Don't mention installing Developer Pack on non-Windows OSes (MSB3644)

[rainersigwald]

Inspired by https://github.com/dotnet/core/issues/6419.

This message is reasonable for Windows scenarios, but since there are no .NET Framework Developer or Targeting Packs for Linux or macOS, we shouldn't mention them in that circumstance.

error MSB3644: The reference assemblies for .NETFramework,Version=v4.8 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks

Not sure whether we should explicitly mention Microsoft.NETFramework.ReferenceAssemblies. The SDK should provide it for you so if you hit this on *nix it's likely an SDK bug.

[AraHaan]

Inspired by https://github.com/dotnet/core/issues/6419.

This message is reasonable for Windows scenarios, but since there are no .NET Framework Developer or Targeting Packs for Linux or macOS, we shouldn't mention them in that circumstance.

error MSB3644: The reference assemblies for .NETFramework,Version=v4.8 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks

Not sure whether we should explicitly mention Microsoft.NETFramework.ReferenceAssemblies. The SDK should provide it for you so if you hit this on *nix it's likely an SDK bug.

Why require installing them at all, I experimented before when I used to explicitly reference that nuget package unconditionally when I multitargeted for .NET Standard, Framework, Core, and .NET 5 and it worked for me even without any devpacks for .NET Framework installed on MAC, Linux (VM), and a fresh Windows 10 install (thanks to the "start fresh" feature).

[rainersigwald]

Why require installing them at all

Great question! They're still required if you're not using the .NET (Core) SDK -- so if you have older projects that won't automatically reference the ReferenceAssemblies package for you (or even can't reference it because they don't use NuGet at all). That's still a common Visual Studio-customer scenario, and should still get a nice error.

[AraHaan]

Why require installing them at all

Great question! They're still required if you're not using the .NET (Core) SDK -- so if you have older projects that won't automatically reference the ReferenceAssemblies package for you (or even can't reference it because they don't use NuGet at all). That's still a common Visual Studio-customer scenario, and should still get a nice error.

True, but didn't most of them use nuget to download those packages to that project's folder though in that case (without directly referencing the packages in the non-SDK style projects) unless they created them themselves?

What if the Dev packs came with the actual frameworks that is preinstalled with Windows's copy (.NET 4.8)? Would that fix that scenario as well?

Assuming Windows 10 what could be added to what is preinstalled can be these:

• all dev packs to 4.5~4.8 (I think anything older than 4.5 should be installed by them)

But then again cant the frameworks older than 4.5 be rigged to use the 4.5 dev pack instead unless those older ones are installed by the user themselves?

[rainersigwald]

True, but didn't most of them use nuget to download those packages to that project's folder though in that case

The default experience was

1. User installs Developer pack for .NET 4.6 (for example)
2. Project has <TargetFrameworkVersion>v4.6</TargetFrameworkVersion>
3. Reference assemblies are located from the developer pack
4. NuGet is not involved at all.

What if the Dev packs came with the actual frameworks that is preinstalled with Windows's copy (.NET 4.8)?

This was the case before .NET Framework 4.0 IIRC, but at some point the team decided to split the runtime and developer packs (presumably to reduce install footprint on non-developer machines).

Would that fix that scenario as well?

Potentially, but it kinda doesn't matter: we're not going to service .NET Framework 4.8 with a change like this. .NET Core is the future of .NET, and this wouldn't meet the bar for a 4.8 change.

But then again cant the frameworks older than 4.5 be rigged to use the 4.5 dev pack instead unless those older ones are installed by the user themselves?

This actually used to be the behavior, but it caused some serious problems: #173.

So: for a subset of users, the right response to this error is to install the developer pack from the link in the error. For them, we'd like to keep the error. For users on the latest SDKs, we should have a different error.

[AraHaan]

So, basically have it trap if they are using the .NET SDK and if so have it not error and use those implicitly added reference assemblies packages unconditionally whenever it sees an .NET Framework TFM in the project's frameworks (like it does currently I think) without needing to install those dev packs otherwise it will error with it not being installed.

[Nirmal4G]

Why not have a different error on non-Windows machines or update the existing message?

Similar message but be generic and have a link point to a common resource for targeting .NET Framework using the .NET SDK!

error MSB3644:
The reference assemblies for ".NETFramework,Version=v4.8" were not found.
To resolve this, install or add a targeting pack for this framework version or retarget your application.
See https://aka.ms/dotnet/targeting-netfx for more info.

[AraHaan]

No need to have that error on Non-windows at all. If they are using the .NET SDK then that means their projects must be sdk-style and that also means that the reference assemblies nuget package is implicitly referenced by the SDK for them.

Or at least what I noticed so far whenever I target for example net472 in github actions when using the 3.1, 5.0, and 6.0 preview .NET SDKs under their linux and MacOS runners.

I think for non-windows OS's the proper thing to say (when they do not use SDK-style projects) is to port them to SDK-style for non-windows OS's (if they want to keep non-sdk style projects on Windows that is).

[Nirmal4G]

That we can do. We can have the SDK props import the NuGet package implicitly but we'd also have to update the error message so that it won't confuse .NET devs on non-Windows platforms.

[rainersigwald]

We can have the SDK props import the NuGet package implicitly

It already does.

we'd also have to update the error message so that it won't confuse .NET devs on non-Windows platforms.

That's what this bug is for :)

[Nirmal4G]

I see... So, what's the verdict on this?
Can we update the message or not?

[rainersigwald]

Can we update the message or not?

This bug asks for a change to the message and has been marked up-for-grabs by a core team member, so we're interested in a change to the message. The core team isn't planning to work on it in the near future, so it's in the Backlog milestone, but if a contributor expresses an interest in working on it we'll happily assign it to them, answer questions during the process, and review the PR.

[Nirmal4G]

Can I?

[rainersigwald]

@Nirmal4G It's all yours. How do you plan to approach it? I can see a couple of options:

1. Emit a different error on non-Windows OSes.
2. Pass a boolean "Should we emit this error or something different?" down to the task and key it off of a using-the-new-sdk property.

[Nirmal4G]

How about updating the error message as I mentioned above? Isn't that the simplest option?

[rainersigwald]

We want to leave the current error message when it's appropriate; it's been tweaked over time to be as informative as possible.

[AraHaan]

I think the simplest fix is so:

if (OperatingSystem.Windows)
{
    // emit MSB3644.
}
else
{
    // either emit nothing or something else.
}

[Nirmal4G]

Let's try emitting a different error on non-Windows systems and then we'll see if we can merge those two messages.

[benvillalobos]

@Nirmal4G Any updates?