Issue with nested DLL referencing in a self-contained .Net Core web app running as a Windows service

user_838807 0
Viewed 242

The Error

First off, lets start with the error message:

System.BadImageFormatException: 'Could not load file or assembly 'System.Management, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (0x80131058)'

In my experience, this type of error usually occurs if the DLL is missing, or it's not in the expected format/version. However, I cannot work out what I need to do to resolve this error.

The Setup

The main project is an ASP.Net Core 3.1 application.

It is configured to be able to run as a Window service and support Web API and MVC frameworks. So my Program.cs looks something like this:

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args)
    {
        var builder = Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });

        builder.UseWindowsService();

        return builder;
    }
}

That part all works great, I can run the app as a Windows service and serve razor views and web API endpoints, etc.

However, there are more projects in this solution. I have a couple of .Net 4.6 class libraries projects that are referenced by the service app. So my solution looks something like this:

  • Service App (NET CORE 3.1)
  • Lib 1 (NET 4.6)
  • Lib 2 (NET 4.6)

Service App references Lib 1, and Lib 1 references Lib 2.

Any code is either of these two libraries works fine and can be used by the service app.

The problem is that Lib 2 references System.Management DLL, and this is what is causing the error. Whenever I use a function that uses that DLL, I get the error above.

The Attempts So Far

My attempts so far have including:

  • Setting the DLL to "copy to output"
  • Adding the DLL reference directly to the web service app
  • Manually copying the DLL to the output folder. Both debug, and publish folder (note: publish is set to "self contained" application)

The Question

Basically, how can I resolve this issue? Or at least, how can I further debug the problem to potentially find a solution.

asp.net-core windows-services
1 Answers

I can't repro this at the time, but I suspect this to be a bug in the way that the self-contained publication process using dotnet publish resolves transitive dependencies.

The point is, your .NET Core 3.1 application doesn't run on .NET Framework, while the library you reference, call it "Lib 2", does.

And your Lib 2 has a reference to the NuGet package System.Management, which, when installed on a project targeting .NET Framework ... does nothing, except making your project reference the .NET Framework reference assembly for System.Management, found in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1. At runtime, the .NET Framework will load the appropriate assembly from the GAC, but the .NET Core runtime does not do this.

Now when publishing your .NET Core app, MSBuild walks through the dependencies to be copied, and (again, I suppose) looks at the reference assembly and goes "I want that one!" and copies it to your output directory.

But you can't run reference assemblies, you can just reference them, so at runtime, your application blows up with an exception stating exactly that:

Reference assemblies should not be loaded for execution

A workaround, but definitely not a solution, is to reference the same System.Management package from your .NET Core application, where the package will actually extract a DLL containing runnable code, and that one will be copied to your output directory. But this might cause other issues, such as the DLL being overwritten during build with the reference one.

I'd suggest looking at GitHub whether this is a known issue, or that this is something caused by your project setup.

user_2661430
Related