Use a static verison of nuget.build.tasks.pack, use licenseexpression #2574
Conversation
nkolev92
requested review from
dominoFire,
PatoBeltran,
zivkan,
jainaashish and
heng-liu
| @@ -31,6 +31,7 @@ | |||
| <XunitConsoleExePath>$(SolutionPackagesFolder)xunit.runner.console.2.3.1\tools\net452\xunit.console.x86.exe</XunitConsoleExePath> | |||
| <ILMergeExePath>$(SolutionPackagesFolder)ILMerge.2.14.1208\tools\ILMerge.exe</ILMergeExePath> | |||
| <XunitXmlLoggerDirectory>$(SolutionPackagesFolder)XunitXml.TestLogger.2.0.0\build\_common</XunitXmlLoggerDirectory> | |||
| <NuGetBuildTasksPackTargets>$(SolutionPackagesFolder)NuGet.Build.Tasks.Pack.4.9.2\build\NuGet.Build.Tasks.Pack.targets</NuGetBuildTasksPackTargets> | |||
There was a problem hiding this comment.
why can't we just use the one from the current build?
There was a problem hiding this comment.
Kind of breaks the whole repeatability thing. And it only works with build.ps1, not necessarily if you want to pack individual projects.
It also will have file access issues when you are trying to pack the pack tasks package itself.
There was a problem hiding this comment.
I'm not able to follow the repeatability concerns here. What exactly it breaks? why shouldn't this always pack our projects with in-built pack target? It will also add an additional check if our pack target breaks something for normal cases...
Also, not able to see through other concerns, may be it'll be better to talk offline and get clarity.
There was a problem hiding this comment.
I don't see the posting on testing "real scenarios".
What are integration tests for then? The pack scenarios for our solution are basic.
Furthermore we are not ready to conform to the changes in the pack targets immediately.
Say for example we were doing this for 4.9.1.
We'd have to suppress the license url warning in all our projects, just to build our packages the way they used to be built.
If we say wanted to build with license expressions or license file we wouldn't have been able to push because the server would not be ready to handle the new feature yet.
It just adds needless complexity in my opinion.
If you run the pack target with the built assemblies, you'd be trying to copy the current running assembly in which you have all the pack logic. That wouldn't work.
There was a problem hiding this comment.
Discussed offline, we're good here.
Bug
Fixes: First part of NuGet/Home#7629.
Regression: No
If Regression then when did it last work:
If Regression then how are we preventing it in future:
Fix
Details:
Use a repeatable version of the pack target, don't depend on the machine dotnet sdk for packing.
Use LicenseExpression instead of license url.
Testing/Validation
Tests Added: No
Reason for not adding tests:
Validation done: Verified with a script that the packages generated are the same.
I will add a tool that does some validation of the packages after the fact.
fyi @karann-msft @anangaur @rrelyea