Change:
If you ever need to update the dependencies of a package, you instead do * `nix-build -A package.fetch-deps` to generate the update script for `package` <del> * Run `./result deps.nix` to regenerate the lockfile to `deps.nix`, keep in mind if a location isn't provided, it will write to a temporary path instead * Finally, move the file where needed and look at its contents to confirm it has updated the dependencies. </del> <ins> * Run `./result` to regenerate the lockfile to the path passed for `nugetDeps` (keep in mind if it can't be resolved to a local path, the script will write to `$1` or a temporary path instead) * Finally, ensure the correct file was written and the derivation can be built. </ins>

Discussion:
Hey , thanks for working on the dotnet stuff, this is about my first experience trying to use it. I'm not familiar with the C# ecosystem in general so this is my first real experience with it. This is too complicated just to get a fetch-deps script the first time you're trying to package a dotnet package: At least setting nugetDeps to empty is mentioned by the documentation but needing to use toFile is unintuitive. The documentation says to "set it to the empty string" (which errors, so it's "wrong"). It would be much friendlier if there was a more direct way to get something. Also, I found nuget-to-nix way before I found fetch-deps, which is suboptimal. fetch-deps should be easier to find than nuget-to-nix! Does fetch-deps even need to be defined in passthru? The only thing it seems to use as a parameter is the package name. Some things I tried:
Up, I can't figure out how to get this script… did you manage to use the script? Edit: I found it this way: being the package I'm working on. Edit2: correct a typo spot below
Is this the shortest way to get this script? I'd like to add this explicit step in nixpkgs' manual
Yeah, thats the shortest way to get the fetch-deps script, if the package isn't part of nixpkgs. If you have any ideas how to update the manual to make it more clear , go for it. The dotnet related stuff is in After documentation updates we can close this issue.
How about extracting the shell script to somewhere else, maybe , and having just call that with the source dir as a shell argument? That way the script could be used as the first step of packaging, before even making an expression file. Unrelated, running the shell script currently causes 800 MiB (half the closure!) of packages to be downloaded from NuGet, most of which seem to be native variants for every TFM. If this is just a blocklist for what ends up in (the codegen output), can it strip the context i.e. ? The same is already in the shell script's closure.

This still has the same issue where needs to be defined .... to generate the file to put into :facepalm: (And no, not even the hack mentioned above works.)
Indeed, I don't remember what did I put as a placeholder for attribute :shrug:
I've made , which fixes the problems you encountered with - you should be able to run when is set to . I've also updated docs to hopefully make it more clear on how to generate the file. - good suggestion on the optimizations, they are unfortunately impossible now with changes to how the sdk-specific dependencies are structured.
This didn't work for me. I had to set it to an empty string to allow building of From what I can tell, just building doesn't actually generate the file. You must run the script output by that build. Unfortunately, when using this with a flake you can't just run , since this script isn't created with a directory. So instead you need to run the following to generate the file. I don't understand but maybe that's because I'm not experienced with dotnet at all...
You shouldn't need to run manually, but if you do you need to pass in the dir you've restored the packages to, which is hopefully not the CWD. For example:
I only tried because the passthru wasn’t working and the script was mentioned in the manual. Thanks for clarifying.
I went ahead and updated DotNET wiki with some of my findings from this and other threads.
Since I am also quite a noob with Nix derivations and system in general, I also ended up resorting to directly calling as suggested above. It is much more straightforward. Thanks, !
I've partially reverted your edits to so it reflects the intended method. As noted above, it must be to init, not . I'll submit a PR for the manual if it hasn't been fixed already. If you push your code somewhere I could review it for you. is now in a good state, comparable to Python, Rust, etc., and hacks are only needed for unorthodox setups.
this is probably not the best place to discuss it.

You probably have not noticed it, but I completely removed method from the wiki, because in comparison to it wasted me over 1h trying to get it working and eventually I gave up alltogether while worked the first time without any shenanigans with nix build system. Unless there is some clear advantage to I think it should be completely retired. Consequentially, I think wiki should say to put and tell the reader to use and never even mention or in the first place. The same applies to documentation.
seriously, the script as you put in wiki is not going to work for standalone packages that are not part of , not to mention the need to sometimes . E.g. it is not universal, so it is going to confuse people. Given that only needs a csproj to work, it should be the preferred way. Why do you insist on bringing the back? As far as I can see it does not have any advantages over whatsoever and has multihour pitfalls in setting it up.
What are you talking about? It does work for expressions outside of Nixpkgs; I wrote one in order to verify how it worked before editing the article. Obviously it involved an to get things like . The way you run the script is the same, it's just whatever attribute path you'd normally use + , since it's in . If your expression isn't nested then it's just . The advantage is that it's all automated, even identifying and overwriting the file passed for . You're asserting that your experience matches everyone else's and that the documentation is therefore incorrect, but no-one else has spoken up about it.
Look, I know you are a volunteer, and I am guessing you put work in the , but I am not claiming documentation is incorrect. I am claiming tool is far more superior to in practical use, and therefore the should be removed from documentation because unlike it is very confusing thing to use, and why would you want to send people do a confusing thing vs a straightforward thing? I am not quite sure what is more automated vs running . The latter only needs a temporary directory and creating and removing it is right there in the suggestion. Half of this thread is about this. See: There's even a facepalm from another frustrated user. This is another history of struggle.

It even tells that they had the struggle because they tried to use because it was what "the manual" (which probably is either the docs thingie or the wiki) told them to do. Same in my case. On the contrary since you comment nobody complained about it. In fact it worked for me with no setup or any prior knowledge of any kind, and seemed to have worked for adamcstephens too.
All of that was before it was fixed and properly documented—I think 23.11 was the first release in which the .NET builder and helpers worked well, so it's still quite young. (And no I haven't really contributed anything, but I have put many hours into .) My intent with changing the wiki was to be consistent, so that everyone uses the same convention for NuGet deps and hopefully we can avoid confusion going forward. I left the method there as a fallback. One could just as easily copy a from an existing project and then run the script, overwriting it.
But I came after 23.11 and still struggled. For instance: Well guess what? Nowhere do wiki or docs say you have to put your in a . Guess what number 2? In repository majority of the primary package files are instead called , including the one I hoped to use as example: . So if you are following their convention (which I did), the current suggestion in the wiki is basically broken. Again, you are not listening. If you carefully set up it may work. But that's not the point. The point is that you don't need to carefully set up . It works well straight away. P.S. Also, naming the deps file would help spot .NET projects in nixpkgs, which would be very helpful for discovery.
That error message isn't from anything .NET-related though, it's from the Nix CLI. The .NET section of the manual makes the (IMO fair) assumption that you're familiar with these more fundamental concepts: Nixpkgs' by-name is its own convention which doesn't affect development outside of Nixpkgs. If you wanted to keep the filename then you'd need to pass .

Perhaps the docs for packaging .NET apps could be made clearer for those not already well-versed in Nix, but I don't think going back to manual invocation would be an improvement on the whole.
In any case my frustration at the time was due to the mismatch between documentation and code behaviour, not the fact that you have to be careful in the steps. (Pretty much everything in nixpkgs requires careful attention to the steps :upsidedownface:) . I tried at the time (with my best effort, having zero knowledge) and ended up with the same error; though obviously it was user error, it's certainly not a foolproof script that "just works". Also, I should note, uses + anyway: So as was said, is a more automated way to achieve the same end result.
I keep hearing that, but you are not really giving any arguments. In fact in your own comment you provide an argument in favor of : ".NET section of the manual makes the (IMO fair) assumption that you're familiar with these more fundamental concepts". This dependency is completely unnecessary.
We need to know nix to work with it effectively; the nixpkgs manual will not provide a primer on how to use the basics of nix. And the docs issue is being looked at in . So let's take a breather instead of arguing which method you prefer, both methods are doing the same thing.
Here's an argument by analogy if a straight up simplification argument does not convince you. Prior to .NET Core the .csproj files looked like this: (I'm not even gonna paste it here, cause it is so obnoxious). Now they look like this: The crucial difference between the two is that most people developing C# code do not and should not care about intricacies of MSBuild unless they really need it. Simple projects should be straightforward. And most projects should be simple. If you remember, was even a separate file! I was writing above before I saw your comment, and it still stands. No. You don't need to know Nix. Like you might not know ARM64 assembly to write Swift for iOS. And you don't need to know how exactly a is implemented internally. There are abstraction layers and build tooling for .NET projects on Nix is one of them.

Hey, I am arguing for the sake of future of NixOS here. The more people will feel comfortable using it, the better tools it will get. It is a perpetual loop. If you want that, you should help new people onboard, and based on my experience as a .NET dev and as a human, not everyone new to NixOS would sit for 2h+ trying to figure out how to build a trivial .NET package. Many would just turn away after a few tries.
I think the change to is also bad, because it introduces yet another dependency, and does not link an instruction to get it. What was wrong with trying to build and getting the hash from the log?
The Nixpkgs manual has a brief section explaining that you're slightly more susceptible to MITM attacks if you fetch twice, and until recently it recommended using a prefetch tool, but in it looks like passing is now the recommended method. Which is probably what most people were already doing. re: improving the experience for new Nix users, I like the direction and are going in.
I am all for simplifying (im)porting things. But we should not let perfect be the enemy of better. BTW, I figured out running ASP.NET project as systemd service and updated wiki.