【问题标题】:Wildcard version project dependencies通配符版本项目依赖
【发布时间】:2019-06-21 13:50:50
【问题描述】:

开始使用 .net 核心。我们在一个文件夹中有很多 dll,其中包含多年来开发的整个软件解决方案。其中一部分开始使用 .net 核心。我们过去常常将带有几个修改过的 dll 的补丁发布到具有递增版本号的生产环境中。 显然 .net core 正在检查依赖 dll 的确切版本,所以当我们发布一个带有 .net core dll 所依赖的修改过的 dll 的补丁时,应用程序将不会开始写入无法加载文件或程序集 xxx.dll,版本 = 1.2 的错误.3.4.

我们使用项目依赖项。 csproj 文件

是否可以覆盖版本检查以仅比较版本的前 2 位数字或完全跳过版本检查(我们在软件中有自己的 dll 版本检查系统)?

【问题讨论】:

  • 我无法在我身边重现同样的问题。在一个解决方案中,我有两个项目(一个是 .net 核心应用程序,另一个是 .net 核心类库)。我将项目引用从应用程序添加到库(1.0.0.0),构建解决方案并将 .net 核心应用程序的输出复制到远程服务器。效果当然很好,然后我修改库中的代码,用2.0.0.0版本构建,把xxx.dll复制到服务器上替换1.0.0.0版本,应用还是可以的,代码修改生效很明显。
  • 你可以查看AssemblyLoadContext.Default.Resolving事件和.deps.json文件的内容,供corehost使用。

标签: c# .net visual-studio .net-core msbuild


【解决方案1】:

强引用(在 .csproj 文件中)如下所示:

<Reference Include="MyLibrary, Version=2.9.4.2, Culture=neutral, PublicKeyToken=85089178b9ac3181, processorArchitecture=MSIL">
  <HintPath>..\lib\lib\net40\MyLibrary.dll</HintPath>
</Reference>

当 DLL 丢失时,您将收到您描述的错误。 为了避免这种情况,您完全删除了版本号。这我称之为弱引用:

<Reference Include="MyLibrary">
  <HintPath>..\lib\lib\net40\MyLibrary.dll</HintPath>
</Reference>

如果你控制一切,那么弱引用就可以了。但要小心这些。 MSBuild 倾向于查看整个计算机。所以最好有一个准确的&lt;HintPath&gt;

【讨论】:

  • 问题不在于 dll 引用,而在于项目引用。
  • ProjectReference 默认情况下很强大,没有办法解决这个问题。您必须停止使用它们,并回到我上面列举的普通旧文件引用。对于您的用例来说,这有点糟糕。也许这是错误的解决方案,您应该接受它并修复您的补丁过程。这似乎更正确。
猜你喜欢
  • 2011-10-17
  • 1970-01-01
  • 2020-06-14
  • 2020-07-24
  • 2011-02-03
  • 2014-07-07
  • 1970-01-01
  • 2019-12-25
  • 1970-01-01
相关资源
最近更新 更多