I have an application that relies on a set of third-party DLLs, version v1.1. In order to use them, I reference the main one, which is found somewhere under the Program Files folder. This library uses the other ones, installed in the GAC.
A new version of the third-party DLLs is released, v1.2. The DLL in the Program Files folder is replaced by the new version; in the GAC, both versions co-exist.
The problem is to get the application (compiled with DLLs v1.1) to work when v1.2 is installed, without re-compiling it, and without changing the app.exe.config file.
I am the maintainer of the DLLs; additional constraints are that only the latest version of the DLL is installed in Program Files, and other DLLs are all installed in the GAC (all versions are kept).
My problem is that the application starts, but eventually I get an error because of incompatibilities between types:
Unhandled Exception: System.InvalidCastException:
[A]ThirdParty.User cannot be cast to [B]ThirdParty.User.
Type A originates from 'ThirdParty, Version=1.2.0.0, Culture=neutral, PublicKeyToken=XXXX'
in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_32\ThirdParty\v4.0_1.2.0.0__XXXX\ThirdParty.dll'.
Type B originates from 'ThirdParty, Version=1.1.0.0, Culture=neutral, PublicKeyToken=XXXX'
in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_32\ThirdPart\v4.0_1.1.0.0__XXXX\ThirdParty.dll'.
I am not sure to understand how the v1.2 DLL is chosen, I am guessing that the path to the DLL is stored in the application, which in turn decides to use the DLLs in the GAC for this version? I am testing on a system different from the one used for compiling, but the DLLs are located in the same location. My understanding from the documentation is that the v1.1 version in the GAC should be chosen, not v1.2.
Where is my mistake? How can I fix it?
Thanks,
I found a solution in my specific case, and re-reading my question I realize I did not mention that my initial DLL does rely on a PowerShell instance. Which is where I worked around my problem. In my DLL, I load a specific version if the DLL that is present in the GAC, and load it in my PowerShell instance:
var assembly = Assembly.Load("ThirdParty, Version=1.1.0.0, Culture=neutral, PublicKeyToken=XXXX");
var ps = PowerShell.Create();
ps.Commands.AddCommand("Import-Module").AddParameter("-Assembly", assembly);
ps.Invoke();
Related
I am trying to include some reference files in Wix# managed project using DefaultRefAssemblies.Add method:
ManagedProject project = new ManagedProject();
project.DefaultRefAssemblies.Add("FontAwesome.Sharp.dll");
project.DefaultRefAssemblies.Add("protobuf-net.dll");
project.DefaultRefAssemblies.Add("Newtonsoft.Json.dll");
project.DefaultRefAssemblies.Add("ManagedOpenSsl.dll");
project.DefaultRefAssemblies.Add("ssleay32.dll");
When I try to build a MSI I get an error. The problem happens to be in loading of ssleay32 assembly (part of OpenSSL). When I exclude this file, the build succeeds. Can you please help me understand the exception? The target framework of the Wix# project is .NET Framework 4.8.
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly '361984 bytes loaded from WixSharp, Version=1.15.0.0, Culture=neutral, PublicKeyToken=3775edd25acc43c2' or one of its dependencies. An attempt was made to load a program with an incorrect format. ---> System.BadImageFormatException: Bad IL format.
Wixsharp supports .net assemblies compiled for:
Platform x86
Managed assemblies (Not native)
Target framework 3.5
So, make sure "ssleay32.dll" has 3 requirements above. Every ssleay32 assembly i have found was native (unmanaged).
Workaround in case of no luck with:
You can try to save ssleay32.dll to embedding resource file and before "ManagedOpenSsl.dll" types usage you should load dll in the memory. Load unmanaged assembly
Good luck!
I'm running a program in C# .Net, WPF, and having this problem: if I try to load a dll dynamically from the GAC and it's not presente, the system show an error, then I install the dll in the GAC and system still isn't able to find it. But, if just restart the system, whitout changing anything, it find's the DLL.
For more details, in an async thread, I call one dll dynamically from the GAC, and this dll calls another DLLs dynamically, and are those "second" dlls that are causing this problem.
The dlls are being called using the following:
var classType = Type.GetType(fullyQualifiedName, true);
T assemblyClass = (T)Activator.CreateInstance(classType);
Also, the "fullyQualifiedName" follows the format:
NameSpace.Class, AssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=number of the token, processorArchitecture=x86
And the "assemblyClass" is cast to an interface.
Thanks in advance.
One of our build agent servers does not have System.Data.SqlXml Version=2.0.0.0 under C:\Windows\assembly but every other machine we have does. Unfortunately this causes nunit-summary.exe on that box to fail with:
EXEC Could not load file or assembly 'System.Data.SqlXml,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or
one of its dependencies. The system cannot find the file specified.
error MSB3073: The command ""../tools/nunit-summary.exe" artifacts/Test_*.xml" exited with code -1.
I tried installing MSXML 4 to no avail. I have not been able to figure out how to install version 2, any ideas?
Two possible solutions.
a) In the project, expand references to find the reference to the library. Go to properies and set Copy Local to be True. The .dll will then be included in the bin folder when the project is built.
b) Install SQLXML from Microsoft (this is different to MSXML which you tried). Details about the library (including the download link) are available at https://learn.microsoft.com/en-us/sql/relational-databases/sqlxml/what-s-new-in-sqlxml-4-0-sp1
I'm trying to create a single-file executable. The code is .Net-based and also relies on some additional libraries including SQLite.
When I compile the source code, all of the relevant files go into the Release directory, although the SQLite DLL (sqlite3.dll) goes into a sub-directory (x86). I think this happens because I'm using SQLite-raw and that "spits out" both x86 and x64 copies of the DLL.
My initial command line to try is:
ILMerge /out:GEDtoRH.all.exe GEDtoRH.exe *.dll /target:exe /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2" /wildcards /log
This produces the following output that worries me:
AssemblyResolver: Assembly 'System.Runtime.WindowsRuntime' is referencing assembly 'System.Runtime'.
...
AssemblyResolver: Did not find assembly in framework directory.
AssemblyResolver: Unable to resolve reference. (It still might be found, e.g., in the GAC.)
AssemblyResolver: Assembly 'System.Runtime.WindowsRuntime' is referencing assembly 'System.Threading.Tasks'.
...
AssemblyResolver: Did not find assembly in framework directory.
AssemblyResolver: Unable to resolve reference. (It still might be found, e.g., in the GAC.)
AssemblyResolver: Assembly 'System.Runtime.WindowsRuntime' is referencing assembly 'System.IO'.
...
AssemblyResolver: Did not find assembly in framework directory.
AssemblyResolver: Unable to resolve reference. (It still might be found, e.g., in the GAC.)
Location for referenced module 'sqlite3' is ''
Should I be concerned about the unresolved references? The reason I ask is because the finished executable doesn't work. It breaks with a null reference exception (Object reference not set to an instance of an object) on this line:
file = await StorageFile.GetFileFromPathAsync(filename);
The un-merged version of the executable works fine :( It isn't "filename" that is broken as I've tried adding some extra tests and it is fine.
Try as I might to add the sqlite3.dll to the list of things to ingest, if I try, ILMerge just complains with a "Could not load assembly" error.
As SQLite is not a .NET library it doesn't contain any IL to be merged
I have got this error when using Enterprise Library 3.1 May 2007 version. We are developing a product and have a common lib directory beneath the Subversion Trunk directory
<>\Trunk\Lib\ into which we put all the third party DLLs. Inside this we have Microsoft\EnterpriseLibrary\v3.1 in which we have copied all the dlls from \Program Files\Microsoft Enterprise Library May2007\bin. Everything was working properly until one of the developers installed the source code on this machine. There were some dlls copied at the end of the source code installation and once that was done, he is not able to run the project anymore. He always gets this error
'Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'
What is the problem here? I thought that when the source code was installed it was just supposed to build everything and copy in the bin directory within the source code parent directory. Also we have copied the Dlls from Microsoft Enterprise Library May 2007\bin directory into our product development directory and references into our project with a copylocal flag set to true.
Can anyone help me out here
RK
I used to get that when I developed against the signed version of the dll and deployed where only the unsigned version was available.
Also, fuslogvw.exe. EVERY. TIME.
I assume the error lies in the developer having compiled the code against the unsigned source code compilation he has.
Make sure he adds the reference to the signed DLLs before compiling his code.
Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null
should be something like:
Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=fa03fef243232
maybe you should check the Assembly- and FileVersion of the dll. if they do not match this exception can occur.
Read here to get started with assembly loading debugging.
In short you need to check the Fusion log for more information.
For a "The located assembly's manifest
definition with name [yourAssembly]
does not match the assembly reference"
message (for hresult
FUSION_E_REF_DEF_MISMATCH,
0x80131040): The Fusion log will say
which part of the assembly reference
failed to match what was found. It
will be the assembly name, culture,
public key (or token) or version (if
the found assembly was
strongly-named).