从 Nuget 包中自动提取本机和托管 DLL

Question

这让我疯狂了几个月，但我仍然无法实现它。我的托管库是从 Nuget 包中提取的，而不是从本地库中提取的。

我们有一堆由另一家公司提供的托管和本地库。 我们同时拥有x86 和x64 版本。为了在 ASP.NET Core 项目中使用它们，我必须创建一个 Nuget 包。

我的架构是：

• 一个 ASP.NET Core 类库，我将其更改为仅针对完整的 .NET Framework。这个项目引用了我的 Nuget 包
• 一个 ASP.NET Core 网站也针对完整的 .NET Framework 并引用类库

当然，最后，我需要将我的本地库提取到网站的正确运行时文件夹（例如：\bin\Debug\net461\win7-x64）。

目前我的解决方案是：

• 将本机库放入 build 文件夹中
• 创建一个targets 文件，将它们复制到$(OutputPath)（甚至不是运行时文件夹）
• 将一些MsBuild命令添加到我网站的xproj，以获取我的$(USERPROFILE)\.nuget\packages\文件夹中的目标文件并执行它
• 复制手动现在在bin文件夹中提取的本机DLL到runtime一个

我尝试使用project.json 中的一些配置将它们直接复制到运行时文件夹（老实说，我不记得我为这部分尝试过的所有事情）但这总是失败。此外，即使我在目标文件中指定了SkipUnchangedFiles="true"，这也会被忽略，并且我的 DLL 在每次构建期间都会复制到我的 bin 文件夹中。

为了实现 DLL 提取，这是一个繁重的过程，现在我真的想摆脱所有 MsBuild 并获得一个更简单的解决方案。

我知道，对于较新版本的 Nuget，它现在能够在本地提取它们，而无需添加自定义 MsBuild 命令的任何帮助。正如here 所写，C# 项目甚至不需要targets 文件

接下来，可能使用 NuGet 包的 C++ 和 JavaScript 项目需要一个 .targets 文件来识别必要的程序集和 winmd 文件。 （C# 和 Visual Basic 项目会自动执行此操作。）

我在浏览器中打开一个选项卡几个月 (original link) 并意识到该资源最近已从 Nuget 网站上删除。它解释了如何使用runtimes 文件夹自动提取本地DLL。但是，正如所解释的那样，我从未能够获得成功的结果。现在这个页面已被删除并被this one 替换，解释很少，根本不谈论这个runtimes 文件夹。

我的猜测是，我应该将 runtimes 文件夹用于本地 DLL，将 lib 文件夹用于托管，但我不能 100% 确定这一点。 （我也应该使用build 文件夹吗？）

我已经尝试了几件事（我不记得尝试了多少次，因为我说过几个月的头痛......）比如this architecture（我不明白这里有什么build/native 和也是runtimes 下的本地文件夹）

我还尝试将here 所述的 .NET 框架版本结构用于我的托管库。

This 似乎也是解决方案的一部分

在创建程序集引用时，编译器会忽略架构。这是一个加载时间概念。如果存在，加载程序将更喜欢特定于架构的引用。

您可以用来生成 AnyCPU 程序集的一个技巧是使用 corflags 从 x86 程序集中删除体系结构。例如：corflags /32BITREQ-MySDK.dll。 Corflags 是 .NET SDK 的一部分，可以在 VS 的开发人员命令提示符中找到。

这就是我所做的，将 x86 和 x64 DLL 都转换为 AnyCPU（不知道它是否对 x64 DLL 有用，但我没有收到错误），然后在我的 Nuget 包中尝试了几种不同的架构，但仍然不工作。

project.json 中没有任何条目的默认运行时是win7-x64，所以我决定明确指定它以防万一

"runtimes": {
    "win7-x64": {}
},

所以这是我在 Nuget 包中的所有尝试使用的运行时标识符。但是我不关心Windows版本。我实际上更喜欢使用 win-x86 或 win-x64，但根据 this page，这似乎是一个无效值

Windows RID

Windows 7 / Windows Server 2008 R2

• win7-x64
• win7-x86

Windows 8 / Windows Server 2012

• win8-x64
• win8-x86
• win8-arm

Windows 8.1 / Windows Server 2012 R2

• win81-x64
• win81-x86
• win81-arm

Windows 10 / Windows Server 2016

• win10-x64
• win10-x86
• win10-arm
• win10-arm64

但是，这个Github source 描述了更多的 RID，那么哪个来源是正确的？

如您所见，这里有很多谜团，主要是因为缺乏文档，甚至不同文档之间存在矛盾。

如果至少我可以有一个工作示例，那么我可以执行我的测试来回答其他问题，例如尝试通用 win-x64 RID，或者看看我是否可以包含一次我的托管库，无论 .NET Framework 版本。

请注意我的特殊上下文：我有一个针对完整 .NET Framework 的 ASP.NET Core 项目

感谢您的回答，我迫切希望让这个简单的事情发挥作用。

Answer 1

我会尽可能详细地解释我所经历的所有痛苦和解决方案。在我的示例中，我使用简单的文本文件 AAA86.txt、AAA64.txt 和 AAAany.txt 而不是原生 DLL 来简单地演示提取过程。

您需要知道的第一件事： 如果您尝试将native NuGet 的体系结构与包含一些托管库的lib 文件夹混合，它将不起作用

在这种情况下，您的托管 DLL 将被复制到项目的输出目录，而不是您的本地目录。

感谢 Jon Skeet，他为我指明了正确的方向，建议我看看 Grpc.Core package。诀窍是创建一个 targets 文件来处理 DLL 提取。

您的目标文件应该包含类似这样的内容

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <ItemGroup Condition=" '$(Platform)' == 'x64' ">
        <Content Include="$(MSBuildThisFileDirectory)..\runtimes\win-x64\native\AAA64.txt">
            <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
            <Link>AAA64.txt</Link>
        </Content>
    </ItemGroup>

    <ItemGroup Condition=" '$(Platform)' == 'x86' OR '$(Platform)' == 'AnyCPU' ">
        <Content Include="$(MSBuildThisFileDirectory)..\runtimes\win-x86\native\AAA86.txt">
            <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
            <Link>AAA86.txt</Link>
        </Content>
    </ItemGroup>

</Project>

还要确保您的.targets 文件与您的AssemblyName 命名相同。所以如果你的程序集的名字是DemoPackage，你的目标文件应该命名为DemoPackage.targets。否则，在另一个项目中引用包时，.targets 文件可能不会被应用。

现在你需要知道的其他一些事情：

1) Visual Studio 根本不关心您选择的设置，它将始终使用虚拟 RID。 （在我的情况下，即使我在 Windows 10 上，我总是以 win7-x64 文件夹结束......）

2)你project.json中的platform setting也完全没用

{
    "buildOptions": {
        "platform": "x64"
    }
}

3)如果您仅设置win和/或win-x64，则在runtimes settings中

"runtimes": {
    "win": {},
    "win-x64": {}
}

Visual Studio 将改为使用 win7-x64。但是，如果您在 Windows 10 计算机上添加 win10-x64，则将使用它

4) 如果您使用这样的通用 RID 编译应用程序

dotnet build -c debug -r win

然后您的targets 文件将收到您机器的架构（在我的情况下为 x64），而不是我所期望的 AnyCPU

5) 如果您遵循架构runtimes/RID/native

6) 在我的包中只有本机库的情况下，选择的 RID 将始终为 win-x64 使用 Visual Studio 构建，正如我告诉你的，运行时文件夹始终是 win7-x64，无论我选择的配置。如果我的包裹中只有一个win RID，那么它会被成功挑选。

编辑：

最后一个有用的提示是，在处理此类任务时，您可能会发现这样打印出正在执行 .targets 文件的当前目录很方便

<Target Name="TestMessage" AfterTargets="Build" >
    <Message Text="***********************************************************" Importance="high"/>
    <Message Text="$(MSBuildThisFileDirectory)" Importance="high"/>
    <Message Text="***********************************************************" Importance="high"/>
</Target>

您的目录将在 Visual Studio 的 Build 输出中打印出来

Answer 2

现在，当您使用dotnet restore 而不是nuget.exe restore 时，本机 DLL 没有被复制到输出目录的问题已经消失。

在我使用 dotnet restore --runtime win-x64 <path_to_the_solution.sln> 时，问题已解决。