Dotnet MAUI workload

.NET has the concept of workloads, which you can install alongside the SDK using dotnet workload install. This doesn’t work in Nix-land, because the SDK is not writeable.

There’s a very simple change one could make to install a workload such as the MAUI workload: put the following in build-dotnet.nix.

  postInstall = ''
    if [ ! -w "$HOME" ]; then
      export HOME=$(mktemp -d) # Dotnet expects a writable home directory for its configuration files
    $out/bin/dotnet workload install maui

But this is very impure. What happens behind the scenes is a whole bunch of NuGet downloads (at arbitrary versions, all specified in a WorkloadManifest.json file which is itself contained within a NuGet package), installing into ${dotnet}/packs.

It’s going to be a massive pain to do this in a version-locked way, I think, because dotnet workload install simply doesn’t care about reproducibility. I can just about create a list of [some of the] required packs and their hashes - e.g. I produced this text file with this shell script - but at this point I’m basically rewriting dotnet workload install in Bash, and I know I haven’t found every edge case yet (since for example the list I generated is not as big as the list that dotnet workload install actually ends up installing).

I guess what I’ll end up doing is making an overlay which adds the above impure post-install script and then move on with my life, but can anyone think of an easier/principled way to do this, e.g. that will allow it to go into nixpkgs?

I did proof of concept a few months that allowed you to declaratively install workloads. It lost momentum because there is a ton of JSON you have to parse to find all the dependencies, and it lost momentum. I can post a gist of the attempt if someone is interested in it. The hard part is taking the manifests and turning them into nix expressions. You also can’t use the current capability to compose .NET environments because it will try to resolve them relative to the .NET installation path and not the symlinked environment that was created.

As a workaround, if the .NET packages in nix added a file named userlocal at at /metadata/workloads/<sdkfeatureband>/userlocal, all workload installs would go to your home folder. See this PR for the change that added support for local installs.

Here is the gist. It’s a flake.nix and pretty hacky. I had wanted to try out Xamarin.Mac for .NET 6. The part it doesn’t do, and the part that made me give up on it because of the scope was parsing the manifests.

What you have to do is run dotnet workload update --print-download-link-only --sdk-version <manifest version> to get the list of workload manifests for your .NET SDK. You then have to download the NuGet packages, extract their manifests, and do that recursively to find all of the dependencies. None of this is impossible to do, but I gave up because trying to parse JSON in bash sucks (even with jq), and I just wanted to learn Mac/iOS development (I ended up going with SwiftUI).

1 Like

WIP is - thanks very much for your gist, that has been extremely helpful!

To my extreme surprise, this is now in a (very tenuously) working state: I successfully built a MAUI example for every OS except Android. Android was always going to be a non-starter because nixpkgs lacks an Android SDK on darwin-aarch64.

The next steps are to productionise and document that PR.

hi @Patrick thanks for your effort! do you think it would be possible to build MAUI Android on NixOS with your PR? Looking to shift towards NixOS on my new workstation, but part of my workflow is tied to MAUI at the moment, so looking for advice before I dive in.

Yeah, this should Just Work, although there are a number of extremely rough edges (not to mention what seems to be an actual bug in composition of workloads). The only reason I can’t build Android is because I can’t get the SDK on darwin-aarch64.

@reckenrode Do you mind me MIT-licensing my attempt? It’s a derivative work of your gist.

@reckenrode Do you mind me MIT-licensing my attempt? It’s a derivative work of your gist.

Go right ahead; that’s perfectly fine. I updated the gist with a SPDX line to indicate that it’s MIT-licensed.

1 Like

I’ve merged Proof of concept (#1) · Smaug123/nix-maui@e79c93f · GitHub into main; it’s still no more than a pile of gruesome hacks, but at least it’s now got the bare minimum documentation you might need to try it yourself.

1 Like