Ensure that the dotnet-monitor tool package doesn't try to build for .NET 10 RID-specific tools #8552
Conversation
| @@ -11,6 +11,13 @@ | |||
| <Nullable>enable</Nullable> | |||
| <EnableConfigurationBindingGenerator>false</EnableConfigurationBindingGenerator> | |||
| <DisableCompileTimeOpenApiXmlGenerator>true</DisableCompileTimeOpenApiXmlGenerator> | |||
| <!-- This repo sets RuntimeIdentifiers globally in Directory.Build.props, but we explicitly don't want to use | |||
| RID-specific tools yet. So we need to clear the RuntimeIdentifiers here. --> | |||
| <RuntimeIdentifiers Condition="'$(_IsPacking)' == 'true'"></RuntimeIdentifiers> | |||
There was a problem hiding this comment.
I think we may need another condition here because the CI build doesn't run dotnet pack so _IsPacking won't be set. There may be some other ambient property available in the CI build that can be used here until the SDK gets a more clear knob.
| <Target Name="PublishProjectsBeforePack" | ||
| Condition="'$(SkipPublishProjects)' != 'true'"> | ||
| <CallTarget Targets="PublishProjects" /> |
There was a problem hiding this comment.
No longer needed because relevant projects are Published as part of Pack directly now.
| Condition="'$(SkipPublishProjects)' != 'true'"> | ||
| <CallTarget Targets="PublishProjects" /> | ||
| </Target> | ||
| <ItemGroup Label="Computed Publish Assets"> |
There was a problem hiding this comment.
We can declare all of these additional files ahead of time, and then hook them up at the right part of the Publishing lifecycle. This means we don't need to worry about Tool-specific paths, and can focus on just making the local publish experience correct. Then, if publish works, tools will also work.
| <Target Name="AddNativeAssetsToPublishLayout" | ||
| BeforeTargets="ComputeResolvedFilesToPublishList"> | ||
| <ItemGroup> | ||
| <ResolvedFileToPublish Include="@(AdditionalRIDSpecificPublishFile->Exists());@(AdditionalRIDAgnosticPublishFile)"> | ||
| <CopyFileToPublishDirectory>PreserveNewest</CopyFileToPublishDirectory> | ||
| </ResolvedFileToPublish> |
There was a problem hiding this comment.
Really easy to add all of the additional files to the publish output as a result!
…publishing/packaging of dotnet-monitor project
| @@ -91,7 +91,7 @@ | |||
| <ProjectReference Include="..\..\Tools\dotnet-monitor\dotnet-monitor.csproj"> | |||
| <ReferenceOutputAssembly>false</ReferenceOutputAssembly> | |||
| <SkipGetTargetFrameworkProperties>true</SkipGetTargetFrameworkProperties> | |||
| <SetTargetFramework>TargetFramework=net10.0</SetTargetFramework> | |||
| <GlobalPropertiesToRemove>TargetFramework</GlobalPropertiesToRemove> | |||
There was a problem hiding this comment.
This was causing a race and double-builds of dotnet-monitor. Since this project isn't referencing the outputs of the project, we can completely remove the TFM of the current project from the set of properties that flow to the inner build of dotnet-monitor, which then makes MSBuild properly synchronize the builds/access of that project.
Continuing the fallout for .NET 10 RID-specific tools, we don't want to opt in to the new mode for this repo as of yet. We explicitly disable it for tool packaging only.
Before:
The RID-specific tool packages are created.
After:
The RID-specific tool packages are not created.
As part of this, because the dotnet-monitor package had some targets that were also adding explicit package files (which causes build errors due to duplicated files in the package), and this is no longer needed due to the change for tool packages to just use the output of
Publish, I've made it so thatdotnet publishof the dotnet-monitor project creates the same layout as the tool package, so you're getting increased consistency of execution-time experience.I also compared the generated tool package to the existing published tool packages and the layouts were essentially identical.