uno-check : Check/Fix Microsoft/VisualStudio folder link

[baskren]

What would you like to be added

I apologize for this edge case but uno-check might be a great place to address this issue I have every time the DotNet SDK is upgraded. I'm running Windows for ARM on a MacBookPro (via Parallels --- an officially Microsoft sanctioned way of doing this). After each DotNet SDK upgrade, I get the following error when building from the command line:

C:\Users\ben\.nuget\packages\microsoft.windowsappsdk\1.4.231008000\buildTransitive\MrtCore.PriGen.targets(911,5): error MSB4062: The "Microsoft.Build.Packaging.Pri.Tasks.ExpandPriContent" task could not be loaded from the assembly C:\Program Files\dotnet\sdk\8.0.201\\Microsoft\VisualStudio\v17.0\AppxPackage\\Microsoft.Build.Packaging.Pri.Tasks.dll. Could not load file or assembly 'C:\Program Files\dotnet\sdk\8.0.201\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.Build.Packaging.Pri.Tasks.dll'. The system cannot find the path specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask [C:\Users\ben\Development\AWC\SpanCalc\Bc3\P42.Uno.Controls\P42.Uno.Controls\P42.Uno.Controls.csproj::TargetFramework=net7.0-windows10.0.19041]

To fix this, I have to open up an Admin Command Prompt, cd to the latest C:Program Files\dotnet\sdk\#.#.###\Microsoft folder, and then do the following:

C:> mklink /d VisualStudio "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VisualStudio"

And then everything is good.

Would it be possible for uno-check to :

1. Check if the VisualStudio folder is present in the Microsoft folder in the currently supported version of dotnet SDK?
2. If the above fails, ask the user if it's ok to fix this (by adding the necessary symbolic folder link)?

Thanks for considering this.

Why is this needed

Make adoption of UNO easier for nerds like me.

For which platform

No response

Anything else we need to know?

You guys are the greatest!

[jeromelaban]

Thanks for the report!

While this is a pworkaround, this is mainly caused by running dotnet build instead of msbuild. I don't think that modifying the dotnet build this way is a particularly good way for fixing this... is there an issue by Microsoft that references this particular workaround?