-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default items and default removes trample on item groups expressed in csproj #623
Comments
cc @balachir @piotrpMSFT |
Example of one implication of this issue: dotnet/project-system#1126. |
I hate to sound like a broken record here, but: I still don't think there should be implicit globs. That said, there's a way to avoid this type of problem: if you're going to do anything non-default with an item group, first make the include explicit, then do your operations on the explicit copy. In other words, excluding a directory should produce this modification to the project: <PropertyGroup>
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
</PropertyGroup>
<ItemGroup>
<Compile Include="**\*.cs" Exclude="TestProjects\**\*" />
</ItemGroup> Instead of the Of course, it's hard to socialize a solution like this--even if we fix it in VS-driven edits. |
Instead, only apply the patterns that used to be called DefaultRemoves to the items that are implicitly included. If someone adds an include for a file to their project file, we should respect that. Fixes dotnet#623 Fixes #588s
Instead, only apply the patterns that used to be called DefaultRemoves to the items that are implicitly included. If someone adds an include for a file to their project file, we should respect that. Fixes dotnet#623 Fixes dotnet#588
Thanks for raising this issue @natemcmaster. I've sent a PR to fix it. |
Fixed by #630 |
…424.9 (dotnet#623) - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19224.9
Can we make DefaultItems and DefaultRemoves smarter? Current implementation tramples what the user expresses in their csproj file and requires deep understanding of internal workings of MSBuild to unwind this.
Addition of Defaultitems and DefaultRemoves makes the behavior of ItemGroups in csproj unpredictable.
For example, consider this test application:
In RC.2, my project defined these items:
DefaultItems causes duplication in Compile groups, and default removes remove items I want in the Content group. To workaround this, I have to change the project to:
This seems excessively ugly.
More details:
Here's the RC.2 project I'm having difficulty porting: https://github.com/aspnet/DotNetTools/blob/cb3c5d77ade283538af441be9792590422c789a5/test/Microsoft.DotNet.Watcher.Tools.FunctionalTests/Microsoft.DotNet.Watcher.Tools.FunctionalTests.csproj#L10
The text was updated successfully, but these errors were encountered: