I need to deploy a new item/project template and I found out that the way to do it is to copy it to [Visual Studio folder]\Common7\IDE\ItemTemplates.
How can I find where VS was installed (in my case VS2010)?
WiX code will be welcomed...
I suppose this is what you need.
Part of the answer:
You're going to need to query the registry to get the path - this is the relevant bit of the help from the wix site: http://wix.sourceforge.net/manual-wix3/read_a_registry_entry.htm
Most of the rest:
Path appears to be somewhere in HKCU (current user) - specifically a value here:
HKEY_CURRENT_USER\software\microsoft\visualstudio\10.0_Config which has a key InstallDir that should give you what you want (or close enough).
Not sure if you should be installing there or in the user's template directories but those are also in the registry (under 10.0 rather than 10.0_Config)
Related
I'm trying to figure out how to get a single-file generator installed on VS2010. Previously I got it sort-of working on VS2013 after many hours of head-banging; in both cases the primary difficulty is setting up the registry entries. Apparently VSIX files don't allow registry settings:
You can use the VSIX format to package project and item templates,
Visual Studio Integration Packages, Managed Extensibility Framework
(MEF) components, toolbox controls, assemblies, and custom types. The
VSIX format uses strictly file-based deployment and does not support
writing to the Global Assembly Cache (GAC), or to the system registry.
VSIX is the preferred deployment method for the extension types that
it supports.
My VS2013 solution involves the CodeGeneratorRegistrationAttribute and ComVisible(true) on the assembly, but after install, the extension doesn't work until the user runs devenv.exe /setup in Administrator mode. In VS2010, CodeGeneratorRegistrationAttribute does not exist in any of the SDK DLLs and simply adding the source code of CodeGeneratorRegistrationAttribute.cs to the project (as the Single File Generator sample does) doesn't seem to work (and I don't understand why the sample seems to expect it to work; .NET doesn't use structural typing, after all, so how could this attribute possibly have any effect?)
If a VSIX cannot add registry settings directly, I think a reasonable substitute is to include some code that automatically runs on VS startup. That code could find out the path of the registry hive of the running VS version and add the necessary registry settings at that time. So I have three questions:
How can I cause a method written by me, inside my extension, to run when VS starts?
How can I get the path of the current VS registry hive?
Is there any other way to add the registry information?
Eventually I gave up on making a VSIX to hold my single-file generator. I made a CodeProject article about what I did instead.
But back when I was still trying to make a VSIX file, this blog post came in handy.
What is wrong with MSI-deployment? You can do anything from there. WiX has option to install VSIX packages pretty simply, just use the embedded element <VSIXPackage>. It also offers you to create new registry keys + you get registry key unistall for free. Note that you can elevate privileges, if needed.
does your vsix have a class that extends Package?
Add code in your Package's Initialize method that runs when your package is initialized.
To get to VS based registry stuff, see Microsoft.VisualStudio.Shell.VSRegistry
Someone sent me a project and I want to create the same type of project (like... WCF Application or Portable Service Class). I've looked around Visual Studio 2010 and don't see any obvious place where it's stated what type it is.
Does anyone have an answer?
Thanks.
Open the project file in a text editor - there is a ProjectGuid element which identifies the type of project.
See this list that maps some of these guids to project types.
In the registry
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio{VisualStudioVersion}_Config\Projects\
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio{VisualStudioVersion}_Config\Packages\
The Project TypeId from the project file can be used to find the relevant information under the first registry path. If further information is required you can for the "Package" key searching under the second registry path.
ps. {VisualStudioVersion} must be substituted with the version you are checking against ie. 10.0 (2010) or 11.0 (2012)
I am useing InstallShield Limited Edition for Visual Studio 2010 to create an installer, and I am trying to add an executable custom action.
My custom action in an exe that is installed to the install dir.
The custom action needs to use another file that is located in the install dir as well.
How do I get the path to the install dir to my exe? I tried to pess [INSTALLDIR] as an argument but it translates to "C:\Program" instead of the correct dir ("C:\Progam Files\MyCompany\MyProduct"). I tried [TARGETDIR] but it translate to E:\ (wrong as well).
Any Ideas?
Found the problem.
using [INSTALLDIR] is currect. the problem is with powershell. reading C:\Program Files...
as C:\Program.
the Issue is discussed here:
http://www.leeholmes.com/blog/2006/05/05/running-powershell-scripts-from-cmd-exe/
EXE custom actions are very limited. If I was using InstallShield LE, I'd create a C# WiX/DTF Custom Action and consume it in a WiX Merge Module and then consume that merge module in your InstallShield LE project. This gives you very powerful solution.
This assembly is in the GAC: Microsoft.SqlServer.Management.RegisteredServers.dll
How can I add a reference to this assembly in Visual Studio?
I can view the file in c:\windows\assembly\
As the others said, most of the time you won't want to do that because it doesn't copy the assembly to your project and it won't deploy with your project. However, if you're like me, and trying to add a reference that all target machines have in their GAC but it's not a .NET Framework assembly:
Open the windows Run dialog (Windows Key + r)
Type C:\Windows\assembly\gac_msil. This is some sort of weird hack that lets you browse your GAC. You can only get to it through the run dialog. Hopefully my spreading this info doesn't eventually cause Microsoft to patch it and block it. (Too paranoid? :P)
Find your assembly and copy its path from the address bar.
Open the Add Reference dialog in Visual Studio and choose the Browse tab.
Paste in the path to your GAC assembly.
I don't know if there's an easier way, but I haven't found it. I also frequently use step 1-3 to place .pdb files with their GAC assemblies to make sure they're not lost when I later need to use Remote Debugger.
Registering assmblies into the GAC does not then place a reference to the assembly in the add references dialog. You still need to reference the assembly by path for your project, the main difference being you do not need to use the copy local option, your app will find it at runtime.
In this particular case, you just need to reference your assembly by path (browse) or if you really want to have it in the add reference dialog there is a registry setting where you can add additional paths.
Note, if you ship your app to someone who does not have this assembly installed you will need to ship it, and in this case you really need to use the SharedManagementObjects.msi redistributable.
I've created a tool which is completely free, that will help you to achieve your goal. Muse VSReferences will allow you to add a Global Assembly Cache reference to the project from Add GAC Reference menu item.
Hope this helps Muse VSExtensions
In VS2010, from the Add Rerences window you can click 'Browse' and navigate to C:\Windows\Assembly and add references to the assemblies that you want. Please note that the files may be grouped under different folders like GAC, GAC_32, GAC_64, GAC_MSIL etc.
In VS, right click your project, select "Add Reference...", and you will see all the namespaces that exist in your GAC. Choose Microsoft.SqlServer.Management.RegisteredServers and click OK, and you should be good to go
EDIT:
That is the way you want to do this most of the time. However, after a bit of poking around I found this issue on MS Connect. MS says it is a known deployment issue, and they don't have a work around. The guy says if he copies the dll from the GAC folder and drops it in his bin, it works.
The only way that worked for me, is by copying the dll into your desktop or something, add reference to it, then delete the dll from your desktop.
Visual Studio will refresh itself, and will finally reference the dll from the GAC on itself.
Assuming you alredy tried to "Add Reference..." as explained above and did not succeed, you can have a look here. They say you have to meet some prerequisites:
- .NET 3.5 SP1
- Windows Installer 4.5
EDIT: According to this post it is a known issue.
And this could be the solution you're looking for :)
May be it's too late to answer, but i found a very simple way to do this(without a hack).
Put your dll in GAC (for 3.5 Drag Drop inside "C:\Windows\assembly\")
GoTo Projects --> Properties
Click Reference Path (for 3.5 it's "C:\Windows\assembly\")
and Build
Hope it helps
The relevant files and references can be found here:
http://msdn.microsoft.com/en-us/library/cc283981.aspx
Note the links off it about implementation/etc.
I found this extension for VS 2013 Vitevic GAC Reference.
So after installing NUnit, the assemblies (nunit.framework, etc.) now appear in the References > Add Reference dialog, but they're not in the %WINDIR%\Microsoft.NET\Framework\v2.0.50727 dir and there is no NUnit registry entry for the Assembly Path (i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramewokr\AssemblyFolder).
There's also no automatic entries created in the project properties Reference Paths for the NUnit install directory. How the heck are they appearing in the "Add Dialog"?!?! I thought the mentioned way were the only ways assemblies could appear in "Add Reference".
I dug deeper into this at the weekend. Reproduced verbatim from my blog:
Why is NUnit not in the GAC? (or Why does [assembly X] not appear in Visual Studio's Add Reference dialog?)
Because Visual Studio doesn’t look for references in the GAC:
http://blogs.msdn.com/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx
http://blogs.msdn.com/junfeng/archive/2004/03/22/93708.aspx
This is by design.
You can either add your files explicitly, which doesn’t work if other people in your team have installed the files somewhere else, for example C:\Program Files\NUnit 2.4.6 vs. C:\Program Files\NUnit-2.4.6. Or (more specifically, because this is the problem I was having this morning) C:\Program Files\NUnit 2.4.6 vs. C:\Program Files (x86)\NUnit 2.4.6. Note the (x86) – my home PC is (as of last weekend) running Vista Ultimate x64.
You have a couple of options:
If your assemblies don’t already have homes, you can put them in the VS PublicAssemblies folder: http://blogs.msdn.com/csharpfaq/archive/2004/10/20/245239.aspx
If they already have homes, you can add them to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders registry key: http://support.microsoft.com/?kbid=306149.
If you’re developing assemblies for other developers to use (i.e. you’re Microsoft or a development tool vendor), you can put these in a subdirectory of C:\Program Files\Reference Assemblies directory, and then add that to the AssemblyFolders registry key.
This means that your project files will reference the assembly by name (i.e. name, version, public key token, all that jazz), and it won’t matter where it’s actually installed on your PC.
Note, however, that this doesn’t work as-is on 64-bit, because Visual Studio is a 32-bit application. You actually need to register your stuff under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AssemblyFolders, and you should probably register under both.
There are also corresponding HKEY_CURRENT_USER variants of those keys, but (since that roams), it’s not much use (because the paths are usually relative to the machine, anyway).
Strange, [HKEY_CURRENT_USER\SOFTWARE\Microsoft.NETFramework\AssemblyFolders] should be the only thing driving this.
Perhaps this snippet from this page is relevant?
If you install the .NET Framework 3.0 Service Pack 1 (SP1), the following registry subkey is added:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\v3.0
If you install the .NET Framework 3.5, the following registry subkey is added:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\v3.5
On my install of NUnit I have a registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\NUnit 2.4.3
It seems to be the driver of this behaviour on my computer. Once I removed that key the references did not appear.