1

this question is related to my other stackoverflow issue.

Can anybody please tell me what Microsoft.NET.Build.Extensions is and why msbuild sometimes takes references from it instead of /packages folder?

Problem description:

I have C# application (targeting .NET Framework 4.6.2). I am using some nuget references (e.g. Microsoft.DotNet.PlatformAbstractions.2.1.0) which is dependent on System.Runtime.InteropServices.RuntimeInformation(v4.3.0). Nuget downloaded this .dll to my /packages folder with file version 4.6.24705.1. During build process this .dll is overriden by higher version 4.6.26011.1 from location "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll"

Everything works fine except my build machine msbuild folder does not contain Microsoft.NET.Build.Extensions and although build process is finished successfuly the result build is not going to run due to this lib which is copied this time from packages with lower version 4.6.24705.1. It says "Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation ..."

EDIT: 29.6.2022

So "MSBuild\Microsoft\Microsoft.NET.Build.Extensions" folder is apparently created by installing .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. enter image description here After I installed .NET SDK the build process starts to mind this folder and some of my System packages are "overidden" during the build process. Maybe it has something to do with .netstandard? Can somebody explain how does the build process works in this situation?

Jan Veselý
  • 31
  • 4
  • It is plumbing to add support for .NETStandard assemblies to projects that target an old .NETFramework version (4.61 through 4.72). You got 4.6.26011.1 (aka 4.0.2.0) because that's the version that the msbuild overlords considered appropriate to support code compiled against .NETStandard. Beyond an assembly redirect in the .config file, you surely found a good reason to start targeting 4.8 so that everybody can agree about using the version in the GAC. – Hans Passant Jun 29 '22 at 19:23
  • So you are using VS 2022 on the dev box, while using VS 2019 on the build machine? That makes no sense, because incompatibility is expected. If you really want to go to the bottom of this, then GitHub seems to be the quickest channel, https://github.com/dotnet/msbuild/issues – Lex Li Aug 28 '22 at 23:22

1 Answers1

0

You have two approaches to building your projects:

  • Old MSBuild task that runs on legacy .NET Framework
  • SDK-style projects with .NET CLI and .NET Core Engine under the hood(including .NET Framework).

You use the latter approach because .NET Standard uses SDK-style and SDK enforces you to use .NET Core Engine so you need to update your build machine with an extra .NET Core Engine(.NET SDK) to run builds on it.

One thing to mention, .NET Core Engine takes precedence in many situations so watch out for situations where the compiler from .NET Core isn't backward compatible with .NET Framework as I had with .resx files compilation.

You shouldn't have any problems with changing the engine but sometimes you can encounter nasty bugs in legacy projects.

Xeinaemm
  • 26
  • 4
  • I wonder how this is related to the question, which asks about a specific MSBuild behavior shipped with VS 2022 that does not appear in the MSBuild version shipped with VS 2019. – Lex Li Aug 28 '22 at 23:26