We Keep Coding

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)

Windows 2016 server with MSBuild for building .NET 4.6.1 project

I have a Windows 2016 server that I am setting up as a build server. It will be setup to use MSBuild to build a .NET 4.6.1 Web API project I am using MSBuild version 15.0, and using TeamCity version 2018.1, however I do not believe TeamCity is really involved in the issue, as I get the issue by doing an MSBuild manually/directly against the code
Windows 2016 has .NET 4.7, so I installed the .NET 4.6.1 targeting pack and .NET 4.6.1 SDK. In the build step in TeamCity, I have a parameter to MSBuild of "/p:TargetFramework=net461" But in the build logs, and when I run MSBuild manually/directly against the code, I get the following error:
HttpExtensions.cs(44, 24): error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
HttpExtensions.cs(44, 24): error CS8179: Predefined type 'System.ValueTuple`2' is not defined or imported
When I am on my development machine with Visual Studio 2017 installed, the project builds without issue. My development machine is Windows 10, but the other major difference is that the Windows 2016 server does not have Visual Studio. My thoughts are this has something to do with Windows 2016 having the primary .NET version as 4.7, and installing Visual Studio would maybe fix the issue. But I really want to avoid installing Visual Studio on the Windows 2016 server
Any ideas/feedback ?

Either or both of the following errors implies that you are trying to use ValueTuples without having either a reference to System.ValueTuple or having a version of mscorlib.dll from NET 4.7 or higher.
error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
error CS8179: Predefined type 'System.ValueTuple`2' is not defined or imported
The simple solution is to add a nuget reference to the most up to date version of System.ValueTuple and your project will then build in NET 4.6.1. See here for more details.
The reason why this works locally for you, but doesn't on your build machine is slightly more complex (and entirely theoretical, since I don't have machines of those specs to test it out).
See this question for an explanation of how MSBuild works when it doesn't have the correct targeting pack available.
Your build machine was building your project as requested. MSBuild 15.0 saw that it needed to build a project to target NET 4.6.1, found the correct targeting pack / SDK and pulled in a reference to the NET 4.6.1 mscorlib.dll, and correctly found that with this dll it had no reference to ValueTuples and couldn't build your project.
My guess is (and I'm happy to be wrong here) that you don't have the targeting pack / SDK for Net 4.6.1 installed on you local machine and as such msbuild defaults to the NET framework associated with 15.0 which is (I think) NET 4.7. This means that the mscorlib.dll that gets used is the NET 4.7 one which does contain an in-built ValueTuple type.
Ordinarily adding the nuget reference would cause a conflict for your local build (you have 2 structs from different sources with the same name (ValueTuple)), but Microsoft appear to have done something clever so that the version from the Nuget package is ignored if ValueTuple is contained in the mscorlib.dll. See comments here.
This all feels very nasty, and I personally would prefer if MSBuild threw a hard error if it couldn't find the correct targeting pack, but that's not how it works currently.

Thanks to #Ross Gurbutt for pointing in me the right direction. While it's easy to find through googling about the issue related to referencing System.ValueTuple when it's .NET 4.6.1 versus 4.7, what was confusing was that it was compiling successfully on my local without a reference. Nonetheless, I added a reference to the nuget package, and the Windows 2016 server with MSBuild v15.0 was able to build the Web API project successfully

Could not load file or assembly System.DirectoryServices. This assembly is built by a runtime newer than the currently loaded runtime [duplicate]

I have downloaded published (code behind files are no there, combined with dll in bin folder) web application from Window Server 2008 where it is hosted, and open it with Visual Studio when I debug that application it shows following error:
"Could not load assembly because this assembly is built by a runtime newer than the currently loaded runtime"
I don't know how can I solve this problem and test application locally.
Please help me.

This errors happens when the DotNet framework you are using is of older version than the one used to build the assembly. You need to check which version of framework is used to build those assemblies and then use the same or higher to debug too.

I was getting this same error when running an installer for a Windows service, even when running the installer on the PC the installer was built on.
It turned out that although the Windows service project had been updated to .NET 4.5, the Setup project that was making the installer was still set to use .NET 2.0.
To check if the Setup project is using an older version of .NET than the project to be installed, in the Visual Studio Solution Explorer:
Expand the Setup project;
Under the Setup project, expand Detected Dependencies;
Under Detected Dependencies select Microsoft .NET Framework and check the Version property. Select the appropriate .NET version from the dropdown list;
Re-build the Setup project to create a new version of the installer.

This error can have a lot of other reasons, too. I had the same problem, and nothing helped until I stumbled across this:
TlbExp.exe error:This assembly is built by a runtime newer

I just ran into this issue when the assembly was built with a target framework of .NET 4, and v4.0.30319 was installed on the server, and other 4.0 apps were running successfully.
The problem arose because the app had originally been built targeting 2.0, and new 4.0 assemblies were pushed, but not the app.config file, which we generally update separately.
This means the supportedRuntime attribute was not updated in the config and caused the error. Adding the following to the app.config fixed our issue:
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>

One the the assemblies reference in the project might be built using a newer version of .net, check version of every assembly reference and correct accordingly.

Also check the application pool that this web site is running as. It could be framework 2.0 default on some older windows servers. Change it to framework 4.0.

Getting c# and c++ to play nice together

I have a c# solution that accesses a c++ project through COM. The project has to be targeted to a specific processor, in this case x64. I am using the Windows installer to install the application.
The first problem I ran into was the c++ dll was not being registered properly when installed, and the program couldn't access it. I solved this by adding the c++ project to the solution.
For a while this worked, and everything installed properly, but then I started getting the following warning when I tried to build:
The target version of the .NET Framework in the project does not match the .NET Framework launch condition version '.NET Framework 3.5'. Update the version of the .NET Framework launch condition to match the target version of the.NET Framework in the Advanced Compile Options Dialog Box (VB) or the Application Page (C#, F#).
The setup would not install if I tried ignoring the warning. After some searching, I found that the c++ project was building in .NET 4.0, while my solution used .NET 3.5. I tried changing my solution to 4.0, but for some reason it stopped working, so I changed the c++ to 3.5.
This worked for a couple of builds, but then I began getting the following errors:
Error: LNK1104 cannot open file 'mfc90.dll'.
I added the file to the Additional Dependencies section, but then another link error occured (mfcs90.dll) and when adding that one, I got an x86 x64 conflict.
I'm not sure why these solutions worked for a while and then stopped, and I can't seem to find a resolution at any step that works. If anyone has seen anything similar to this, the insight would be appreciated.

In order to include the Microsoft runtime dlls, you should not simply include the dll in your application directory. This won't help when the dlls have various dependencies and you might run into different conflicts and versioning issues.
The way I would recommend installing the runtime dlls for you application is to include the official merge module in your MSI.
See the following link for your options to redistribute the runtime library:
http://msdn.microsoft.com/en-us/library/ms235316(v=vs.90).aspx

Cannot get my NUnit tests to run because of error

I'm trying to run an NUnit case. When I load the library, I get the following message
System.BadImageFormatException : Could not load file or assembly ... or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
You may be attempting to load an assembly built with a later version of the CLR than the version under which NUnit is currently running, 2.5.5.0727.
I've searched everywhere to find out what is causing this problem. I found another post that mentioned changing in the config file to the current .NET version that is installed. I did that and I am still getting the same error.
I'm currently using NUnit 2.4.8 and the latest version of Selenium 2.0. Any thoughts on this?
EDIT - I've noticed a lot of people are running in to this issue when using the x64 exe when they should be using x86. My library was compiled with an x86 install of Visual C# Express and I'm using the x86 NUnit executable.

Which version of the framework have the unit tests been build against? Old version of NUnit (< 2.5.6) have issues with unit tests build against the .NET 4 framework. If you building against the .NET 4 framework then I would highly suggest upgrading to the latest NUnit both to run your tests, and build against.