Disable packing for source build excluded projects#2106
Conversation
|
FYI @jcagme |
|
This shouldn't be necessary. The entire Pack target is disabled here: https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/Empty.targets#L15. |
|
Agree, a consistent fix would be to add more disables for any other targets that are running and causing failures. (Edit: To clarify, this was assuming the emptying was working correctly, and the issue was |
|
This needs to be investigated more - from the binlog attached to the issue it seems like the default implementation of Pack target was executed. Not sure why. |
|
I'm not following. Today, if I build Arcade... … I get these failures … I looked at the pp file and saw that Empty.targets gets imported before the SDK targets get imported and the SDK targets define Pack. I didn't see that Empty.targets was really doing anything here. |
That's the bug. |
|
The solution is to either set |
|
Yeah :(. This used to work when we imported the Arcade.Sdk directly from the the project I think we should set There doesn't seem to be a way to import our targets after all SDK targets have been imported, nor we can disable importing SDK .targets. @nguerrera any ideas? |
|
Defining |
| <!-- Skip importing NuGet Pack targets from the SDK --> | ||
| <ImportNuGetBuildTasksPackTargetsFromSdk>false</ImportNuGetBuildTasksPackTargetsFromSdk> | ||
| </PropertyGroup> | ||
|
|
There was a problem hiding this comment.
I'd remove <Target Name="Pack"/> line since it's not effective.
Also, I'd add to the comment that NuGet targets is imported by Microsoft.Net.Sdk.targets after this file is, so we can't override Pack target here.
There was a problem hiding this comment.
I can modify the comment.
Given that NuGet.Build.Tasks.Pack.targets defines the "Pack" target, I was concerned that there would be somebody in the chain dependent on that target or trying to run that target and would hit an error related to that target not being defined if we didn't preserve the empty "pack" target. It seems safer to me to just define the empty target here. Perhaps that's overly cautious?
There was a problem hiding this comment.
Actually, you are right. We need the empty Pack target, if we won't import NuGet.Build.Tasks.Pack.targets
|
I'm still getting errors with this change and the build command: |
|
I can do a private build and publish it if you want to validate that way? This works in my local testing but I'm not opposed to getting more validation. |
|
Oh, sorry, that makes sense. Trying that now. |
|
You have to build the package with this change and then update your repo to consume this change use the SDK you just built, and then build. Have you followed those steps? |
|
@crummel , I'll wait to merge this until you've completed your validation. Let me know if you hit any issues. |
crummel
left a comment
There was a problem hiding this comment.
Built this properly now and it looks good to me. Thanks!
Fixes #1183