ASP.NET Core 共享第三方依赖库部署的正常打开方式

2年前 (2022) 程序员胖胖胖虎阿
213 0 0

曾经:

写了一篇:

ASP.Net Core on Linux (CentOS7) 共享第三方依赖库部署

当第二次想做相同的事,却遇上了Bug,于是有了第二篇:

ASP.NET Core 共享第三方依赖库部署的Bug(*.deps.json on 2.2.0 or 4.6.0 版本)

然后:

就报告到Github上去了,来来回回和人家交涉了几天:

 

截几个图,给大伙学习一下英文:

我以强悍的中英文双版提交了问题:

Steps to reproduce

I try to put the Microsoft..dll and System..dll togather to a new folder.
以便把(第三方或)系统的和应用的dll分开。
之前花了很长的一段时间研究之后:
I find xxx.deps.json can make it work.
之后我还特意写了篇文章介绍它:https://www.cnblogs.com/cyq1162/p/10542832.html
but today,when i update the Microsoft. Aspnetcore to 2.2.0 version.
it dose not work, and make me crazy.

because it always show me the msg like this:

F:\Code\OpenSource\Aries-GitHub\trunk\Aries.DevFramework\Web.UI_NetCore\bin\Rele ase\PublishOutput>dotnet Web.UI.dll Error: **An assembly specified in the application dependencies manifest (Web.UI.deps.js on) was not found**: package: 'Microsoft.AspNetCore.Authentication.Abstractions', version: '2.2.0 ' path: 'lib/netstandard2.0/Microsoft.AspNetCore.Authentication.Abstractions.d ll'
and the json like this:

"Microsoft.AspNetCore.Authentication.Abstractions/2.2.0": {
        "dependencies": {
          "Microsoft.AspNetCore.Http.Abstractions": "2.2.0",
          "Microsoft.Extensions.Logging.Abstractions": "2.2.0",
          "Microsoft.Extensions.Options": "2.2.0"
        },
        "runtime": {
          "lib/netstandard2.0/Microsoft.AspNetCore.Authentication.Abstractions.dll": {
            "fileVersion": "2.2.0.18316"
          }
        }
      }

我花了N长的时间在检测配置和确定路径的正确性,但结果,却依旧很悲催。
it take me much time to find out the question what it's.
when i try to maike it like this:
Microsoft.AspNetCore.Authentication.Abstractions
Microsoft.AspNetCore.Authentication.Abstractions/2.2.xxx
it work.
就是这样,只要版本号不是2.2.0,它就一切正常。
之后又几次测试,发现版本号是4.6.0也同样有问题。
and then i find the version on /4.6.0 ,it does not work also.
就是这样,版本号三位数,尾数是0的,就提示找不到dll。
how ugly this bug it's.

中英文双语版汇报之后,老外回消息了,它估计看到中文就头大:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

我看了半天,也是一脸头大,于是,我努力再描述一下问题,并打算用截图说明问题:

ok,i try it again.
1、I have a mvc website:http://mvc.taurus.cyqdata.com, it run on CentOS7,at first it deploy like this :

ASP.NET Core 共享第三方依赖库部署的正常打开方式

and now it make it like this by *.deps.json:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

I put the Microsoft.xxx.dll or System.xxx.dll to another folder like package.
how I do that ? I replace all the path lib/netstardardxxxx to my path.

ASP.NET Core 共享第三方依赖库部署的正常打开方式

so it work well at Microsoft.AspNetCore.All 2.0.3 version.
but my question is :when i update to 2.2.0 version,it dose not work.

ASP.NET Core 共享第三方依赖库部署的正常打开方式

if i change the version to anything like 2.2.x,it will work well.
I find it have the same bug on linux and windows. now ,you kown what i say ?

忙碌中,对方又回了一条消息:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

他说他随便折腾一下,没发现问题啊。

我能怎么办?只能把demo双手奉上:

OK,I try it again.
I make a SourceCode and Demo,you can download on (5M) : http://mvc.taurus.cyqdata.com/WebPublish.rar
unrar and "dotnet Taurus.View.dll" on cmd,you will get the error message like:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

and you replace 2.2.0 to 2.2.1 at Taurus.View.deps.json like this,and run again,it will be ok.

ASP.NET Core 共享第三方依赖库部署的正常打开方式

you you need the source code for building, you can download on (917K) : http://mvc.taurus.cyqdata.com/SourceCode.rar

 对方告诉我,没啥问题,本来就是找不到路径文件,另外至于改版本号就变好了的问题,可能真是个bug,然后给我推荐升级到2.2版本:

Thanks a lot.

The immediate failure is caused by a missing file. The Microsoft.AspNetCore.Authentication.Abstraction.dll is in fact not there. So it fails correctly.

If you change the version you effectively corrupt the .deps.json. The entire string Microsoft.AspNetCore.Authentication.Abstraction/2.2.0 is a package identifier, which should exist in the libraries section near the end of the .deps.json file. As is the package section exists. If you change the version it won't find the package. I guess it's a bug that it won't fail in that case, in fact it simply ignores the assembly if it can't find the matching package section. This is definitely not expected, but I doubt we can fix it (if somebody relies on this behavior we would break them).

The app runs without the assembly just fine, at least the startup as I assume it doesn't need it. If it would run into code which needs it, it would fail at runtime.

Note that when I built it from source, it worked without any modifications (as the file was present).

As for the number of additional files in the app. I took your solution, changed all projects to target netcoreapp2.2 (since you're trying to use ASP.NET Core 2.2, it makes sense to target 2.2 for everything). And then I added this line to the Taurus.View_NetCore.csproj

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

Now when I publish the solution, I get only about 20 files in the output. Basically just the application plus 2 additional System.* assemblies.

我感觉它没发现我说的重点,于是用翻译快速上了一段文字:

To facilitate the presentation of the problem,
I put Microsoft. AspNetCore. Authentication. Abstraction. dll in the Lib directory, and then the path of the configuration file was modified to point to it, so the file is supposed to exist, even if it is not used in the project, but the direction of the path is right, I don't know if you notice it.

Version number is no problem, after all, it is automatically generated by the system.


In addition, the 2.2.0 I mentioned above refers to the Nuget version package of ASPNET Core. It is not. NetApp version upgraded to 2.2. App version is still using 2.1.

对方开始慒B了,说了一堆,然后还是推荐我上2.2版本:

I'm sorry - I don't understand your comment about the version number not being a problem. It is by design that the run fails if .deps.json refers to a file which it can't find, so in your repro, the fact that it fails is expected.
I do agree that the fact that if the version number is changed (and thus doesn't match the package in the libraries section) the run will simply ignore the problem and the file and just continue is a bug. I have my doubts we would fix it though as it might break people.
By doing this the .deps.json becomes invalid, and the current error checking is somewhat simplistic on .deps.json - this is basically expected, as the .deps.json is not meant to be used by humans - it is meant to be machine generated, and thus it's reasonable to expect correct input.

As for ASPNET Core versioning - I'm honestly surprised you can even run ASP.NET 2.2 on .NET Core 2.1, but I'm no expert in ASP.NET deployment.

To explain why you get so many files in the output:

    • Normally .NET Core apps rely on "shared frameworks" which live in the global installed location. These are referenced from the .runtimeconfig.json. You can see that your app references Microsoft.NETCore.App there, which is the root framework (contains CoreCLR and CoreFX).
    • ASP.NET itself contains lot of assemblies. Again by default this will be recognized as a "shared framework" and you would get a reference to Microsoft.AspNet.Core.App in your .runtimeconfig.json.
    • If one of the referenced shared frameworks contains the required assembly, then that assembly is not included in the output of the app. So by default you don't get pretty much any "Microsoft." or "System." assemblies in the app as those are all in the shared frameworks.
    • In your case I can only assume the build system is confused a bit - you require ASPNET Core 2.2 on .NET Core 2.1. Since no such shared framework exists, it probably just brings all the ASP.NET assemblies into the app. By migrating all projects to .NET Core 2.2 you give the build system a way to rely on shared frameworks instead. For some reason the PackageReference to ASPNET also has to be in the main project for this to work (no idea why).
    • Once that is done, your app should have a reference to Microsoft.AspNet.Core.App version 2.2 which in turn has a reference to Microsoft.NETCore.App version 2.2. And so the build system will be able to avoid all the system assemblies in the app and solely rely on the shared frameworks.

我感觉这问题似乎要无解,又要重新描述问题了:

i mean,when you down from http://mvc.taurus.cyqdata.com/WebPublish.rar
and unrar , you will find lib/Microsoft. AspNetCore. Authentication. Abstraction. dll and this dll version is 2.2.0. the file is exists.
and the Taurus.View.deps.json , you look,it point to the same path.
ASP.NET Core 共享第三方依赖库部署的正常打开方式
so,tell me ,why can't find it ,the related path is error ? 

这此,对方终于知道我要表达或关注点在什么地方了:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

不过它始终没Get到我的点,或者我没有Get到它的点,我只能强调,我上一版本V2.0.3是OK的,要不要弄个正常的Demo过去?

ASP.NET Core 共享第三方依赖库部署的正常打开方式

它想让我把正常的.runtimeconfig.json文件发给它看看

ASP.NET Core 共享第三方依赖库部署的正常打开方式

于是,我转身向服务器走去,我Down下了2.0.3那个运行正常的runtimeconfig.json文件,打开一看,what X,什么时候多了一行:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

这不是我当年研究失败时留下的东西么,难道它是关键?

于是通过把这个属性加上和关掉,重新运行了一下,XYZ,还真是它的问题,只有配置了这个路径,deps.json上的路径才能生效

故事的结局:

感觉要分手了,给它回了最后一段话:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

好聚好散,但它还是坚持让我升级到NetCore 2.2版本:

ASP.NET Core 共享第三方依赖库部署的正常打开方式

 交涉地址:https://github.com/dotnet/core-setup/issues/5588

最后,发现在Github留下问题,还是有点乐趣的~~~

相关文章

暂无评论

暂无评论...