I would like create a MVC3 website. I have existing dlls packaged as .net MSI which are installed into the GAC. What is the best way to reference these update-able dlls in MVC3? They will always be installed into the GAC, their version number will be updated accordingly. I don't want to have to manually reference them in my MVC3 project, as every time I re install, the reference will break and I have to update my dependent dll references.
Any input would be appreciated. I have looked around for solutions already but nothing seems straight forward.
Thanks
You haven't found a solution because there isn't one. In order for an assembly to be installed into the GAC it must have a strong name. Every application that uses assemblies from the GAC are tied to the given version and strong name (and this no matter whether you statically referenced the assembly at compile time or used reflection to load it). If you modify it in the GAC clients no longer work and should be updated accordingly. So if you intend to often modify versions of the assembly the GAC is probably not the right place for you. You could still make changes to an assembly in the GAC without modifying its version but you must ensure that those changes are compatible in order to avoid breaking clients.
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 an Oracle.DataAccess 2.112.1.0 version referenced in my project. Whenever I run the project I get an error Could not load the assembly. I checked the entries made in the .csproj file for the referenced dll, and found that the referenced dll was Oracle.DataAccess 2.111.7.0. I am pretty sure the referenced dll is Oracle.DataAccess2.112.1.0 but not sure why the entry made in the project file is different. Any pointers to this would be helpful as this issue has been holding me up for a long time.
I found the same issue when a client use 2.112.1.0 in their references, but it kept referencing a machine local 2.112.3.0.
The reason is that when installed in the GAC, it inserts a policy file - a GAC level config entry to redirect your DLL to their newer version. Even if you have the file in the same dir, .NET 2+ will check the GAC for any policies before allowing your application to resolve the assembly itself.
Something I tried was a manual redirection in your App/Web.config file, but I found this didn't work for me, which is detailed under Redirecting Assembly Versions.
Once this is done, you may encounter this issue:
BadImageFormatException - Image is not of correct format (or something similar)
and/or
Version mismatch - The major/minor version does not match (or something similar)
These errors indicate that although your older assembly is now in use, the COM assemblies it reference are not expected. My investigation found Oracle ODP.NET assemblies stores its COM DLL versions hard-coded within.
The only solution that did for me, was to
Un-GAC the 2.112.X.0 that your app was auto-referencing.
Copy the version specific COM DLLs to a different directory (like \LIB)
Copy them into the build, as you build
If this all fails, I would recommend completely uninstalling the Oracle ODP.NET, deleting the Oracle directory manually and then after rebooting, installing the old DLL from the MSI directly. Oracle seem to have stored the whole history of drivers online at Oracle's website.
Good luck!
I have a VC++ project and I need to add a reference to a managed dll. This dll has a version number which changes every build. When I add it to my project, its version is saved and if I replace it with another one (with a different version number) the project cannot compile because it doesn't find the dll with the version previously saved.
Is there a way to add a reference without a specific version?
Thank you for your help
The C# IDE has the "Specific Version" property for a reference but the C++/CLI build system doesn't support that. There is a workaround, you can use the #using directive in source code to load an assembly reference. This by design cannot check the assembly version of the reference assembly. Normally that's a problem but not in your case. The MSDN page is here.
Note: I don't know whether this works with C++ projects -- we have C# code that references C++, but we haven't done the other way around. But just in case it's easy, I'll offer this:
With C#-to-C# references, normally you would make sure both projects are in the same solution, and then add a reference using the "Projects" tab of the Add Reference dialog (not the "Browse" tab). This way, the build system has a reference to the project in the solution (which knows its own current version number), rather than having a reference to the filename+version; and then it can cope with version number changes just fine.
We recently put out an update of one of our apps with a "test" DLL from a third party. The third party does not update their assembly versions on the dll's, only the file versions, so multiple apps can reference different "versions" of it. However, the GAC still allows us to keep the newest version, because it also checks the file version which is always updated.
What happened is we were not ready to release this DLL, but it got out there on some customer machines. I would like to put our current live version back out there, but it has an older file version (and the same assembly version) as the test DLL. We have multiple apps referencing this DLL, so I can't simply delete it and drop in the new one.
Is there a way to replace the DLL in the GAC? I'm using installshield 2009. Perhaps some sort of custom action upon install?
Could you do following
Verify with respect of gacutil.exe /lr that there are no reference to the old version of the DLL
Verify that there are processorArchitecture information about the old version of the assembly in MSI package. (see http://community.flexerasoftware.com/showthread.php?t=154839&page=2)
Verify that old version of your DLL will be removed during deinstallation.
Look at http://kb.flexerasoftware.com/selfservice/viewContent.do?externalID=Q111094
I'm using VS2005 (haven't moved to 2008 because I'm still using some legacy tools) and have a question about the way project references work.
If I make a project reference to a project that has been deployed to the GAC, VS will use the assembly in the GAC. This is annoying when I have older code in the GACed assembly and I am making code changes and doing quick tests against them - I have to either GAC the new code every time, or remove the assembly from the GAC so VS can't get it from there.
Is there a way to defeat this behavior?
Can't you just change the reference, pointing to the DLL directly?
Better yet, if you changing your DLL, use the Project as reference instead of the GAC DLL?
The best way around this is a two step proces.
1.) In your GAC'ed DLL upgrade the minor version number. (1.0 to 1.1)
2.) Update the project reference to copy local, and use the new version number.
This "SHOULD" get it working, but with the GAC it isn't always 100%.
You could go the route of a policy file, to stop the GAC from loading....but that gets way more complex.
Copy the reference locally.