我们有一堆旧版 dll（基本上可以是任何东西，有些是旧的 fortran，有些是 .NET），我们希望将它们移动到 Azure Artifacts。我可以自己从这些不基于 .NET（如 Fortran 的）的旧版 dll 中创建 NuGet 包吗？
我已经尝试过创建 NuGet 包，但我收到了关于我的依赖项的警告，因为看起来他们正试图在 .NET 框架上加载包。这里唯一真正的解决方法是构建一个 .NET 类库或其他东西，然后通过它引用 dll，并使用该库创建一个 NuGet 包并添加旧版 dll 作为引用？
我假设您的意思是您的托管代码是使用DllImport属性来调用本机代码，在 .NET 生态系统中称为平台调用或 P/Invoke。我之所以提到这一点，是因为如果您在 P/Invoke 和 nuget 周围搜索术语，您可能会更幸运地找到存在的堆栈溢出问题、博客文章等。出于这个原因，尝试找出您使用的功能的官方名称或常用名称很有用，这样您就知道要搜索什么。不幸的是，我认为 NuGet 团队目前没有关于这种情况的任何文档。
SDK 风格的项目支持runtime\包中的目录，尽管我认为这也有点无证。我不知道使用PackageReference（PR）的传统项目，但packages.config（PC）肯定不支持runtimes\. 对于 PC 项目，包作者通常（总是？）包含构建目标以在构建后复制本机程序集。在包中，本机 dll 位于其他地方，通常作者将它们放在build目标旁边的目录中，但我想我也看到了目标从runtime目录中复制，因此该包同时支持 PC 和 SDK 风格的项目。
我建议您尝试考虑一些具有 .NET 绑定的常用本机库，并查看包的工作原理（nupkg只是zip重命名）。我的猜测是 sqlite 或 curl，或者 asp.net core 的 kestrel web 服务器如何捆绑 libuv（或者如果不再这样做，则在早期版本中捆绑）。我现在正在度假，所以没有动力深入挖掘自己。
我可以使用不在 .NET Framework 上的旧版 dll 创建 NuGet 包（或其他包）吗？
答案是肯定的。
您可以将这些旧版 dll 定位到 tools 文件夹而不是 lib 文件夹。喜欢：
<files>
<file src="legacy\*.dll" target="Tools" />
<!-- Other files -->
</files>
然后在构建管道时打包这个.nuspec文件，那些遗留的dll位于tools文件夹中，不会添加为引用。
检查来自基于约定的工作目录以获取一些详细信息。
希望这可以帮助。