I have a project for a .Net log component.
As I use this in many other projects I decided in the past to push it on nuget.org. In other projects I do reference this package.
So far so good.
Now I started to setup a deployment server using Jenkins.
In Jenkins I have a project that builds this log component and copy the artifact log.dll to a final destination.
When the component that works fine with the log.dll from nuget.org package uses the local build log.dll from the Jenkins build.
I get this error in event-log:
Application: ServiceConsole.exe Framework Version: v4.0.30319 Description:
The process was terminated due to an unhandled exception.
Exception Info:
System.IO.FileLoadException at ServiceConsole.MainForm..ctor()
at ServiceConsole.Program.Main()
And another
ServiceConsole.exe
2.10.0.0
5b3f4a6d
KERNELBASE.dll
10.0.14393.2312
5b1a1651
e0434352
0000000000033c58
480c
01d4153f46b746a1
C:\bin\ServiceConsole.exe
C:\Windows\System32\KERNELBASE.dll
05d03123-c336-4119-947f-7de71a75c0b5
I did compare the two dll (from nuget.org and locally build with jenkins (msbuild.exe)).
Both dll have:
The only difference that just came into my mind is that msbuild.exe in Jenkins is from VS2017 build tools while months ago I did publish the dll on nuget was VS2015.
Anyone have a clue what this could be? Really a compiler issue?
Edit Was curious and installed MSBuild.exe from VS2015 (Version 14) and changed Jenkins settings. The locally build with this build did not work either...
So the only difference I think I still have is that the former package I pushed on nuget.org was build on my develop machine using VS2015 IDE.
Edit
Start code that is not even fired:
static class Program
{
private static readonly string _assemblyName = Assembly.GetExecutingAssembly().GetName().Name;
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
try
{
Console.WriteLine("starting app");
using (var processLock = new ProcessLock(_assemblyName))
{
if (processLock.AlreadyExists)
return;
// The program operation must run inside the 'using' block.
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainForm());
}
}
catch (Exception e)
{
Console.WriteLine(e);
throw;
}
}
}
EDIT2
So it seems to turn out that changing the signed key file after last push to nuget the public key token changes and results into this error.
start appSystem.IO.FileLoadException: Could not load file or assembly 'Common.Log, Version=2.10.0.0, Culture=neutral, PublicKeyToken=8a1542bdbac62407' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Common.Log, Version=2.10.0.0, Culture=neutral, PublicKeyToken=8a1542bdbac62407'
at ServiceConsole.MainForm..ctor()
at ServiceConsole.Program.Main()
=== Pre-bind state information ===
LOG: DisplayName = Common.Log, Version=2.10.0.0, Culture=neutral, PublicKeyToken=8a1542bdbac62407
(Fully-specified)
LOG: Appbase = file:///C:/prog/bin/
LOG: Initial PrivatePath = NULL
Calling assembly : ServiceConsole, Version=2.10.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Common.Log, Version=2.10.0.0, Culture=neutral, PublicKeyToken=8a1542bdbac62407
LOG: Attempting download of new URL file:///C:/prog/bin/Common.Log.DLL.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Looking for confirmation. So next step to fix that is publish new version to nuget and use it, but have to raise the version number. Correct?
If the assemblies are identical in a binary compare and one loads but the other does not it is likely to be a security issue.
.Net tracks the origin of assemblies and applies different security policies for assemblies that originated from the Internet for example to protect you from accidentally running malicious code.
Two identical assemblies could be treated differently by the .Net loader if they were copied from different places.
User contributions licensed under CC BY-SA 3.0