Skip to content
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

Closed
natemcmaster opened this issue Jan 10, 2017 · 5 comments
Assignees
Milestone

Comments

@natemcmaster
Copy link
Contributor

natemcmaster commented Jan 10, 2017

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:

Microsoft.DotNet.Tools.Watcher.FunctionalTests.csproj
Tests.cs
TestProjects/
     TestApp/
          TestApp.csproj
          Program.cs

In RC.2, my project defined these items:

<Compile Include="**\*.cs" Exclude="TestProjects\**\*" />
<Content Include="TestProjects\**\*" CopyToOutputDirectory="PreserveNewest" />

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:

  <PropertyGroup>
    <DisableDefaultRemoves>true</DisableDefaultRemoves>
  </PropertyGroup>

  <ItemGroup>
    <Compile Remove="TestProjects\**\*" />

    <Compile Remove="$(DefaultRemoves)" />
    <EmbeddedResource Remove="$(DefaultRemoves)" />
    <None Remove="$(DefaultRemoves)" />
    <Content Remove="$(DefaultRemoves)" />

    <Content Include="TestProjects\**\*" CopyToOutputDirectory="PreserveNewest" />
 </ItemGroup>

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

@muratg
Copy link

muratg commented Jan 10, 2017

cc @balachir @piotrpMSFT

@natemcmaster
Copy link
Contributor Author

Example of one implication of this issue: dotnet/project-system#1126.

@dsplaisted dsplaisted self-assigned this Jan 11, 2017
@rainersigwald
Copy link
Member

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 Remove stuff above.

Of course, it's hard to socialize a solution like this--even if we fix it in VS-driven edits.

dsplaisted added a commit to dsplaisted/sdk that referenced this issue Jan 11, 2017
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
dsplaisted added a commit to dsplaisted/sdk that referenced this issue Jan 11, 2017
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
@dsplaisted
Copy link
Member

Thanks for raising this issue @natemcmaster. I've sent a PR to fix it.

@srivatsn srivatsn added the Bug label Jan 13, 2017
@srivatsn srivatsn added this to the 1.0 RC3 milestone Jan 13, 2017
@srivatsn
Copy link
Contributor

Fixed by #630

mmitche pushed a commit to mmitche/sdk that referenced this issue Jun 5, 2020
…424.9 (dotnet#623)

- Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19224.9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants