0

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?

biggfu444
  • 61
  • 1
  • 5
  • how do you imagine users of your package using it? Say you packed some fortran code or dll or whatever in a package, who is going to use that package? Another fortran user? how will they aquire it? how will the build system know to include the package's contents as part of the build? Once these questions are answered, knowing how to pack becomes easy, or at least easier. – zivkan May 25 '19 at 08:19
  • we just want to use the package as kind of like a storage for the dll's, the dll's don't need to be referenced from code like a traditional nuget package, the actual dll just needs to be in the correct place, so it's used by our .net code but not as an actual dependency – biggfu444 May 28 '19 at 11:09

2 Answers2

0

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.

enter image description here

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • Okay so another question I guess, if we want to store these for people to bring down locally, say install the nuget package when they clone the repo, where would it put the dll's in the nuget package if they are in the tools folder? – biggfu444 May 28 '19 at 11:50
  • @biggfu444, In the `\packages` folder of the solution folder. Then you can add those dll manually when you need. – Leo Liu May 28 '19 at 11:56
  • okay so our code is written to basically expect the dll's to be in the same folder that the exe of our project is run from, so I don't want our devs to necessarily have to move the dll's manually when they want to test, we just want them in the correct folder, I feel like in the pipeline I can edit the NuGet restore step to point to the correct path, but not sure about locally. – biggfu444 May 28 '19 at 12:08
  • @biggfu444, If you don't want our devs to necessarily have to move the dll's manually when they want to test, you need set a task in your nuget package to copy those dll file into the the same folder that the exe of the project run from, check my another thread for details:https://stackoverflow.com/questions/44747744/how-can-i-set-the-copy-to-output-directory-property-in-my-nuspec-file/44752745#44752745 – Leo Liu May 29 '19 at 01:29
0

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.

zivkan
  • 12,793
  • 2
  • 34
  • 51