I'm trying to use ILMerge to create a single executable that uses Windows Azure SDK 2.0 including the Microsoft.WindowsAzure.ServiceRuntime.dll, which I added manually because I couldn't find any NuGET package that contains it.
I'm using the following command line on a VS2012 post-build event:
/wildcards /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" /log:ILMerge.log /closed Output.exe *.dll /out:Executable.exe
However, I'm getting the following error in ILMerge.log, even though the output window reports no issues at all after building:
The assembly 'Microsoft.WindowsAzure.ServiceRuntime' was not merged in correctly. It is still listed as an external reference in the target assembly.
An exception occurred during merging:
ILMerge.Merge: The assembly 'Microsoft.WindowsAzure.ServiceRuntime' was not merged in correctly. It is still listed as an external reference in the target assembly.
at ILMerging.ILMerge.Merge()
at ILMerging.ILMerge.Main(String[] args)
And then the executable throws the following exception when opened:
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. ---> System.IO.FileNotFoundException: Could not load file
or assembly 'msshrtmi, Version=2.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35'
or one of its dependencies.
I have also tested the same output without merging and it works fine.
What am I missing here?
It would seem like this cannot be done, or at least not how I want it done.
Microsoft.WindowsAzure.ServiceRuntime.dll seems to have a dependency on the native library msshrtmi.dll. This means that ILMerge cannot handle it, since unmanaged code cannot be merged with managed code.
According to these two questions there is a way to work around this problem, but it involves packaging the msshrtmi.dllas a resource and unpacking it when it's needed. I feel it's kinda hacky.
So I guess I'll just have to do what I should have done before: remove all references to Microsoft.WindowsAzure.ServiceRuntime.dll from the project that builds the merged, non-Azure version of my WCF service. This might involve using some IoC container and doing some heavy refactoring, which is why I was trying to avoid it at this stage.
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 have a .net core Console app (netcoreapp2.2) that has a project reference to a .net standard Library project (netstandard2.0). The solution builds successfully but when I try to instantiate a class from the library I get the following:
Exception thrown: 'System.IO.FileNotFoundException' in Console.dll. An unhandled exception of type 'System.IO.FileNotFoundException' occurred in Console.dll. Could not load file or assembly 'Library, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
When I remove the project reference and add a dependency reference directly to the debug Library.dll file manually, the project builds and runs normally.
Edit: It is important to note also that when I look in Console\bin\Debug\netcoreapp2.2, the Library.dll and Library.pdb files are present.
Interestingly, if I create a new Library2 project with a different name but copy all of the files from Library into it and change them to the Library2 namespace, the project builds and runs successfully. I could do this as a last resort but would like to understand what's going on.
I don't see anything in either of the .csproj files that would indicate that they would act differently.
What I'm trying to do
I'm trying to create a library (Arduino.dll) to interact with my Bluetooth device from a laptop (Windows 10). This library is intended to be used by a desktop application.
To achieve that, I had to reference both Windows.winmd and System.Runtime.WindowsRuntime.
What's working
I did write the library and tested it on a console application which was on another project in the same solution. To make it work, I had to reference the project and Windows.winmd in the test project. Note that this test project is used to test all of my libraries, so it is heavily manipulated and I tinkered with the settings a lot for years.
What's not working
I finished to write my dll, and wanted to use it in my desktop application. Therefore, I referenced both Arduino.dll and Windows.winmd as in my test project, expecting to work the same way. Sadly, on running the application, I got a "dll not found" when instantiating a class for Arduino.dll :
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in LuxAFX4.exe
Additional information: Could not load file or assembly 'System.Runtime.WindowsRuntime, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
Strange, but well, I tried to reference the (same) System.Runtime.WindowsRuntime as in Arduino.dll but no luck, I now got an even weirder error :
An unhandled exception of type 'System.BadImageFormatException' occurred in LuxAFX4.exe
Additional information: Could not load file or assembly 'System.Runtime.WindowsRuntime, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' 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)
During my search for a solution, I understood that I shouldn't try to load this "reference library" and if it is not found, it must be because it is not installed on the system. But then, why would it work in my test project?
Another thing I may have understand, is that if my library doesn't expose members of referenced 'sub'-libraries, they won't be needed when referencing my library. Should I try to 'hide' all references? If so, is there a way to catch all exposed members? Source : How to to avoid referencing a dll's referenced dll
Side note : I use C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5.1\System.Runtime.WindowsRuntime.dll and C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd.
May be related : Could not load file or assembly Windows.winmd and How to reference Windows.winmd from a .NET Core library?
After some more research, and with the hint given by Hans Passant, I finally understood that I had chosen the wrong System.Runtime.WindowsRuntime.dll to start with. Changing it to use C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Runtime.WindowsRuntime.dll instead in both the project with the DLL and the project using it, resolved my problem.
I got the new file location here : C# “await” error when using WinRT from Desktop app
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 added an existing project to my solution. When I run all unit tests with MSTest runner, I get the following error on a couple of tests:
Message: Test method soandso threw exception:
System.IO.FileLoadException: Could not load file or assembly 'log4net, Version 1.2.12.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a' or one of it's dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT:0x80131040)
I know others have had the same problem and there is other questions and answers about this topic. But I tried many things, but nothing helped.
The version of log4net we use is 1.2.13.0.
I checked with FUSLOGVW.exe for binding errors. The log4net shows up with the added assembly and some Unknown assembly.
The reference of log4net in the assembly shows version 1.2.13.0 which was added with NuGet. So it is probably a dependent assembly that is causing all this trouble.
I tried changing log4net back to version 1.2.12.0, but I still get the same error message.
When I run all the tests with MSTest testrunner, these errors show up. When I only run the failed tests, they pass. When I run them individually, they also pass.
I tried binding redirection, but I did it for the assembly that is tested not the testing assembly. I did not know how to do that for a test assembly - there is no config.
When I run the tests with Resharper test runner they also pass (but other tests fail). The TFS Build server runs the MSTest-runner, therefore I need to get it working with MSTest.
Does anyone know how I can get this resolved?
The culprit was found. Like I was suspecting, a dependent assembly was referencing log4net 1.2.12.0. The tool used to find out was dotPeek. Luckily we do have the source code for the dependent assembly and we can change it to reference the latest log4net. This solves this issue.
So if anyone has a similar problem, use dotPeek or a similar tool to go through the dependent assemblies to find out what versions of assemblies it is referencing.