Skip to content

Update RepoTasks to use the FrameworkReference workaround from GenerateFiles #45973

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

Open
wtgodbe opened this issue Jan 9, 2023 · 1 comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework

Comments

@wtgodbe
Copy link
Member

wtgodbe commented Jan 9, 2023

Today, we can't update RepoTasks.csproj's TFM until we get an SDK with the new TFM baked in. Our other projects can update before that because they get the workaround from GenerateFiles:

<!-- Workaround when there is no vNext SDK available; copy known apphost/framework reference info from 6.0. -->
<ItemGroup>
<KnownAppHostPack
Include="@(KnownAppHostPack->WithMetadataValue('TargetFramework', 'net6.0'))"
TargetFramework="${DefaultNetCoreTargetFramework}"
Condition="'@(KnownAppHostPack->Count())' != '0' AND
!(@(KnownAppHostPack->AnyHaveMetadataValue('TargetFramework', '${DefaultNetCoreTargetFramework}')))" />
<KnownRuntimePack
Include="@(KnownRuntimePack->WithMetadataValue('TargetFramework', 'net6.0'))"
TargetFramework="${DefaultNetCoreTargetFramework}"
Condition="'@(KnownRuntimePack->Count())' != '0' AND
!(@(KnownRuntimePack->AnyHaveMetadataValue('TargetFramework', '${DefaultNetCoreTargetFramework}')))" />
<KnownFrameworkReference
Include="@(KnownFrameworkReference->WithMetadataValue('TargetFramework', 'net6.0'))"
TargetFramework="${DefaultNetCoreTargetFramework}"
Condition="'@(KnownFrameworkReference->Count())' != '0' AND
!(@(KnownFrameworkReference->AnyHaveMetadataValue('TargetFramework', '${DefaultNetCoreTargetFramework}')))" />
</ItemGroup>
. This blocks source build because we wind up with mixed TFM assets in the source build payload in dotnet/installer.

@wtgodbe wtgodbe added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Jan 9, 2023
@wtgodbe wtgodbe added this to the .NET 8 Planning milestone Jan 9, 2023
@ghost
Copy link

ghost commented Jan 9, 2023

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
Projects
None yet
Development

No branches or pull requests

2 participants
@wtgodbe and others