We Keep Coding

Visual Studio 2019 - change .NET target framework to 4.8

I cannot change the .NET version of my project. I installed .NET 4.8 via the Visual studio installer and manually downloaded it separately. Neither of these works.
I actually tried to change the framework in the .csproj project file
<TargetFramework> net5.0-windows </TargetFramework>
to
<TargetFramework>net48</TargetFramework>
and it doesn't work too...
I'm running out of solutions and don't really know what to do next.

If you're attempting to convert an SDK-style "net5.0-windows" project to a "net48" WinForms one you'll likely need to do more than just change TargetFramework.
Firstly, the Project node at the start of the ".csproj" file should look like this:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
(A "net5.0" target doesn't need the .WindowsDesktop part of that.)
Secondly, you'll need to ensure that <UseWindowsForms>true</UseWindowsForms> is part of the main PropertyGroup.
Even after those changes you're still likely to get all sorts of issues if your project uses types that are not available in .net 4.8.

I try to set in Unity С# Project framework 4.6.1 but it return to 4.7.1 after save the project

I use Unity 2019.4.2f1 and Rider 2019.2.3.
I tried to use a library NPOI, but it need framework version 4.6.1.
Ok, I had set the version 4.6.1 in the solutions Assembly-CSharp and Assembly-CSharp-Editor.
All right, it works. But next step I had save the project and get errors because... the framework in the solution becomes again 4.7.1.
Ok. I tried do it with Visual Studio 2019 and I got same result.
Ok. I tried to write set framework's version in the files Assembly-CSharp.csproj and Assembly-CSharp-Editor.csproj with v4.6.1. And I got same result.
Something automatically sets the version of the framework and I don't understand where is the shit.
WTF? Does anybody know anything about it?

Unity doesn't rely on csproj for compilation. csproj is only created for IDEs.
Theoretically you workaround by moving Rider package from whatever it is on your computer to Packages folder, it becomes your locally developed package, then you can change TargetFrameworkVersion https://github.com/van800/com.unity.ide.rider/blob/0a42b224e6191934884de084ccd59348742a2bc6/Packages/com.unity.ide.rider/Rider/Editor/ProjectGeneration/ProjectGeneration.cs#L83

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)

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.

MSBuild 4 fails to build VS2008 csproj due to 1 compiler warning

We have a VS2008 CS DLL project targeting .NET 3.5. It builds successfully on our CI server when using MSBuild 3.5.
When CI is upgraded to use MSBuild 4.0, the same project fails to build, due to 1 warning message:
c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(1418,9):
warning MSB3283: Cannot find wrapper
assembly for type library "ADODB".
The warning does not occur with MSBuild 3.5, and I'm surprised that it results in Build FAILED. We do not have the project set to treat warnings as errors.
All our other projects build successfully with either version of MSBuild.

The error message was not telling the whole story. The ADODB assembly on our dev machines is loaded in the GAC. That was not the case on the CI build machine.
The reference to ADODB was only placed into our C# project by a TLBIMP pre-build task, within the C# project (along with references to MSXML and VBA dlls). The latter DLLs are included in our source code repository, and thus found during the CI build process. ADODB is not. However, we also discovered that we could safely remove from the C# project all the added references, including the one to ADODB.DLL.
This fixed the problem. (Thanks for your suggestions -- they kept me thinking till we got there.)

Try either removing any hardwired toolsversion in your msbuild (and csproj) files, or setting them to ToolsVersion="4.0".
Read: http://msdn.microsoft.com/en-us/library/bb383796.aspx for a better understanding of the significance of the attribute.
Since you want to target 3.5, make sure you have the target framework version set up correctly by checking that the TargetFrameworkVersion in your csproj.
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
If you set the ToolsVersion to 4.0, any machine that wants to build the project, will have a dependency on the 4.0 framework (which has the 4.0 msbuild), even though you're targetting 3.5.
If you're targetting 3.5, and your projects are VS2008, there's no need to use msbuild 4.0 over msbuild 3.5 (they can exist peacefully side by side). Just using the 3.5 msbuild would be the simpler solution.

This is a ClickOnce issue. Remove that dependency from the list.
BTW, this bug is present in VS2008 too, but seems to not have triggered for you.