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
Related
I've been going circles on this one for over a day now. I have a WPF project that is making use of sqlite-net-pcl.
I'm ready to package this project up into an MSI for distribution (x64). The first hitch was that I need to directly add the nuget for the dependency (SQLitePCLRaw.bundle_green). I've come across this before when a nuget package contains content files that need to find their way into the final release. Smooth sailing.
At this point, the bin/x64/release is good and runs fine. However, when I build an installer and run the installed version I get the following exception:
System.BadImageFormatException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatException: Cannot load a reference assembly for execution.
Doing a file compare between my release folder and the application install folder I find the following:
Binary Difference: System.Buffers.dll
Binary Difference: System.Numerics.Vectors.dll
Binary Difference: System.Runtime.CompilerServices.Unsafe.dll
Installer Only: netstandard.dll
Installer Only: System.Diagnostics.Tracing.dll
Installer Only: System.IO.Compression.dll
Installer Only: System.IO.Compression.FileSystem.dll
Installer Only: System.Net.Http.dll
After inspecting further and digging in to the DLLs, I find if I overwrite System.Runtime.CompilerServices.Unsafe.dll with the binary from my release folder everything works.
Digging in even further and inspecting the installer version of CompilerServices.Unsafe I realize that the installer is grabbing the dotnet core version of the DLL.
I've isolated this down to a single console app with a fresh installer project and only adding the content and output to the installer.
Why is the installer insisting that the dependency is a dotnet core version?
I'd like to find a real solution, but in the meantime I found some confirmation and a dirty workaround in this thread: https://developercommunity.visualstudio.com/content/problem/810090/visual-studio-installer-projects-extensions-incorr.html
Workaround option 1: In addition to adding the “Primary Output” of the project containing the package reference also add “Locally-Copied Items” for that project. This will result in the lib version of the assembly overwriting the ref version, giving you the behavior you want. However, you’ll also get a warning about the duplicate file being added, since as I said the lib version will be overwriting the ref version. This also could bring in additional files like xml doc files that should have no impact at runtime but may increase the size of the installer. These can also be individually excluded from the setup project.
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!
How to replace a strong named DLL in GAC by the windows installer?
I am having two installers that shared some common DLLs from the GAC.
suppose there is any change in any common DLL then
running any one installer with latest DLL is not replacing the existing DLL.
from some old post, it is suggested that changing file assembly version will replace DLL.
that approach is not working. Is there anything else needs to be done apart from that?
Windows Installer will not update an assembly in the GAC if you only change the assembly file version unless your install authoring tool also sets the fileVersion attribute for the assembly in the MsiAssemblyName table of the new MSI.
Aaron Stebner addresses this in his blog posting.
I know that this works when using WiX, as I've done this in several installers. I don't know how this might be done in other authoring tools.
I have a problem with an application installer compiled in VS2010.
Version 1.1 installs fine, I get the .exe, .config and referenced assemblies.
I uninstall, then install 1.2. Again everything works as expected.
Uninstall, the install 1.1 again.
Next I install 1.2, the installer updates the referenced assmeblies (I can see the modified date is different) but not the .exe or the .config.
Is there something I'm missing config wise in the setup project?
Thanks
Sam
You'll want to read:
Default File Versioning
Note: it's not the AssemblyVersion attribute that is important rather the AssemblyFileVersion attribute. The former is used by the GAC and Strong Name contracts while the later maps to the Windows Native FileVersion structure.
I've actually answered my own question.
The problem was that I'd not incremented the assembly version of one of the referenced .dlls. Although the timestamp was being updated, the existing files were not being overwritten or patched.
I used
msiexec.exe /i "\\path\myApp.msi" /l*vx! C:\temp\install.log
to log what was happening and found the problem in there.
Since then I've incremented the offending assembly's version number and all is ok.
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.