Re: How To Change Msbuild Version In Visual Studio 2019
Eden Alvardo
For this section I have started using Rider i.o. VSC. Though compiling without any issues, it has the following errors. Could anybody please explain what do they mean and how to solve them? Much appreciated!!
image943136 4.92 KB
image92892 2.76 KB
Hi. I use rider for unreal (or you can use the latest preview of the main version) and it relies on the build tools from visual studio to be correct and up to date. I never had to configure Rider as I always used studio and use Studio for other projects daily. If you are able to build your Unreal Project in studio 2019, it should work fine without messing with the settings.
The best way to know if this will affect you is by testing your build with a 64-bit version of MSBuild. Visual Studio and Build Tools have included 64-bit MSBuild since Visual Studio 2013, so you can do this in your current version of Visual Studio, as well as with the Visual Studio 2022 previews.
MSBuild has both 32- and 64-bit executables. Both are installed in every copy of Visual Studio and Visual Studio Build Tools, and scripts that call msbuild.exe by full path can select which to use. The Developer Command Prompt for Visual Studio also sets PATH to include the MSBuild bin folder.
Visual Studio 2019 is the last version of Visual studio that used the 32-bit version of MSBuild for builds within Visual Studio. Since Visual Studio 2022 is now 64-bit and runs MSBuild in-process, it now runs a 64-bit version of MSBuild, including when you hit F5 or Ctrl-F5. Consistent with the change to 64-bit, the Visual Studio Developer Command Prompt now points to the 64-bit version of MSBuild in the PATH (the 32-bit version was on the PATH in earlier releases).
The 32-bit MSBuild is run by default in the Azure Pipelines Visual Studio Build and MSBuild tasks. To change this, specify msbuildArchitecture: 'x64' in your YAML job definition. For GitHub Actions, the setup-msbuild action allows for specifying this same setting using msbuild-architecture: 'x64'.
MSBuild tasks are .NET assemblies that add extra functionality to MSBuild. You use them in your normal build, even if you have never written one. MSBuild tasks normally run inside the parent MSBuild process.
You have the option of rewriting your task to support running in a 32- or 64-bit environment and deploying both copies of native assemblies, but this is often difficult, so you may prefer to configure MSBuild to run your task in a 32-bit process (even from a 64-bit build).
Because this requires starting a new process and communicating with it, it takes more time during the build than running a task in the existing MSBuild process. This is usually not a problem unless the task is called many, many times in your build.
Tasks are made available for use with UsingTask elements. You can configure the task to indicate that it requires a specific runtime environment by specifying the Architecture attribute in the UsingTask element.
This change is backward compatible since MSBuild has supported running tasks in a different architecture since .NET 4.5 and Visual Studio 2012. Specifying Architecture will not change how the task runs in a 32-bit MSBuild environment, but will cause 64-bit MSBuild to run it in a secondary 32-bit process. Because of this, we recommend making this change unconditionally and not trying to detect Visual Studio 2022 (MSBuild 17) specifically.
You can work around this issue by recompiling your task assembly as AnyCPU and additionally specifying the Architecture. In that case, the MSBuild engine can load the task in a 64-bit environment but it will only execute it in a 32-bit process.
Unfortunately, it is difficult to work around task misconfiguration if you do not control the UsingTask. dotnet/msbuild#5541 tracks a change that would make it easier to override an incorrect UsingTask in your project. Please let us know if this would be useful to you in a future Visual Studio/MSBuild release.
Aperantly when I switch back to an old VS2020 (16.5.5) everything works fine.
Does it matter that the -A x64 argument is at the end of the geration cmd in my case?
So something changed within the versions
It would also be worth trying CMake 3.17 or another earlier version to see if this is a regression in the 3.18 release. It might be something that VS changed in recent versions, but if we can eliminate CMake versions from the picture, that may help narrow down the underlying cause.
Hey thx for your replys. I did some version tests.
All tests where run unsing the posted cmd above except with the proper generator "Visual Studio 16 2019"
All VS Versions where taken from -us/visualstudio/releases/2019/history
According to the paths it looks like you are running your generation command from a unixoid terminal (MSYS, Cygwin, WSL) on Windows. Can you try to run your command from a "x64 Native Tools Command Prompt for VS 2019" using Windows paths? The native tools command prompt can be found in the Start menu under the Visual Studio 2019 entry.
@brad.king This is suggesting that VS may have changed something in a recent version. Do we have any nightly builders running VS 16.7.0 or later? If not, do you have access to such a machine locally? This one may need further investigation as a potential environmental change.
The current master branch of Habitat is using v0.4.4 of the gulp-msbuild package. That version was still using an iterative process to figure out the location of msbuild. Priority is given to the following versions, in order:
This is a pretty limited process, because it doesn't allow for non-standard installations. It looks for each of the above folder names within C:\Program Files (x86)\Microsoft Visual Studio\2017. When it finds a folder that exists, it's considered the official version for building. So presumably you do have that folder on your drive: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise. Removing it, if not needed, would resolve your issue.
What I would recommend though is updating the gulp-msbuild package (from your solution root: npm update gulp-msbuild --save). Since that version, this package has been updated to use vswhere in order to locate msbuild. You can see the change in this commit on GitHub.
Build scripts for .net are always a bit painful, and Microsoft has not made it easy over the years as every release they change the paths. For 2017 it is even worse and it depends on the edition so they want you to use vswhere.exe to locate the installed version(s) of msbuild.
As you can see in Figure 1 this command immediately lists all your installed versions of Visual studio in your running system. If you have preview version you need to add argument -Prerelease to retrieve information even for pre-release versions.
If you sort descending by InstallationVersion the first element will be latest version, then you can easily locate latest version of MsBuild.exe because you have the exact installation path of VS. Here is the full function:
The function is really simple, it just uses the Get-VSSetupInstance to locate all visual studio installed version, sort by version, then it got the location of msbuild.exe. From VS2017 and VS2019 it seems on my machines that the location is different, VS2017 uses 15.0 subdirectory while VS2019 seems to use Current directory. Feel free to point me example where this assumption is not working (maybe some installation options can change msbuild location)
The solution to all these problems is that unit tests should be run in their own process.It lets us leverage the existing assembly resolution logic without needing anythingspecial, and offers a better level of isolation from one test project to another whenrunning in parallel.
In v2, we separated two libraries: xunit.core.dll and xunit.execution.*.dll. The purposeof this separation was two-fold: to isolate the code used to write tests and the code usedto run those tests; to hide the fact that while core targeted netstandard1.1, executionwas forced to ship framework-specific DLLs.
With v3, these two libraries have been collapsed into xunit.v3.core.dll and the target is nownetstandard2.0. This will primarily benefit extensibility authors who previously had tochoose whether to extend core and/or execution, and more specifically, had to shipmulti-targeted libraries to match whichever runtimes they wanted to support.
Note that currently the xunit.v3.core (and xunit.v3) NuGet package shows target frameworksof net472 and net6.0 because of the in-process runner requirement. Developers who extendxUnit.net will use the xunit.v3.extensibility.core NuGet package instead, which issingle-targeted against netstandard2.0. Extensibility authors will no longer need to shipmulti-targeted NuGet packages.
If you want to use the MSBuild runner, we now ship both a .NET Framework and .NET Core/.NET versionin the same package. It will dynamically select the correct version depending on whether you usethe .NET Framework MSBuild or the .NET MSBuild (via dotnet build or dotnet msbuild). However,the .NET version only supports v3 test projects. If you need to still run v1 and/or v2 test projects,you must use the .NET Framework version. (Mono ships with the .NET Framework version of MSBuild,so all comments about .NET Framework also apply to Mono.)
You can run your v3 test projects with first and third party test runners that havebeen developed to do so (by using xunit.v3.runner.utility). We ship NuGet packagesfor our console runner (xunit.v3.runner.console) and our MSBuild runner(xunit.v3.runner.msbuild). These work exactly like their v2 counterparts. We haveincluded a new .NET Core/.NET version of our MSBuild runner, so it can be used withdotnet build and/or dotnet msbuild; however, this version of the MSBuild runnercan only run v3 test projects. To be able to run v1 or v2 test projects, you muststick with the .NET Framework of the MSBuild runner, run via msbuild.
We also are making pre-release builds of xunit.runner.visualstudio available fordevelopers who wish to run their tests via dotnet test, Test Explorer in Visual Studio2022, or any other IDE which supports VSTest. Make sure to use one of the 3.0.0-prebuilds for this functionality, as the builds from the 2.x tree are still onlycapable of running v1 and v2 tests.
d3342ee215