我是否可以使用不在.NET Framework上的旧版DLL创建NuGet包（或其他包）？

Question

We have a bunch of legacy dll's (basically could be anything, some are old fortran, some .NET) and we want to move them to Azure Artifacts. Can I create NuGet packages from these legacy dll's that are not based on .NET (like the Fortran ones) by themselves.

I've already tried creating the NuGet packages, but I get warnings on my dependencies because it looks like they are trying to load the packages on a .NET framework. Is the only real workaround here to build a .NET say class library or something, then reference the dll through that, and create a NuGet package with that library and just add the legacy dll's as references?

Answer 1

Can I create a NuGet package (or other package) with legacy dll's that are not on a .NET Framework?

The answer is yes.

You could target those legacy dlls to the tools folder instead of the lib folder. like:

<files>
    <file src="legacy\*.dll" target="Tools" />
    <!-- Other files -->
</files>

Then pack this .nuspec file when you build the pipeline, those legacy dlls are located in the tools folder, which will not add as references.

Check the From a convention-based working directory for some details.

Hope this helps.

Answer 2

I assume what you mean is that your managed code is usng DllImport attributes to call native code, which in the .NET ecosystem is called Platform Invoke, or P/Invoke. I mention this because if you googled terms around P/Invoke and nuget you probably would have had better luck finding existint stack overflow questions, blog posts and so on. For this reason it's useful to try to find out the official or commonly used names of the features you use, so you know what to search for. Unfortunately I don't think the NuGet team has any docs on this scenario at the moment.

SDK style projects support the runtime\\ directory in the package, although I think that's somewhat undocumented as well. I don't know about traditional projects using PackageReference (PR), but packages.config (PC) definately does not support runtimes\\ . For PC projects, the package author typically (always?) includes build targets to copy the native assemblies after build. In the package, the native dlls are elsewhere, often the author puts them in the build directory next to the targets, but I think I've also seen the targets copy from the runtime directory so that the package supports both PC and SDK style projects.

I suggest you try to think of some commonly used native libraries that have .NET bindings and see how the package works ( nupkg is just a zip renamed). My guesses would be sqlite or curl, or how asp.net core's kestrel web server bundles libuv (or did in earlier versions if it no longer does). I'm on vacation at the moment, so don't have the motivation to dig deep myself.