We Keep Coding

Azure Devops Pipeline crashes on .NET 5 version, MSBuild version etc. Any idea how to fix this?

So I've made a back-end project in .NET 5.
I'm trying now to make a release pipeline in Azure Devops, where my code is also located.
Errors include:
Error : Version 5.0.100 of the .NET Core SDK requires at least version 16.8.0 of MSBuild. The current available version of MSBuild is 15.9.21.664. Change the .NET Core SDK specified in global.json to an older version that requires the MSBuild version currently available.
Error MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1179,5): Error MSB3644: The reference assemblies for framework ".NETFramework,Version=v5.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
In the above picture's the steps I take:
First I use the almost latest version of Nuget, 5.8.0
Then the next job is a "nuget restore".
The next step is to specifically specify it needs to use .NET 5 SDK (if this job isn't included, Azure Devops throws errors on this, stating that it can't find runtime=net50 etc...).
Here's the more in detail screen:
The next job is the "MSBuild" one, here in more detail:
This "MSBuild" job replaced my "Visual Studio Build" job, because here I could set it to version "16.0" but apparently this doesn't work? The regular "Visual Studio Build" details look just the same, even in my settings, but doesn't include the "MSBuild version" option. Using the regular "Visual Studio Build" option didn't work (see above errors as well).
The next jobs he doesn't even reach yet, so I'll presume for now they work correctly. The issue is indeed with the builds, using SDK, restore etc...
Does anyone who has more experience making azure pipelines/builds in .NET Framework 5.0 or higher have an idea what's wrong here and how I can fix this? Or even an idea where I should look?
I've been breaking my head over this the entire day and it's about to explode...

You should use a different type of tasks to restore/build etc .net core apps
https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/dotnet-core?view=azure-devops&tabs=dotnetfive

My program doesn't excute even installed runtime package

I published my program(.net core 3.1 winform program). but it doesnt excuted even installed .net core 3.1 run-time package. so i install .net core 3.1 sdk package, it works.
why i install sdk instead of run-time package?

The software development kit (SDK) includes everything you need to build and run . NET Core applications, using command line tools and any editor (including Visual Studio). The runtime includes just the resources required to run existing

There was a problem creating a single file by using app.config in the wrong way.
When app.config was used in the correct way, it was confirmed that it works normally only with the runtime sdk.
Previously, both *.dll.config and *.dll were required, but after correcting it, only *.dll.config worked normally.

What's the difference between using dotnet and MSBuild for building .NET applications?

I've just had to do some builds without using Visual Studio for the first time, and clearly there is a gap in my knowledge regarding MSBuild and the build process.
So, what are the differences between the two build processes below?
Option 1:
dotnet build C:\Dev\trunk\Mvc.sln
This option uses "Build Engine version 16.8.3+39993bd9d for .NET" - I presume this means this way can be used for .NET Core as it has no reference to "Framework"?
Option 2:
msbuild C:\Dev\trunk\Mvc.sln
This option uses "Build Engine version 16.8.2+25e4d540b for .NET Framework".
My assumption was that the "dotnet build" command was just a shorthand way of using MSBuild. However, the logging provided by both is pretty different and they both produce different results.

Roslyn -- the C# compiler platform -- is a .NET Standard 2.0 library, meaning that it can run on both .NET Framework 4.6.1+ and .NET Core 2.0+(1).
Visual Studio, which includes MSBuild, runs on .NET Framework. When you build a project using Visual Studio (or directly using MSBuild), it runs Roslyn on .NET Framework. Visual Studio knows how to process both SDK-style csprojs and the legacy non-SDK-style csprojs, and invoke Roslyn accordingly. The version of Roslyn which is used is tied to the Visual Studio version.
dotnet build is a separate tool, and is a .NET Core application. It knows how to build SDK-style csprojs only, and it does this by running Roslyn on .NET Core. Roslyn is distributed with the .NET Core SDKs, and dotnet build loads Roslyn from one of these installed SDK versions (normally the latest).
These two ways of building a C# project are more-or-less equivalent, and they invoke the same compiler code. However, they differ on where they can run (Visual Studio is .NET Framework and Windows-only, dotnet build is .NET Core and can run on multiple platforms), and whether they can build legacy non-SDK-style csprojs. dotnet build is also a bit nicer to use from the command-line.
Note that the runtime which Roslyn is loaded into has no bearing on the compiled IL which Roslyn can emit: Roslyn running on .NET Framework can emit IL which is executed by .NET Core just fine, and vice versa.
If you are using analyzers which target .NET Core (unlikely, as Analyzers are encouraged to target .NET Standard 2.0), these will only run from dotnet build.
(1) I'm using ".NET Core" to refer to both .NET Core and .NET 5+.

error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild

I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?

https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.

Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao

I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.

I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE

I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)

Building of .NET Core application offline doesn't create the "NuGetFallbackFolder" folder

I had installed VS2019 and running "dotnet --version" command shows "3.1.100".
When i try to build a .NET standard library project without connecting to the network the following error is thrown
"error NU1100: Unable to resolve 'NETStandard.Library (>= 2.0.3)' for
'.NETStandard,Version=v2.0'
My project has the following tag
<TargetFramework>netstandard2.0</TargetFramework>
Earlier i was using Binaries of "dotnet-sdk-2.1.301-win-x64" and when i build the project, the restore command was automatically extracting and creating the "NuGetFallbackFolder" folder when i was building without connecting to the network.
The same doesn't happen after installing VS2019.
IS there a workaround for this?

Copied from github:
Starting in VS 16.3 and .NET Core 3.0, we no longer use a nuget fallback folder. A side-effect of this is that in order for you to be able to work with .NET Standard 2.0 offline, you need to restore a .net standard 2.0 project at least once while online. And every time if you clean your NuGet cache

.NET Standard 2.0 projects can be compiled on .NET Core 3.1.100 SDK successfully. Ensure that you are not having global.json with older SDK defined.
Because based on that error you have, the inability to restore ".NET Standard 2.0.3" means that somewhere in your codes you have global.json or you are explicitly referencing .NET runtime version in the csproj, instead of just using TFM of netstandard2.0 as main target defined in the csproj file.