ASP.NET Core application compiles but can't load Microsoft.AspNetCore at runtime

huangapple go评论77阅读模式
英文:

ASP.NET Core application compiles but can't load Microsoft.AspNetCore at runtime

问题

I have a class library project targeting .NET 7 which needs to self-host ASP.NET Core Web API.

我有一个针对.NET 7的类库项目,需要自托管ASP.NET Core Web API。

I added a reference to Microsoft.AspNetCore.App framework:

我添加了对 Microsoft.AspNetCore.App 框架的引用:

<FrameworkReference Include="Microsoft.AspNetCore.App"/>

as well as some Microsoft.AspNetCore.* nuget packages. In project dependencies list I see that framework assemblies are properly found and resolved from C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\7.0.5\ref\net7.0\\:

以及一些 Microsoft.AspNetCore.* NuGet 包。在项目依赖列表中,我看到框架程序集从 C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\7.0.5\ref\net7.0\\ 正确地找到并解析:

ASP.NET Core application compiles but can't load Microsoft.AspNetCore at runtime

ASP.NET Core application compiles but can't load Microsoft.AspNetCore at runtime

The project compiles with no issues. I see that dlls from nuget packages are copied to the binary output folder, while framework dlls no. This is probably correct.

该项目编译没有问题。我看到来自 NuGet 包的 DLL 被复制到二进制输出文件夹,而框架的 DLL 没有。这可能是正确的。

When I run the application I get an exception

当我运行应用程序时,我收到一个异常:

> System.IO.FileNotFoundException: 'Could not load file or assembly 'Microsoft.AspNetCore, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.'

> System.IO.FileNotFoundException: '无法加载文件或程序集 'Microsoft.AspNetCore, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'。系统找不到指定的文件。'

If, just to check, I manually copy the dll to the output folder, the exception disappears. Obviously it doesn't find framework dlls at runtime.

如果为了检查,我手动将 DLL 复制到输出文件夹,异常就消失了。显然,在运行时它找不到框架的 DLL。

Does anyone know what the reason could be, and what is the proper approach to shared framework dependencies management?

有人知道可能的原因是什么,以及共享框架依赖项管理的正确方法是什么吗?

UPD: I digged into the code deeper (it is originally not mine and gets into net 4 times) and it is trickier than originally looks. The console executable in its config file has a custom config section. So far so good, but the section has a field of type Type. Which in a config file refers to a fully quantified type name mentioning the assembly in a binary folder. Which is loaded when configuration is loaded and the Type object is created. I guess Type.GetType method loads it. That assembly directly references the assembly in question which at this moment is loaded too. This all goes flawlessly but at a certain moment a method is called which needs objects from Microsoft.AspNetCore.* packages which in turn reference Microsoft.AspNetCore.dll from a framework which at that moment it can't find. And it explodes. But if the framework dll is in a binary folder - no pb.

我深入研究了代码(它最初不是我的,而是进入了四次网络),比起最初的样子更加棘手。控制台可执行文件在其配置文件中有一个自定义配置部分。到目前为止,一切都很好,但是该部分具有 Type 类型的字段。在配置文件中,这个字段引用了一个完全合格的类型名称,其中提到了二进制文件夹中的程序集。当加载配置并创建 Type 对象时,该程序集被加载。我猜测是 Type.GetType 方法加载了它。该程序集直接引用了此时也加载的相关程序集。一切都进行得很顺利,但在某一时刻,调用了一个需要来自 Microsoft.AspNetCore.* 包的对象的方法,这些包又引用了一个此时无法找到的框架的 Microsoft.AspNetCore.dll。然后程序崩溃了。但如果框架的 DLL 在二进制文件夹中 - 就没有问题。

I still don't understand how framework dlls should be treated. In many places it is said: "consider them like nuget packages, but local, no need to download". But in this case I may need to copy them locally. Do I?

我仍然不明白应该如何处理框架的 DLL。在许多地方都说:"将它们视为 NuGet 包,但是本地的,不需要下载"。但在这种情况下,我可能需要将它们复制到本地。是吗?

英文:

I have a class library project targeting .NET 7 which needs to self-host ASP.NET Core Web API.

I added a reference to Microsoft.AspNetCore.App framework:

&lt;FrameworkReference Include=&quot;Microsoft.AspNetCore.App&quot;/&gt;

as well as some Microsoft.AspNetCore.* nuget packages. In project dependencies list I see that framework assemblies are properly found and resolved from C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\7.0.5\ref\net7.0\\:

ASP.NET Core application compiles but can't load Microsoft.AspNetCore at runtime

The project compiles with no issues. I see that dlls from nuget packages are copied to the binary output folder, while framework dlls no. This is probably correct.

When I run the application I get an exception

> System.IO.FileNotFoundException: 'Could not load file or assembly 'Microsoft.AspNetCore, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.'

If, just to check, I manually copy the dll to the output folder, the exception disappears. Obviously it doesn't find framework dlls at runtime.

Does anyone know what the reason could be, and what is the proper approach to shared framework dependencies management?

UPD:
I digged into the code deeper (it is originally not mine and gets into net 4 times) and it is trickier than originally looks.
The console executable in its config file has a custom config section. So far so good, but the section has a field of type Type. Which in a config file refers to a fully quantified type name mentioning the assembly in a binary folder. Which is loaded when configuration is loaded and the Type object is created. I guess Type.GetType method loads it. That assembly directly references the assembly in question which at this moment is loaded too. This all goes flawlessly but at a certain moment a method is called which needs objects from Microsoft.AspNetCore.* packages which in turn reference Microsoft.AspNetCore.dll from a framework which at that moment it can't find. And it explodes. But if the framework dll is in a binary folder - no pb.

I still don't understand how framework dlls should be treated. In many places it is said: "consider them like nuget packages, but local, no need to download". But in this case I may need to copy them locally. Do I?

答案1

得分: 1

I had the same problem with a C++/CLI Project (only .Net 6 as Target) depending on a C# ASP.NET Core library.

The C++/CLI Project was not able to recognize the dependencies of my C# Project and was thus not able to create the correct .runtimeconfig.json. Since the runtime Dependencies were not correct.

The Documentation regarding the behavior of the file was helpful to understand the Problem runtimeconfig.json.

My solution was to add the relevant information to a runtimeconfig.template.json File in the Project-Directory of my C++/CLI-Project. The Description on how to do that is mentioned here.

My new runtimeconfig.template.json:

{
"frameworks": [
{
"name": "Microsoft.AspNetCore.App",
"version": "6.0.0"
}
]
}

英文:

I had the same problem with an C++/CLI Project (only .Net 6 as Target) depending on a C# ASP.NET Core library.

The C++/CLI Project was not able to recognice the dependencies of my C# Project and was thus not able to create the correct <Projectname>.runtimeconfig.json. Since the runtime Dependencies were not correct.

The Documentation regarding the behaviour of the file was helpful to understand the Problem runtimeconfig.json.

My solution was to add the relevant information to a runtimeconfig.template.json File in the Project-Directory of my C++/CLI-Project. The Discription on how to do that is mentioned here.

My new runtimeconfig.template.json:

{
    &quot;frameworks&quot;: [
        {
            &quot;name&quot;: &quot;Microsoft.AspNetCore.App&quot;,
            &quot;version&quot;: &quot;6.0.0&quot;
        }
    ]
}

答案2

得分: 0

问题已通过以下问题得到解决:

https://stackoverflow.com/questions/68951383/how-to-use-the-asp-net-core-shared-framework-correctly-or-how-to-use-its-assembl

该 DLL 被动态加载,在这种情况下,显然需要向加载程序添加框架引用,以使框架程序集可用。

英文:

The issue was resolved using this question:

https://stackoverflow.com/questions/68951383/how-to-use-the-asp-net-core-shared-framework-correctly-or-how-to-use-its-assembl

The dll was loaded dynamically and in this case in is obviously necessary to add a framework reference to the loader application to make framework assemblies available.

huangapple
  • 本文由 发表于 2023年5月25日 23:21:16
  • 转载请务必保留本文链接:https://go.coder-hub.com/76333917.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定