I work on WinApp in Visual Studio 2010 (With C# Language)
I want to add one dll (not system dll) to Reference.
but when I open Add Reference Window And Browse dll see under error message:
Could not load file or assembly 'W2D_D2.dll' or one of its
dependencies. The module was expected to contain an assembly manifest.
this file may not be a managed assembly.
I even change the Target Platform from ".net framework 4 client profile" to ".net framework 4" but not difference.
How Can Add This dll To My Project?
Looks like this DLL is not a managed assembly. You can check this very quickly by trying to open it with ILSpy or Reflector.
If this is the case, you'll have to pinvoke or use com to use this dll.
Related
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.
I have installed the strong named assembly TestReflection into the GAC (I am using .NET 4.0 and VS 2010).
Different versions of the TestReflection DLL are in GAC of .NET 4.0 (C:\WINDOWS\Microsoft.NET\assembly\GAC_32\TestReflection\), however, the assembly does not appear in the "Project" -> "Add reference" box of VS 2010.
How can I refer to my assembly deployed in GAC at design time from another project?
This page says that:
You cannot add references from the Global Assembly Cache (GAC), as it is strictly part of the run-time environment.
Referring to this statement, I would like to know how to make your project's DLL shared assembly for other consumers if it's the requirement?
The dll's shown in the .Net tab of the "Add references" dialog are not actually the ones registered in the GAC. They are found by searching a few paths on your filesystem.
The paths being searched are located by Visual Studio by looking up the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\{Version}\AssemblyFoldersEx\
There should be some keys added there already, so if you want your own dll to show up on the .Net tab, you can add it to one of the folders defined there. You could also add a new registry key pointing to a custom folder, which would only contain your own dll's.
The GAC is only meant for loading assemblies at runtime after your application has been deployed, so I don't think you should use it while developing. When you deploy your app, make sure to set "Copy local" to false on your reference so the dll won't be copied to the bin folder, and then install it into the GAC and it will be loaded from there instead.
Another simple option would be to manually edit the project file as XML in visual studio (You will have to unload the project first), and simply add node <Reference Include="<name of dll>" /> in MSBuild project file. After reloading the project, VS will pick up the reference without problem.
If you want to add Global Assembly Cache references to your VS2010 project, there is an extension you can use: Muse.VSExtensions.
It has some quirks but does a decent job. Check it out...
The answer is the Reference Paths in the property windows, you have to set it with the GAC path
Please see my post here:
In VS 2010 express there are a few library projects (dlls) attached to the application project. When building the solution the dlls output to bin/Release/. Is there a way to have the .exe output to bin/Release and the dlls to bin/Release/dll?
This requires either a .config file with the <probing> element or implementing AppDomain.AssemblyResolve so that the CLR can find these DLLs. You'll have a deployment problem too, you have to convince ClickOnce to publish these DLLs. Realistically should only attempt this with the retail edition of Visual Studio so you can create a Setup project.
Fwiw: your customer won't mind that the DLLs are in the same folder as the EXE. I think most actually strongly prefer this. I do.
You could always have a post build event on the application project that copies all .dll files to a dll directory.
However the assembly loader will not be able to find the dll file and you application will not start.
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.
I have a C# project in Visual Studio 2005 that is referencing a few COM libraries. When I build it errors like this are thrown:
Referenced assembly 'assemblyName' does not have a strong name.
Now, I used to reference COM assemblies in Visual Studio 2003, and it would automatically sign the Interop wrappers. All I had to do was set the setting 'Wrapper Assembly Key File'.
I tried finding a similar setting in Visual Studio 2005, but I couldn't find any. So I was wondering if there's any equivalent way of strong naming COM Interops in Visual Studio 2005 and getting rid of the above error.
It looks like it was already answered in "Where is the Wrapper Assembly Key File setting in VS 2008?" question.
Instead of using Visual Studio you could use Tlbimp.exe and
Aximp.exe to generate the Interops. Tlbimp.exe has options for signing.
I have used them to be generate an Interop file for each different version of the same COM component in my application. The COM components are vendor supplied COM components used for accessing data points in mass spectrometry files and the COM interface change from time to time as new versions of the vendor software is released. The application can then decide at runtime which Interop to use in order to match what version is installed on the computer where the application is installed.
The BAT file I use for generating the Interops is online.