We’re aiming to prepare the groundwork for the .NET 10 migration by ensuring that we only need to startVisual Studio Preview, without requiring any further changes to the existing codebase. The goal is to keep the transition as seamless as possible and avoid deeper structural modifications at this stage.

Something like this

<TargetFrameworks>net8.0;net9.0</TargetFrameworks><TargetFrameworksCondition=" '$(BuildInsideVisualStudioPreview)' == 'true'">$(TargetFrameworks);net10.0</TargetFrameworks>

Is there anything specific that makes you think this might not be a good idea? We’d appreciate any insights or concerns you might have.

Trying to add the TFM conditionally based on whether VS is the initiator is not something that we really support or would suggest; in particular, this means that as you migrate to .NET 10, you'll have no guarantee that it continues to work as things like CI will not validate your changes. If you want take an approach like this, I'd suggest defining your ownEnableNET10 variable, or similar, and ensuring that is set during your CI to ensure your developers don't accidentally break .NET your app in .NET 10 as they're continuing their regular work.

I've moved this discussion to the MSBuild repo, since it has nothing to do with Roslyn as far as I can tell.

You may be able to use$(NETCoreAppMaximumVersion) or$(NETCoreSdkVersion).

However IIRC making TargetFrameworks conditional on those causes NuGet lock file mismatch errors if your CI builds with RestoreLockedMode=true and different developers use different SDK versions when regenerating the package lock files.

Thank you@CZEMacLeod, for the proposed solution. However, unfortunately, it is not applicable toDirectory.Build.props files.

ContentDirectory.Build.props

<_ProjectTargetFrameworks>net8.0;net9.0</_ProjectTargetFrameworks>// Throws: `error  : The expression "[MSBuild]::VersionGreaterThanOrEquals('', 10.0)" cannot be evaluated. Version string was not in a correct format.  C:\sources\dailydevops\healthchecks\Directory.Build.props`<_ProjectTargetFrameworksCondition="$([MSBuild]::VersionGreaterThanOrEquals('$(NETCoreAppMaximumVersion)','10.0'))">$(_ProjectTargetFrameworks);net10.0</_ProjectTargetFrameworks>

Content of my project files

<TargetFrameworks>$(_ProjectTargetFrameworks)</TargetFrameworks>

Directory.Build.props

  <PropertyGroup>    <TargetFrameworks>net8.0;net9.0</TargetFrameworks>  </PropertyGroup>

Directory.Build.targets

  <PropertyGroup>    <TargetFrameworksCondition="$([MSBuild]::VersionGreaterThanOrEquals('$(NETCoreAppMaximumVersion)','10.0'))">$(TargetFrameworks);net10.0</TargetFrameworks>  </PropertyGroup>  <TargetName="DetectNet10"BeforeTargets="DispatchToInnerBuilds">    <MessageImportance="high"Text="NETCoreAppMaximumVersion: $(NETCoreAppMaximumVersion)" />    <WarningCondition="$([MSBuild]::VersionLessThan('$(NETCoreAppMaximumVersion)','10.0'))"Text="net10 not supported. Please install the net10 sdk."File="https://dotnet.microsoft.com/en-us/download/dotnet/10.0" />  </Target>

Leave theTargetFrameworks out of your project files entirely.

This does detect VS Preview, but having the preview installed does not necessarily mean you have net10 sdk installed to build net10 targets. You can also build net10 without the preview version of VS2022.

My comment above is in response to the original question,
It distinguish VS Regular/Preview by environment variable that is set by VS.

If it need to use .NET 10 on non-preview environment also.
It might required to checkNETCoreAppMaximumVersion as commented.
(And it need to enable "Use previews of the .NET SDK" preview feature on VS setting)