NuGet package now requires running a project in .NET Standard/.NET Framework. 3.6.5 did not have such a limitation

[stunney]

In 3.6.X, all of the binaries were crunched into a single DLL (GitVersionTask.dll) during the build process. This allowed the nuget package to be installed on Managed AND Native projects. With the addition of dependencies into the nuspec, Native projects cannot install the package.

If not going back to re-packing the binaries into a single DLL, please find a way to work around the crappy NuGet forced limitation trying to match a target project with a development (build) dependency.

[JakeGinnivan]

This may be resolvable by doing something similar to ILRepackGitVersionExe which is in the Portable-Package task in build.cake inside GitVersionCore-Package. Thoughts? Interested in giving this a go?

[dazinator]

Not fully understanding this but maybe I can add some info. The NET desktop version of gitversiontask.dll used to have its dependencies ILMerged thats true. Now they are just included in the nuget package alongside the assembly itself. We did some testing with msbuild, and when msbuild for desktop (not dotnet cli) builds a proj file with targets that load the .net framework version of the gitversiontask assembly from the nuget package, msbuild was clever enough to resolve its dependencies from the same base bath (i.e inside the nuget package) so in this case ILMerging them into the same assembly didnt seem a necessary step anymore (for this scenario anyway!) they just needed to live alongside on disk. For the dotnet cli version of gitversiontask, there is no ILMerge equivalent for the dotnetcore stack. Instead UtilPack handles restoring and resolving dependencies of the build task through a nuget restore the first time its used in a dotnet.exe build worker process.
So the bit I am unclear on is your usage scenario - I dont have any experience with native projects and gitversion. Are you using msbuild? Do you have a proj file? Are you adding gitversiontask to the proj file as a nuget package?

[dazinator]

UtilPack dependency currently needs to stay as a dependency listed in the .nuspec file, even if we end up ILMerging all of the dependencies again for the desktop version. Just be wary of this. It's because we rely on UtilPack's msbuild task factory to load and execute our task now. This decouples us from the platform, but it does require that the UtilPack package is installed. The only way to ensure the utilpack package is installed, is to list it as a dependency in the nuspec. If we remove this entry, the current targets that rely on util pack task factory won't work, unless, the user happens to already have the utilpack package in their nuget package cache. On a clean environment without utilpack already in the package cache, it would fail.

With this taken into account, it would be better to understand this "native" project use case and the nuget limitation a little more. Perhaps there is another workaround.

[dazinator]

More background about that issue can be found here: stazz/UtilPack#24
more specifically - this comment: stazz/UtilPack#24 (comment)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.