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)

Use Roslyn MSBuildWorkspace with Visual Studio 2013

For my master thesis I'm building a Visual Studio plugin that should perform some code-analysis of the current opened solution.
In order to do that I've decided to try to use Roslyn, using the corresponding nuget package.
Everything works fine (SyntaxTree for navigating the code,...) until I've tried to use MSBuildWorkspace.Create().
This last call causes the following exception:
Could not load file or assembly 'Microsoft.Build, Version=14.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies. The system cannot find the file
specified.":"Microsoft.Build, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
I found this two posts:
Creating new Microsoft.CodeAnalysis.CustomWorkspace - got ReflectionTypeLoadException
MSBuildWorkspace.Create() throws exception
from which I understand that I need the MSBuild Tools for Visual Studio 14, which is in the related iso.
I do not want to install the full Visual Studio 14, this also because the plugin that I'm writing should run under Visual Studio 2013. From the two post it seems that I can install only this part of VS 14.
My question actually is: if I install MSBuild Tools for Visual Studio 14 what will happen with all other Visual Studio projects that I'm currently working on?
At the moment they use the MSBuild tool of Visual Studio 2013. It's possible to still use that?
Update
What I'm acctually trying to get is to find if a given method has references inside the project. The idea was to proceed as in this post.

When you say you're building a plugin for Visual Studio, if all you care about is getting the workspace for the currently open solution (i.e. the code the user is editing), you shouldn't use MSBuildWorkspace, really ever. That's a type for loading things outside of Visual Studio. What you can do if you're in the product is MEF [Import] Microsoft.VisualStudio.LanguageServices.VisualStudioWorkspace. That gives you live access to what the user has open, and avoids running MSBuild entirely.
Note you're still going to have to be careful about your choice of reference assemblies you build against: if you use the latest NuGet packages that won't work since those will differ in version (and also APIs -- we changed a bunch of stuff) than what was in the last Visual Studio 2013 preview.

The issue is that (unfortunately) the assemblies in the public Roslyn nuget packages have been compiled with a newer version of MSBuild than what you want.
However, it's pretty simple to fix so that it works on MSBuild 4.0 (VS2012+). I've provided them with a PR with the fix (at https://roslyn.codeplex.com/workitem/405), but also published a nuget package called DesktopAnalysis that contains all the assemblies for doing C# code analysis, that work on VS2012+ (MSBuild 4.0+): https://www.nuget.org/packages/DesktopAnalysis
Just do an install-package DesktopAnalysis -pre instead and you're done. The assemblies are the same, the code is the same, etc.
I'm using this to provide a code migration extension that works from VS2013 all the way to VS2015 Preview.

You could fork the Roslyn codebase, and compile with MSBUILD12 defined, which should still work, though we don't really test this much.

This is entirely possible, but not at all easy.
You need to make sure that you only ever load the version of the Roslyn assemblies that is in the VS version you're targeting, by removing those assemblies from your VSIX and handling AssemblyResolve to make sure you get the right ones.
You can see my code that does exactly that here, and you can read more about this technique in my blog post
Note that if you need to [Export] any interfaces defined in Roslyn assemblies, this will not work at all, since MEF will try to load them before you add your handler. (unless you add a module initializer by hand in ildasm)
The harder part is that you need to limit yourself to the intersection of the APIs in every Roslyn version you want to support.

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/

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

Reference Component Microsoft.CSharp could not be found

I found this problem on my C# project which I started at Visual Studio 2010, when I go to another PC I use in 2008, I open the project.csproj:
A get or set accessor expected
and warning:
The referenced component 'Microsoft.CSharp' could not be found.
I thought that it was about .NET Framework or Microsoft.CSharp is not located, because it says that:
Could not resolve this reference. Could not locate the assembly "Microsoft.CSharp". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors
but I'm not sure about the problem, can you guys give me a solution? Really appreciated.

It sounds like you are targeting .NET 4.0 in the project, and then trying to load it in VS2008 which only targets up to .NET 3.5.
If you need to use the project in VS2008, then you should re-target the project at .NET 3.5:
and then remove any incorrect references (they'll probably have yellow warning triangles on them anyway).
The A get or set accessor expected also suggests you're using new C# syntax, for example dynamic. If you need to target older C# compilers, you'll have to not do that. If you are using multiple IDE versions and it is being a problem, then to ensure you don't do that accidentally you can set the language version for the project via Project Properties -> Build -> Advanced: