Simplest implementation: Build a nuget package with a build for the local target. For nuget we could use the any rid, but I'd like to get a toe in the water for cross compilation and think about how to go from a Rust triple to a .NET rid.

TODO

• Parse Cargo.toml
• Run cargo build
• Convert toml to nuspec
• Build nupkg
• Save nupkg
• Standardise PathBuf/&Path/String/&str/Cow<'a, str> usage
• Add tests for nuget bits

Rather than writing things to the console directly, we should use log, which has more level configuration.

Just tried this on a rust crate where there's a hyphen in the project name, meaning the library name has to be specified to use an underscore. AFAICT there's no way to specify alternative library names in cargo-nuget, so this caused packing to fail, when the generated library wasn't found because it didn't match the project name.

It'd be nice to have a way to specify alternative library names, even if it's just another CLI arg.

It's a more targeted crate type for an exported C API. At the very least it should be accepted as well as dylib. The question is whether it's always the most appropriate crate type to use.

Blocked on:

• #7
• #11
• #12
• #13

netstandard 2.0 is official so we should make sure this library supports netstandard 2.0 packages. It should do, but there might be new versions of the platforms package to support.

See: https://www.microsoft.com/net/download/core

The dotnet tooling is now released, which hopefully fixes some of the problems I've had on Linux lately. It looks like the download URLs have moved again, but there's an install script that constructs them. I'll check it out.

It would be great if this crate supported Tool packages as well. This could be solved by #30 if it was available, but first-class support would be better. I believe this would be detectable by looking for the [[bin]] section or the presence of main.rs (as opposed to lib.rs).

It's not very useful of we're not actually using it. Hopefully a cheeky 2>&1 will be enough to keep AppVeyor happy.

Right now we've got a pack command that builds a binary for the local platform with a loose RID. We should also support cross-compilation, which means thinking about the following in more detail:

• Converting Rust triples into .NET RIDs
• Cross-compilation
• Supplying pre-built Rust libraries for various targets

So something like the following workflow might work:

struct Target { triple: &str, source: TargetSource }
enum TargetSource { Build, File { path: &Path } }

The question then is how to get the target and source from command line, and how to deal with cases where the Rust triple doesn't align with a .NET RID.

You can do cross compilation in Rust with cross, but it doesn't support Windows.

There's also CI templates that produce nice cross-platform binaries, but they require a Travis and AppVeyor build, which might not be suitable for stuff that isn't open-source or already using those systems.

At this stage I'm leaning towards a cross compilation story that will try use cross, and for Windows, expect you're building on a Windows environment. For proper CI, you could use something like trust, then cargo-nuget could consume those artifacts without trying to build itself.

I'm keen to know what other people think, how they might expect cross compilation to be supported.

The current pack is for local builds, which are just for the target mahcine and don't use very specific RIDs. To make this as clear as possible, and cache-bust any previously installed packages with the same version, we should append a -dev{timestamp} tag to packages.

That way there are no special steps needed to get the latest code in dev environments, and differentiates local and cross-platform builds better.

Hi. I was struggling with an issue with a NuGet package created with this incredible tool. I couldn't build a docker image because of it. After an investigation I realized that a proper directory tree isn't created in the nupkg. It just creates a single file with all its directory path inside. Here I'm unzipping the resulting .nupkg and what I get:

geext@LAPTOP-C1938VO5:/mnt/c/Users/geext/source/repos/improc-petrsu/test$ ls
improc_petrsu.0.3.0.nupkg
geext@LAPTOP-C1938VO5:/mnt/c/Users/geext/source/repos/improc-petrsu/test$ unzip improc_petrsu.0.3.0.nupkg
Archive:  improc_petrsu.0.3.0.nupkg
zip-rs
  inflating: _rels\.rels
  inflating: [Content_Types].xml
  inflating: improc_petrsu.nuspec
  inflating: runtimes\linux-x64\native\improc_petrsu.so
  inflating: runtimes\win-x64\native\improc_petrsu.dll
geext@LAPTOP-C1938VO5:/mnt/c/Users/geext/source/repos/improc-petrsu/test$ ls
'[Content_Types].xml'        improc_petrsu.nuspec  'runtimes\linux-x64\native\improc_petrsu.so'
 improc_petrsu.0.3.0.nupkg  '_rels\.rels'          'runtimes\win-x64\native\improc_petrsu.dll'

so as you can see, the native libraries are put into the package with the directories in their names.

Here is a link to my repository: https://gitlab.com/geext/improc-petrsu
You can test it with cargo-nuget pack in the root directroy

I use Windows 10, but the unzipping example above is actually WSL 2 (Debian)

So there are a couple of ways to run cargo-nuget, which should all be tested on major platforms. I think there should be a couple of scenarios captured in containers and tested in CI, including:

• build a package with no arguments
• build a package with relative directories
• build a package with absolute directories

It would be good to have a scalable way to add more scenarios as the tool's complexity increases.

It turns out this library is a fairly handy little tool for collecting platform-specific libraries into a single Nuget package. The cross command doesn't make any assumptions about how those platform-specific libraries are produced. If we accepted metadata from other sources besides a Cargo.toml (possibly even still using TOML as a format) then we'd be able to neatly package up libraries with no Cargo integration at all.

Instead of attempting to build and pack a library when run with no inputs, cargo-nuget should just print some info.

The equivalent of what it does now should be cargo-nuget pack. This gives us more flexibility to add commands in the future and lets users run it and discover the API without it actually trying to do stuff.

I'm having problems with local feeds using the dotnet CLI RC4. I'll confirm if it's just on UNIX or Windows too.

Hey! Thanks for writing this crate!

Our company would like to start writing some of our data heavy processing in rust and we would like to be able to call it from .net core.

How do you feel about the level of stability/quality of the crate?

Are there any examples of passing complex types (structs) and returning complex types?