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

Error in Visual Studio 2013 when including JetBrains ReSharper via NuGet

When I include JetBrains-ReSharper my project using NuGet Package Manager, and then I try to rebuild the project, it shows an error.
Error 14 The type 'System.Threading.LazyInitializer' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\mscorlib.dll' and 'Project\packages\JetBrains.ReSharper.SDK.8.2.1158\bin\System.Threading.dll' Project\Filters\InitializeSimpleMembershipAttribute.cs
Can anybody can help me to solve the problem ?

Sadly, because ReSharper is a .net 3.5 application, and due to the way the SDK is set up, it includes references to the .net 3.5 compatible System.Threading.Tasks.dll back port Microsoft initially released with RX. The unfortunate part is that this file is referenced even if your plugin is a .net 4 project, and so you get conflicts with the real System.Threading.Tasks.
You can change your project to be .net 3.5, but then (again, due to the way the SDK is set up) you'll get other warnings about .net 4 assemblies that are referenced, but shouldn't be. Essentially, you just have to ignore those warnings. We're working on fixing all of this for 9.0.
However, as #derigel mentions in the comments - adding the ReSharper SDK to an MVC project is a little weird, and frankly, won't work. The ReSharper SDK is for building ReSharper plugin extensions. If you want to install ReSharper, download it from here: http://www.jetbrains.com/resharper/download/

dnlib library issue when trying to reference it into other project

Using VisualStudio 2013 I've successfuly compiled the latest version of dnlib which is part of the ConfuserEx and de4dot projects, the dnlib project by default targets .NET Framework 2.0 so it should be compatible to reference it in other projects that targets a greater version but when I reference the resulting dnlib.dll in a new project that targets a .NET framework greater than 3.0 the project can't compile.
There is any compiling error information just a VisualStudio messagebox that says:
There were build errors. Would you like to continue and run the last
successful build?
I've tried the dnlib.dll in a (new, empty) WinForms project using both the debug and the release version of dnlib.dll, I've tried targeting FW 3.5, 4.0, 4.5 and 4.5.1 but the project has been compiled successfuly only targeting FW 2.0 and 3.0.
By the other hand, I'm totally able to navigate through the library members and instance the classes inside and all that, but no way to compile a project with that referenced dnlib.dll.
I think that if the default FW targeting in the dnlib project is 2.0 should be for a good reason 'cause it touchs external assemblies and that, so I'm not sure to try to solve this issue by increasing the FW targeting in the dnlib project, but anyways I've tried to increase it to 4.0 to see what hapens and I get a lot of compiler errors about type defs in mscorlib.dll.
I'm missing something?
How I can solve this problem to be able to compile a project that targets FW4.0 with the dnlib.dll that targets FW2.0 referenced?

Ok, fiddling around, I could get some Warnings but not errors. As per MSDN, ExtensionAttribute came into being with Net 3.0 and HandleProcessCorruptedStateExceptionsAttribute with NET 4.0. So, in order to make the NET 2.0 code compatible with 4.0 projects, it provides the missing Attributes. The warnings are just that they are multiply defined, and since they are just Attributes, I don't think it matters.
Rather than comment them out, there are 2 easy ways to get rid of the Warnings.
Method 1 (better, I think): Create solutions for Net 2.0 and 4.0 builds.
Open the basic Net 2.0 solution. Select the Solution (dnlib) in Solution Explorer. On the File menu pick Save dnlib.sln As and use dnlib20.sln as the file name. This is your NET 2.0 FrameWork Solution.
Do Save As again, this time to dblib40.sln. This will be your Net 4.0 Framwwork solution in a moment. Switch both the console test project and dnlib library projects to Net 4.0 Target platform. Then, in Solution Explorer, exclude the last 2 files from the solution: HandleProcessCorruptedStateExceptionsAttribute.cs and ExtensionAttribute.cs. Save it, clean and build, and you should be good.
You don't need these 2 files because NET has them defined (which is the warning); they are only meant for 2.0 projects/solutions.
Note: You can also set it up so that the solutions compile to their own folders, so you dont get them confused. On the Build Tab, next output add a folder(..\Debug\bin\Net20 and ..\Debug\bin\Net40). You'll have to change/update for both Debug and Release versions.
Method 2: Define some conditional compiler constants.
Create dblib20.sln and dblib40.sln solutions as above (unless you dont want to even use 2.0). Be sure to set the Framework to NET 4 in the 4.0 solution.
In the Net 2.0 dnlib project file, go to Project Properties --> Build --> General add the conditional compile symbol NET20. Now, in HandleProcessCorruptedStateExceptionsAttribute.cs wrap the code there in a #if:
#if NET20
using System;
#pragma warning disable 1591 // XML doc warning
namespace System.Runtime.ExceptionServices {
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
sealed class HandleProcessCorruptedStateExceptionsAttribute : Attribute {
}
}
#endif
In ExtensionAttribute.cs, do the same thing. Then Clean and Rebuild, and all should be well. Since the symbol is only defined in the NET20 solution, those classes will only be compiled when you use/open the Net 2.0 solution. If you download another update, you will have to redo this unless they provide a NET 4.0 solution file.
AFAIK, there still are not any built in FrameWork constants.
Finally, when those warnings are cleared away, there are 5 compare warnings, but from the looks of it, those can be ignored (the code seems to be doing what it wants).

This worked for me:
Change dnlib project's target version to .NET 4.0 Framework Client Profile.
Change the Example project target version to .NET 4.0 Framework Client Profile.
Remove/comment out ExtensionAttribute in ExtensionAttribute.cs in dnlib
Remove/comment out HandleProcessCorruptedStateExceptionsAttribute in dnlib
I then compiled and got no errors.
I used Visual Studio 2012.

Downgrading MSbuild file from 4.0 to 3.5

I've got a heap of csproj files that were created with Visual Studio 2010 and targeted .NET 4.0.
I am now trying to compile on Mono 2.6.7 with xbuild, however 2.6.7 can't compile verison 4 msbuild projects. (2.10.1 has no issues, which is what we've been using, but I want to do an experiment on 2.6.7).
Using MonoDevelop I've changed the Runtime Version to Mono / .NET 3.5, and it compiles fine under 2.6.7. Changing to use xbuild however fails.
What steps are required to change the MSBuild version to 3.5? The top line in the csproj file is pretty obvious:
<Project ToolsVersion="4.0"
And changing that is easy, but I'm concerned there are less obvious things that should also be changed.
Anyone know the definitive way to downgrade from a 4.0 to 3.5 msbuild file?

I don't know of an authoritative guide, but having done this several times I can say what I know.
For a simple Class Library or WinForms application, it's pretty straight forward:
The ToolsVersion on the project file needs to be set to 3.5, as you indicated.
If there is an OldToolsVersion element (meaning it was previously upgraded) in the project file, it should be removed. The same goes for FileUpgradeFlags and UpgradeBackupLocation elements. Basically, you don't want the OldToolsVersion to be the same as the current version.
If you were using the Client Framework profile, in 3.5 the element is called TargetFrameworkSubset. In 4.0, it's called TargetFrameworkProfile, so the element should be renamed. (Not sure of the applicability to Mono on this one).

Using MonoDevelop, Project->Export the solution to VS2008 format.

Are you sure you have to downgrade the MSBuild version? Just compile with 2.10, switch your environment to 2.6.7, and run the tests.