Differentiating Visual Studio Preview from Regular VS in MSBuild – Beyond BuildingInsideVisualStudio

[samtrion]

Is there a dedicated MSBuild property or mechanism to detect when a build is running specifically inside a Visual Studio Preview instance, as opposed to a regular release version? We are aware of the BuildingInsideVisualStudio property, but it does not differentiate between stable and preview editions.

[333fred]

Not that I'm aware of. It also seems very likely to me that changing the build based on such information would be a very bad idea. What are you trying to do?

[samtrion]

We’re aiming to prepare the groundwork for the .NET 10 migration by ensuring that we only need to start Visual 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>
<TargetFrameworks Condition=" '$(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.

[333fred]

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 own EnableNET10 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.

[jasonmalinowski]

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

[KalleOlaviNiemitalo]

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.

[CZEMacLeod]

You can have Preview version and no net10 support, and I think you can do net10 in the non-preview version of VS2022. It is about which SDK is in use. You need to install the net10 sdk (which becomes the default unless you specify something in the global.json file) to light up net10 support.

If you want to do this, you can try:

    <TargetFrameworks Condition="$([MSBuild]::VersionGreaterThanOrEquals('$(NETCoreAppMaximumVersion)','10.0'))">$(TargetFrameworks);net10.0</TargetFrameworks>

You might also want something like

  <Target Name="DetectNet10" BeforeTargets="DispatchToInnerBuilds">
    <Message Importance="high" Text="NETCoreAppMaximumVersion: $(NETCoreAppMaximumVersion)" />
    <Warning Condition="$([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>

This will mean your devs will get the appropriate warning, and you can check if your CI servers have net10 installed, and update any build scripts to add the appropriate SDK install.

[samtrion]

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

Content Directory.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`
<_ProjectTargetFrameworks Condition="$([MSBuild]::VersionGreaterThanOrEquals('$(NETCoreAppMaximumVersion)','10.0'))">$(_ProjectTargetFrameworks);net10.0</_ProjectTargetFrameworks>

Content of my project files

<TargetFrameworks>$(_ProjectTargetFrameworks)</TargetFrameworks>

[CZEMacLeod]

Directory.Build.props

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

Directory.Build.targets

  <PropertyGroup>
    <TargetFrameworks Condition="$([MSBuild]::VersionGreaterThanOrEquals('$(NETCoreAppMaximumVersion)','10.0'))">$(TargetFrameworks);net10.0</TargetFrameworks>
  </PropertyGroup>
  <Target Name="DetectNet10" BeforeTargets="DispatchToInnerBuilds">
    <Message Importance="high" Text="NETCoreAppMaximumVersion: $(NETCoreAppMaximumVersion)" />
    <Warning Condition="$([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 the TargetFrameworks out of your project files entirely.

[filzrev]

I'm using following settings to check it's executed on VS Preview.

<PropertyGroup Condition="'$(BuildingInsideVisualStudio)' != '' AND $(VisualStudioDir.Contains('Preview'))">
    <TargetFrameworks>net10.0;$(TargetFrameworks)</TargetFrameworks>
</PropertyGroup>

Note:
On my environment. VisualStudioDir environment variable indicate C:\Users\user\Documents\Visual Studio 2022 Preview.
And this path will be changed when RC version is released.

[CZEMacLeod]

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.

[filzrev]

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 check NETCoreAppMaximumVersion as commented.
(And it need to enable "Use previews of the .NET SDK" preview feature on VS setting)