Microsoft.Build.Artifacts conflicts with .NET 8 SDK simplified output paths
Opened this issue · 17 comments
The .NET 8 SDK has a new simplified output paths feature that is opt-in.
However, the property that has been chosen to configure it is ArtifactsPath.
That leads to any projects using Microsoft.Build.Artifacts that are built with the .NET 8 SDK to suddenly find bin and obj folders in the build artifacts folder.
@jeffkl Any thoughts on how you'd like to solve this conflict?
If you have a direction in mind, I'd be happy to open a PR with the required changes.
The .NET SDK now disables itself if you're using Microsoft.Build.Artifacts: dotnet/sdk#33470
I'm trying to get this pull request to work as well: #458
The .NET SDK now disables itself if you're using Microsoft.Build.Artifacts: dotnet/sdk#33470
Do you know what version of the .NET 8 SDK should have that change? The merged PR mentions Preview 6, but I'm using RC1, and I'm still seeing the conflict.
@dsplaisted can you answer @bording's question? #477 (comment)
@bording I believe the fix went into Preview 6 as mentioned in the PR, but it should definitely be in RC1 in any case. Can you share a repro or a binlog for how you're still seeing the conflict?
It's happening in https://github.com/Particular/ServiceControl. When I build that with the RC1 SDK, the bin and obj folders end up in the folder configured in ArtifactsPath.
ArtifactsPath is defined in a Custom.Build.props file, which is imported into Directory.Build.props.
The other potentially relevant piece is that Microsoft.Build.Artifacts is added as a GlobalPackageReference.
I can also try and put together a simplified repro if that would also be helpful.
@dsplaisted Here's a simplified repro:
I included a binlog in there as well. When I build that with the RC1 SDK, the configured artifacts folder has both the default artifacts from Microsoft.Build.Artifacts and the project bin and obj folders.
@dsplaisted @jeffkl Anything else I can do to move this forward?
@bording you can disable Microsoft.Build.Artifacts if you're using the .NET SDK's artifacts functionality:
<PropertyGroup>
<EnableArtifacts Condition="'$(UseArtifactsOutput)' == 'true'">false</EnableArtifacts>
</PropertyGroup>Although the .NET SDK's artifacts should be disabling itself if you're using Microsoft.Build.Artifacts.
@jeffkl I'm not using the .NET SDK artifact functionality, but it's enabled anyway. That's the entire point of the issue I've raised here.
Whatever you've done in the SDK so far to try and detect Microsoft.Build.Artifacts is not working.
Would the opposite work then, disabling .NET SDK's artifacts?
<PropertyGroup>
<UseArtifactsOutput>false</UseArtifactsOutput>
</PropertyGroup>@jeffkl That does force it off, yes. For now, I'll go ahead and add that to my project that's having the problem as a workaround.
However, that doesn't address the larger issue here. According to dotnet/sdk#33470, the SDK is supposed to detect Microsoft.Build.Artifacts and automatically disable the SDK artifacts. That detection is not working properly, so it seems like something that should be investigated and fixed.
Reading through the changes and comments in dotnet/sdk#33470, I believe this is happening in my case because of the scenario being talked about in dotnet/sdk#33470 (comment)
I do think something more needs to be done in the SDK to cover that scenario as well.
Got it, I think we'll need to open an issue at https://github.com/dotnet/sdk/issues/new/choose instead, this issue is about Microsoft.Build.Artifacts disabling itself when the .NET SDK's functionality is enabled.
Got it, I think we'll need to open an issue at https://github.com/dotnet/sdk/issues/new/choose instead, this issue is about Microsoft.Build.Artifacts disabling itself when the .NET SDK's functionality is enabled.
Maybe you're thinking about a different issue? This is the issue I opened about the conflict.
Due to the order things are imported in, I'm not sure we can make this work without requiring the Directory.Build.props to set UseArtifactsOutput to false (or some other change to that file). The project is opting in to using Microsoft.Build.Artifacts by referencing the package and setting the ArtifactsPath. However, ArtifactsPath is now overloaded with the built-in functionality of the .NET SDK, and in this case at the point where we're determining whether we should use the built-in .NET SDK functionality, we don't know yet that the Microsoft.Build.Artifacts package has been referenced.
So I think the guidance should be, that if you're referencing Microsoft.Build.Artifacts as a NuGet package, and you are setting ArtifactsPath via Directory.Build.props, that you should also set UseArtifactsOutput to false when you set ArtifactsPath.
If it's not actually possible to resolve the conflict between the shared use of ArtifactsPath, then I don't think it's really acceptable to leave things in the state that they are currently in.
Instead, I think it makes more sense to go ahead and take a breaking change in a new major version of Microsoft.Build.Artifacts and have it use a different property name, for example BuildArtifactsPath.
That was what I was going to suggest doing when I opened this issue before learning that there was an attempt to modify the SDK.