4 ms·
Too bad the tooling (e.g. restore, build, package) and (I think) the project files format is still preview. So far, my experience has been that small isolated
by mjgoeke 10y ago
Too bad the tooling (e.g. restore, build, package) and (I think) the project files format is still preview.
So far, my experience has been that small isolated project seem to work fine, but as soon as I try to break a more complex solution out into separate nuget dependencies things start to get hairy.
Nuget dependency versions don't support npm-like syntax, so you can forget about the "^1.0.0.0" notation.
Syntax like "[1.0.0.0-2.0.0.0)" might be supported, but honestly I've been fighting with other issues enough that I can't recall for sure if making the version syntax ugly makes it happy.
Another surprise to those from javascript/npm land is multiple versions of the same library in your dependency tree isn't supported. So you basically need to support redirecting to a commonly supported version (which, without examples showing version ranges, you're back at the version range syntax pains).
If anyone's tackled these pain points I'd love to hear.
- soulnothing 10y agoI'm new to the CLR build system myself, and have sort of gotten stuck on project formatting. The F# side seems to have some newer build systems, and are trying to go towards a simpler build/project system. For dependencies see Paket[1]. It allows versioning, and only the parent dependencies not the entire dependency tree. For building much like Gradle there is FAKE [2]. It's an F# DSL for build tasks, and has type safety etc. But I've seen examples with C# project as well. [1] https://fsprojects.github.io/Paket/getting-started.html https://fsprojects.github.io/Paket/getting-started.html [2] http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/