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.
Related
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.
I am working in Visual Studio 2012 and I was missing the "Microsoft.Office.Interop.Excel" assembly. After downloading the missing exe from http://www.microsoft.com/en-us/download/details.aspx?id=3508,
the instructions are as follows:
"Wrap the O2010pia.msi file in another setup package through Visual Studio or other Windows Installer aware setup editor"
I ran the exe, but the missing assembly is still missing from Visual Studio.
I am quite new to development and after googling for a while, I am no closer to understanding what this means. I would greatly appreciate some insight.
You did not read it correctly. The page says "Use one of the following installation methods". The one you are asking about is what you do when you create an installer for your program so the PIA also gets installed on your client's machine. You are not there yet.
You should not be doing this anymore, PIAs are outdated since VS2010. Replaced by the "Embed interop types" feature, aka "NoPIA". Project, Add Reference, click COM, select the "Microsoft Excel xx.x Object Library" entry where xx.x is the version number of Office you've got installed on your machine. This automatically adds the Microsoft.Office.Core and Microsoft.Office.Interop.Excel references to your project. With their Embed Interop Types property set to True so you don't have to install anything on the client's machine.
If you don't see this entry then you will need to install Office on your machine. Required to add the reference and to debug and test your code.
I am using Visual Basic 6.
There are some component references in my project. Components are registered with Windows using "regsvr32".
So, I have added .ocx from the installation directory to Components.
Let say C:\Program Files\Install Dir\. But, When I see References (.oca) for the control, VB automatically taking path C:\Program Files\Microsoft Visual Studio\VB98 and I can see .oca files are getting copied.
But, I want to use References from the Install dir only. I tried removing or updating, It says Can't remove control or reference;In use
I have already tried editing .vbp in editor but It does not show .oca Reference path not even default C:\Program Files\Microsoft Visual Studio\VB98
ActiveX DLLs and OCXs install as shared libraries by design. For this reason you almost never want to install them into a private folder like your C:\Program Files\Install Dir\ unless they are truly private in the sense of being parts of your application that other code should not use.
More generic "utility" libraries such as those provided by Microsoft, 3rd parties, or even those you develop yourself normally install in developer mode by including both design-time licenses (when licensed) and more relevantly here .DEP files. Part of the information contained in such .DEP files is where the library is meant to be installed. In some cases this is System32, in others it is a folder under Common Files, etc.
Now if you truly want a private copy of a DLL or OCX there is a mechanism for that. These are called isolated assemblies and they replaced the earlier, problematic .local mechanism in Win2K.
Those .OCA files are something else entirely and you should not try to reference them or deploy them.
But it is hard to tell what you are really after. A message like:
Can't remove control or reference;In use.
.. is a design-time issue entirely unrelated to the rest of your question.
I'm just not sure what you are trying to do. It sounds like you are trying to re-use libraries private to some other application.
This is similar to Add Non-GAC reference to project but the solutions presented there don't seem to help.
I have a WinForms UI Library (Krypton from ComponentFactory) installed in the GAC. There's a bug I want to track down in that library, so I added the source code to my solution, removed the old references from my WinForms project to Krypton DLLs, added them back as a project references, ensured Copy Local is set to true, double-checked that the path (on reference properties tab) points to my local project, and...
...the GAC version is still being used while debugging. I cannot set a breakpoint in the Krypton source, Debugger.Break() or other code changes to not execute, and when I start the Visual Studio 2010 debugger, I see a Loading from ... GAC_MISL message relating to the Krypton DLLs flash by in the VS 2010 status bar. The DLLs are not copied to the WinForm's Debug folder.
How can I reference the "project" version of the files while debugging while leaving them registered in the GAC?
The CLR will always look in the GAC first. Don't hesitate to use gacutil.exe /u to remove them. Hacking the [AssemblyVersion] would work too so that the GAC copy won't be a match.
I am trying to extend a certain application. I am using a DLL which comes bundled with that application to extend its functionality. I am using visual studio 2010 express edition. I added a reference to the dll library. In the reference properties the option "Copy local" is disabled.(greyed out) why is that? I want visual studio to copy the dll to my release folder. If this can't be done is there another way to bundle the dll?
Your comment to Hans answer indicates this is a COM assembly and that you are using Visual Studio 2010.
This means the assembly reference was likely added with the "Embed Interop Types" setting set to true. This has the effect of linking the COM assembly into your binary removing the need to deploy it altogether. The following link has a more detailed explanation
http://msdn.microsoft.com/en-us/library/dd409610.aspx
If you do want to deploy it though then will need to do the following
Click on the reference in the references tab
Hit F4 to bring up the properties grid
Set "Embed Interop Types" to False (this will ungray Copy Local)
Set "Copy Local" to true
It depends on what kind of DLL it is. If it is a COM server then Copy Local is off when you have a PIA registered for that COM server. If it is a regular .NET assembly then it will be off when it is registered in the GAC.
Fix the issue by, respectively, using regasm /u to unregister the PIA or gacutil /u to remove it from the GAC. Do note that you might not want to do this if this DLL requires that its installer is executed on the target machine. Which is likely. Talk to the component vendor or author to find out what you should do.