Closed TeaDrivenDev closed 4 years ago
Hi there @TeaDrivenDev, thanks a lot for taking a stab at the situation. I am looking at the changes in the code and they look good but it seems that the newly generated nuspec file doesn't allow for multi-targeting, is that the case here?
No, that works fine (package pushed to and consumed from MyGet):
The dependencies are only listed once because unlike dotnet pack
, Paket doesn't split them up by framework when auto-generating them, as they are identical anyway.
Hello @TeaDrivenDev, it took me a while but I finally got around to publish the fix within the PR. Now the version constraint should not allow people to install the package with incompatible versions 😄 thanks a lot for this :pray:
As noted in #45, LiteDB.FSharp is currently incompatible with LiteDB 5.x due to API changes, but it is possible to install them together, as LiteDB.FSharp does not restrict the version range for the
LiteDB
dependency. The user will only learn about the incompatibility at runtime.This PR does the following:
LiteDB.FSharp
via simpledotnet pack
with Paket using a template file to allow for specifying dependency version ranges (This is not possible at this time withdotnet pack
in a project using Paket for its own dependency management, due to fsprojects/Paket#2883.)LiteDB
dependency to 4.1.4 <= x < 5.0Release
configuration and the created package tobin
in the repository root. This seemed more appropriate when not using the built-in package creation withdotnet pack
.Using the Paket template file means that all the package metadata entries have been moved over there. I have not looked into potential ways of having FAKE/Paket transfer the information over from the project file during the build process, as it didn't seem worth the effort. It's still all in one place, just in a different file.
I have tried to keep the resulting
.nuspec
file in the package as close as possible to the previous one.This is the
.nuspec
file currently live on NuGet:This is what is generated by this PR:
The dependencies are filled automatically by Paket, relying on the information in
paket.dependencies
andpaket.references
. This avoids having to maintain them in multiple places, but causes them to be listed only once instead of for each individual platform target. I'm not sure if that might allow installing the package into projects using incompatible platforms, but I think it shouldn't.The files to include in the package are also determined automatically by Paket and are identical to those currently included.
As before, I have not tested publishing the package.