I’m trying to create new project using the following commands:
dotnet new sln -n TestMe
dotnet new console -lang 'F#' -o SqlTP
dotnet sln add .\SqlTP\SqlTP.fsproj
dotnet new tool-manifest
dotnet tool install paket
dotnet tool restore
dotnet paket init
dotnet paket add FParsec --version 1.1.1 --interactive # I answer Y at the interactive prompt
These commands generates the paket.references in the project directory and all seems well except for the fact that the project does not see the dependency . It does not appear in the package references in VSCode and I can’t use the library.
I tried it using dotnet 5.0.x and 3.1.xxx and got the same result. The thing is that I think I created test project in the past following similar procedure and it worked. Not sure what’s wrong …
You can see the generated projects (both dotnet 3 and 5) of the procedure above (with different dependencies) in this repository.
that’s not quite right: paket supports .net 5 since version 5.250.0, the releases page just shows all releases and the 6.0 prereleases have been more active lately. What’s probably happening is you have to restore after you do the package add in order to trigger the refresh files that VSCode (specifically, ionide) is watching to determine that references have changed.
Sadly this does not help. I tried restoring and building (which should implicitly restore?) and closing/opening the project several times and it doesn’t help. Exactly the same steps with global.json file locking to sdk 3.1.xxx does work.
Paket and Fake are so often in flux and don’t work easily, so I avoid them when possible. In fact, at work, I have never used them. There are probably scenarios where they are worth the effort to learn and troubleshoot them, but so far I’ve been lucky not to have those scenarios.
mmmmm, so how do you handle transient dependencies? Do you just hard code everything? I have zero experience with .Net but in other runtimes that does not support lock files I certainly had problems with the same code produces errors at runtime because of different transient dependencies between builds.
If you’re using PackageReference with NuGet and don’t have wildcards specified, restore is deterministic and so you won’t get a magic package upgrade between builds. There is a lock file of sorts stored in the obj directory. However, it’s not an artifact intended to be checked in with source code. This is a big difference with Paket, since it makes all of that explicit and not just a build artifact. IMO at this point it’s really just a philosophical difference, since Paket makes it explicit and the lock file can only be updated when you explicitly choose to (updating a package version isn’t enough, you need to also update the lock file). In the case of NuGet, it’s still explicit at build time, but you can change a package version and the next build will change the graph,
Well, we have a local Nuget repository, so we control the version(s) in that repository for all our projects. And we don’t mind those packages being years old as long as they still work as expected. But in general I can’t remember ever having a run-time issue due to upgrading a nuget package. I’m sure I’ve had compile-time issues, but could deal with them or just decide not to upgrade the package if possible.
This is stable, yes. Unless you change the version. Older versions of NuGet used to do bad stuff like notice there were updates in the graph of transitive graph of dependencies and update them. Paket was essential for anyone who care about anything to do with dependencies. But now it’s more of a “do what you prefer using” kind of thing, at least to me. I personally like to explicit nature of lock files and so I will often use Paket.
What specific files are being referenced in a nuget package? My tendency when working with really short scripts is to #r reference merely the .dll file in a respective nuget package and then run an .fsx script using FSI.
. It does not appear in the package references in VSCode and I can’t use the library.
.
.