This is not so much a question but rather a comment since I've found the answer already.
Problem:
I was moving a VS2008 project to VS2010, which uses the Microsoft.ManagementConsole namespace. The reference of the project targeted the DLL registered in the GAC, namely the file C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ManagementConsole\3.0.0.0__31bf3856ad364e35\Microsoft.ManagementConsole.dll. However VS2010 did not accept the reference anymore, even though I checked that the DLL was still in the GAC with the command gacutil /l.
Solution:
On MSDN: How-To Create a Hello World Snap-in I found a hint in a comment. Instead of linking the DLL in the GAC, I'd rather link the original DLL in the folder C:\Program Files\Reference Assemblies\Microsoft\mmc\v3.0\microsoft.managementconsole.dll. Builds like a charm.
Hope this helps somebody with the same problem!
Related
Good day. I have 2 solutions on C# (Visual Studio 2008). First solution contains reference to built dll of second solution. When I debug first solution, appears code of second solution. It is no obvious and no useful for me. I want to debug solutions separately. How can I do this?
Update:
I deleted all PDB files, put DLL in new folder, updated the reference, but Visual Studio still find the source code. I can not hide it from VS! Help me please.
The only way VS can find the code for a random DLL is by using the debug information, which is stored in a PDB file in the same folder as the DLL.
So in solution 1, if you are referencing the DLL in the location where it was built by solution 2, then it probably has the PDB file in that same folder. And that's why VS can figure out where the source code is.
Try this:
Remove the reference to the DLL from solution 1
Copy the DLL from solution 2's bin\Debug folder to a brand new folder
In solution 1, add a reference to the DLL in this brand new folder
Also ensure the <dllname>.PDB does not exist anywhere below solution 2's directory structure.
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.
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.
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.