CODEWITHSUNDEEP
.netpackagenugetexecutablepublish
Nick Farsi
Nick Farsi

Reputation: 427

Publish nuget package with executable inside, nuget.org

I'm being a nice guy and want to contribute to nuget.org

I had a task which I could not get to solve using .NET (converting .pdf to .html, but that's not the gist, it could have been any other) but was quite easy to deal with using Python. So I wrote a .py script, turned it into single-file executable, wrote some wrapping in .NET, and there it is, working.

The wrapper basically just unloads the executable somewhere on the hard-drive, calls it via command line arguments and gets the response.

Upvotes: 3

Views: 1527

Answers (1)

thatguy
thatguy

Reputation: 22079

Now how do I go about publishing this nuget with executable inside?

This is common practice. NuGet packages allow for a variety of artifacts, like source files, images, XML files, build scripts for MSBuild, tool executables, PowerShell scripts, as well as any sort of binaries, including libraries and executables.

Is this even allowed?

NuGet is a package manager. As for the packages itself, the description from Microsoft is not very clear about what useful code, or content is.

An essential tool for any modern development platform is a mechanism through which developers can create, share, and consume useful code. Often such code is bundled into "packages" that contain compiled code (as DLLs) along with other content needed in the projects that consume these packages.

Many mainstream NuGet packages contain executables, like for example CefSharp.Common that contains a whole Chromium browser or even Microsoft's own CPPRestSDK, which contains multiple executables for OpenSSL, Boost or Brotli, along with a PowerShell script for copying files and much more. By the way it was the prime example for building native NuGet packages on MSDN.

Is the idea so bad that I scrap the whole thing?

No. Even if it was not intended to package executables from the start, it has grown a common practice. Everyone using NuGet should be aware that they are consuming libraries and other potentially harmful artifacts. How can you be sure that the DLLs you consume are safe either?

Do I somehow explicitly warn users that the library contains an executable which would get copied to their hard-drive?

If you look at the packages above, there is not any notice about the content apart from being a native package. You have to inspect the package or got the correspoding project sites to find that out yourself. Plus, packages containing unwanted artifacts could be shadowed by a cascade of other package dependencies.

What you can do of course is provide a comprehensive description of your package via the description tags in the NuSpec file. This description will be displayed on nuget.org, as well as in most clients.

Provide a link (where?) to the code of the .py script?

You can provide a link to your project site via the projectUrl tag, where you can go into detail and provide your source. Another option is to include it as a content file for reference, but the chance that someone will look at it is small and it does not prove that your executable was built from that script.

And a validation of sorts (how?) that this code is what actually inside the executable?

It all comes down to the question, how can you trust a package? You can't.

Packages can impose a security risk, as they can potentially execute arbitrary code or carry malicious code into your application. You can check all files yourself as a consumer or rely on a source or author that you trust. One way to provide trust is by signing packages to prevent content tampering an ensure package integrity. Again, that does not validate how your executable was built.

Upvotes: 7

Related Questions