Related to this question here, I am trying to create an installer which installs DLLs on the target user's PC and makes them available to the Visual Studio Reference Manager (Project > Add References)
I have figured out that to make an assembly visible to the .NET4.0 Reference Manager, I need to add this Registry Key
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\MyAsm
Value: <Directory on target PC of .NET4.0 assembly>
And for .NET4.5, I need this key
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.5.50709\AssemblyFoldersEx\MyAsm
Value: <Directory on target PC of .NET4.5 assembly>
However I now have a problem. When I go to Add-References, I see something like this
So my question is, what is the best practice here for distributing multiple DLLs compiled to different .NET Frameworks (e.g. .NET4.0, .NET4.0 Client Profile, .NET4.5) and targeting different machines (x86, x64, AnyCPU) so that only one version shows up in Add-References OR So that versions can be differentiated in the Add-References dialog?
In general the best practice is to not mess with the user's registry. Do note that a programmer won't expect to find a non-Microsoft assembly in the Framework list so might never even look there. The added convenience is fairly minor, the user can simply use the Browse button to pick the reference assembly you copied onto his machine. Albeit that you do need to provide him with a hint on where to look. Not much of a problem when you use the standard c:\program files\company\product naming strategy.
Avoiding the duplicate is otherwise easy. If your assembly is compatible with .NET 4.0 then only modify the v4.0.30319 key. A project that targets 4.5 will include 4.0 assemblies in the list. If you require 4.5 for some reason then modify the v4.5.50709 key.
Related
How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).
So I've looked around to try to find some posts on this and there are many but none that address my specific question (that I could find).
I am trying to add some DLL's in my project but few of them are coming from :
C:\Windows\Microsoft.NET\Framework\v3.5\XXX.YYY.dll
and what I expecting this should be coming from GAC.
Please suggest me the best practice to reference the Dll's in Visual Studio.
That's not the way it works. When you use Project + Add Reference then you always add a reference assembly. This is never an assembly from the GAC. The GAC is a runtime implementation detail, it is only ever used to supply assemblies when your program executes, never when it is built.
It is very important that it works that way, the content of the GAC on your machine will not match the content of the GAC on your user's machine. Lots of DLL Hell countermeasures are in place to ensure the mapping of your reference assembly to the user's GAC content is taken care of with good diagnostics when the user's machine isn't configured correctly to execute your program.
This is also the reason that you cannot directly look at the GAC folders when you navigate to c:\windows\assembly with Explorer. A shell extension handler hides the details to stop you from making a mistake like adding a GAC-ed assembly as a reference assembly. This same extension handler is not installed for the .NET 4 assemblies, you can look at c:\windows\microsoft.net\assembly and see the structure of the GAC. Do not assume that it is now okay to add references from there, reference assemblies are even more important in .NET 4, they are completely different from the runtime assemblies.
So seeing the reference assembly stored in C:\Windows\Microsoft.NET\Framework\v3.5 is completely normal, that's the home directory for .NET 3.5 specific reference assemblies, like System.Core.dll. For .NET 4 projects the reference assemblies are stored in c:\program files\reference assemblies, they should not reference C:\Windows\Microsoft.NET\Framework\v4.0.30319. Check this answer to see what kind of undiagnosable misery can be caused by not using the correct reference assemblies.
Those assemblies are assemblies of the .NET Framework 3.5. The assembly cache is located at
%SystemRoot%\assembly
You may distribute the .NET Framework 3.5 (scroll the the end of the page) together with your project. Aso if you are using VS Setup projects you can simply use the properties page to reference it.
To reference those assemblies you can easily right-click "References" > "Add Reference" and choose the assembly from the .NET tab. For referencing GAC assemblies refer to this question.
Right now I have a WIX 3.5 project that lives in my VS 2010 solution. It works great and compiles down to 1 MSI.
What I want is to have the 1 project potentially compile down to 2 MSI's. One of the MSI's references a .NET 3.5 DLL that it is installing into the GAC, and the other MSI references a .NET 4.0 assembly that it is also installing into the GAC.
That way I can give the .NET respective MSI's to those depending on what framework they are on.
Is this possible?
Depending on your preference, you can either:
In this Solution panel/Project tree, have two separate projects; a .Net 3.5 and 4.0 projects, with the projects sharing files but different includes/build options.
or
Under the Build tab, pick "Configuration Manager" and "New", using the option to copy the current build to a new configuration. This is similar to having a Release/Debug version.
Here's an overview of this option:
MSDN overview of VS Configuration Manager
The advantage of the first method is the solution pane shows clearly that there are two builds (but its sort of redundant). The second is a bit cleaner, but a bit more hidden (and I'm pretty sure, you can only set the active project to build one configuration at a time).
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.
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.