I recently upgraded our ASP.NET Core 1.1 application to 2.x. This project (and all other projects in the solution) now target the full 4.6.1 framework (previously targeted the full 4.5.2 framework). Visual Studio Version 15.5.7.
After doing so, all my class library projects in the same solution have a number of broken/yellow references to NETStandard.Library.2.0.2. Strangely, the solution still builds without issue and no pertinent warnings or errors are generated in the build output. All other references are fine including all references in the ASP.NET project (meaning that project does not have this problem).
Does anyone know what might be going on here?
Troubleshooting Steps
Clean Solution/Rebuild
NuGet Restore
Restart Visual Studio
Remove .suo/.vs/project.fragment.lock.json and restart
Suspend/Resume/Turn off R#
Manually remove and rebuild (works but they come back after NuGet restore)
Confirm the files it's looking for are actually available on the path...which they are sans the strange "double backslash" before ref:
Environment Details
Visual Studio: 15.5.7
Full Framework: 4.6.1
dotnet --info:
.NET Command Line Tools (2.1.4)
Product Information: Version: 2.1.4 Commit SHA-1 hash:
5e8add2190
Runtime Environment: OS Name: Windows OS Version: 10.0.16299
OS Platform: Windows RID: win10-x64 Base Path: C:\Program
Files\dotnet\sdk\2.1.4\
Microsoft .NET Core Shared Framework Host
Version : 2.0.5 Build :
17373eb129b3b05aa18ece963f8795d65ef8ea54
Please feel free to let me know what other information may be pertinent.
UPDATE: As Requested CSProj Sample (Some Things Had to be Redacted)
https://gist.github.com/mikeomeara1/0edd3b83447473accd3350ffc974c62c
The older .NET Framework project system doesn’t properly support .NET Standard Library 2.x, at least at design time. It requires the new .NET Core SDK project system.
A good migration how-to I’ve recently followed — https://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/.
#MattBrooks and #ScottChamberlain are correct and this is a Visual Studio csproj issue and following the link #MattBrooks provided is the correct answer to this question (I've marked it as such). However, I also wanted to share my personal experience with this in the hopes it will help others who find this process convoluted and confusing (and it doesn't seem right to plop this into an update to the question). As Matt says, "it can be very confusing and sometimes the tooling doesn’t help very much."
Here is the exact procedure I used to convert my projects over. After trying to manually convert a couple, I gave up and rebuilt them:
Remove Project from Solution
Copy Project Folder to Backup Location
Add New ".NET Standard" Class Library Project with Same Name
Edit new .csproj and Change <TargetFramework> to net461 (or whatever you need. Note this can't be done from the Target Framework UI Dropdown. All you'll see is "Net Standard").
Copy all <package> elements from backup projects packages.json (if you don't have a package.json see the outline from the accepted answer to convert your csproj <References> to <PackageReferences>)
Create <ItemGroup> in new csproj
Paste in <package> elements
Find Replace:
<package id= --> <PackageReference Include=
targetFramework=".*" --> <blank>
version --> Version
Open Backed-Up .csproj and copy all <Reference Include=... That DON'T HAVE Version=4.1.0.0, Culture=neutral, PublicKeyToken=..." e.g. that look like <Reference Include="System.Web" /> and paste into new csproj and save.
At this point, NuGet will restore your packages.
If you (likely) end up with NuGet Dependencies that have Yellow/Warning Triangles:
Try to build and see if you get any errors/warnings in the error list. I had some versions that didn't jive between projects. Apparently that's a full stop issue now.
I had some Pre-Release NuGet Packages from a Private Feed that I had to re-install manually.
If all else fails, remove the reference from csproj and install directly from NuGet
If all else all else fails, uninstall and reinstall the package from the VS Package Manager
Copy content files and folders from Backup Project into New Project Folder - VS Will Pick them Up and Auto-Add to Project. I also had to copy node_modules for projects that had NPM packages installed from the backup back into the new project.
Add back any solution project references you may have.
Now, the fun part if you're an idiot like me and had files "excluded from project"....you must hunt those down and remove them.
I would also note that if you (like me) had <Reference> tags to packages in your csproj and a package.json, I found that the package.json was accurate in terms of having the correct versions.
I was not able to convert a single MVC4/WebAPI2 project over because there doesn't seem to be a way in the new project format to tell it "This is a web project, run IIS and debug"...in that all new Core projects expect an static void Main. Probably a different question though.
I was able to get the MVC4/WebAPI2 App Migrated Using the Answer Provided here: https://stackoverflow.com/a/49655107/3892531
Good Luck!
Related
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)
I am trying to write some unit tests in C# in a '.NETFramework,Version=v4.5.2' application but all tests give the next error:
'System.IO.FileNotFoundException : Could not load file or assembly
'System.Drawing.Common, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file
specified.'
When I try to install System.Drawing.Common I get the next error from the NuGet package:
Could not install package 'System.Drawing.Common 4.5.1'. You are trying to install this package into a project that targets
'.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more
information, contact the package author.
I cannot change the application version or the framework (.NET Core 2.1) and any other trick I found online did not work (or generated more errors).
Help?
in NuGet put this line :
Install-Package System.Drawing.Common -Version 4.5.2
in .NET CLI put :
dotnet add package System.Drawing.Common --version 4.5.2
in Paket CLI put :
paket add System.Drawing.Common --version 4.5.2
Had the same problem. I have cloned solution https://github.com/barnhill/barcodelib . It has two projects: library project targets .Net Standard 2.0 and refers to System.Drawings.Common. Example project depends on library and has reference to System.Drawings.Common. Example project was not compiling due to same error.
My solution was just to remove reference to System.Drawings.Common in nuget packages and readd it (rclick on Example project > Manage nuget packages > Browse Installed, remove the System.Drawings.Common package, and then add it back), unload project and then reload it again
Helped for me.
I managed to solve it by restarting Visual Studio, changing the framework to 4.6.1 (which I could not do before) and adding the reference.
OP's solution migrated from the question to an answer.
you could try to use one of the libs described in here instead https://devblogs.microsoft.com/dotnet/net-core-image-processing/
you could try to use https://www.nuget.org/packages/CoreCompat.System.Drawing/ as well and maybe try to change your app framework to .net standard 2.0?
This is kind of bizarre but it worked dramatically so I'm going to mention it. I built a small vs 2017 ent console project that was supposed to read an oracle database. When I started to run it I got the System.Drawing.Common error mentioned above. It seemed stupid because I wasn't really doing anything having to do with Drawing at all. In Manage Nuget Packages I deleted the Oracle.ManagedDataAccess driver and added the Oracle.ManagedDataAccess.Core and the System.Drawing.Common error went away and I was able to read my oracle database. So I'm suggesting that with NuGet you may be picking up some things you really don't need and if you have any choice for your NuGet packages, try different ones. This also may be some foible with how my organization managed nuget for Visual Studio 2017 enterprise.
I got the below error while building the Enterprise Bot Template Project in VS2017. Not sure what i 'm doing wrong here.
Severity Code Description Project File Line Suppression State
Error CS1703 Multiple assemblies with equivalent identity have been imported: 'C:\Users\XXX.nuget\packages\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Runtime.Serialization.Json.dll' and 'C:\Users\XXX.nuget\packages\system.runtime.serialization.json\4.3.0\ref\netstandard1.0\System.Runtime.Serialization.Json.dll'. Remove one of the duplicate references. SovereignBot C:\Users\XXX\Documents\Visual Studio 2017\Projects\SovereignBot\SovereignBot\CSC 1 Active
Any ideas how to fix?
I'm not able to replicate this issue with a fresh install of the Enterprise VSIX template. This leads me to believe the issue is either in your code or on your machine.
After researching, it appears there could be a couple of problems and solutions:
Your Local/Development and Build servers use different versions of Visual Studio
Update Visual Studio for both environments
If you're still experiencing issues, try installing the Microsoft.CodeDom.Providers.DotNetcompilerPlatform NuGet package.
NuGet or .NET Core is out of date
Update NuGet
Update the appropriate .NET Core SDK. Currently, Bot Framework is supported well on .NET Core 2.2. Keep in mind that if you have 2.2 installed, you may need to update to the latest sub-version (v2.2.104, as of now). Keep in mind you may also need to upgrade your NuGet packages within the project in order to be compatible to the .NET Core SDK.
Ensure your bot is using the correct .NET Core Target Framework by right-clicking the Project > Properties > Application:
Your Visual Studio version doesn't handle dependency version collisions on its own
Update your Visual Studio
You have a duplicate reference to the same package (but possibly different versions) in your .csproj file
This is more likely if you're using code brought in from another project.
Delete or comment out the duplicate by right-clicking on your Project in Visual Studio, and clicking Edit .csproj:
You have a package installed via both NuGet and locally
(I don't believe this is the issue for you, since both of your packages appear to be in the NuGet directory)
Go to the file path of one of the dependencies and delete it.
I'm trying to use a Windows Service to host a simple ASP.Net Core web app targeting .Net core 2.x, as detailed here by Microsoft.
This should be simple with the docs, but I'm getting nowhere because the Microsoft.AspNetCore.Hosting.WindowsServices package doesn't seem to work with any version of .Net Core (the NuGet page says it depends on .Net Standard). Simply opening a project will cause Visual Studio to get stuck at NuGet restore, without any error message whatsoever (I have to kill the VS process manually, as closing VS would cause it to stop responding). Running dotnet restore from command will cause cmd gets stuck at "Restoring packages for XXX".
The same thing happens with the sample code in ASP.Net official docs. I guess this must mean a machine- or platform-specific issue to me but I have tried with various (fresh) VMs and am out of ideas. The only thing that works so far is this answer here, i.e targeting .Net Framework and explicitly list all the package references rather than using Microsoft.AspNetCore.All.
I'm using VS2017 15.7.6. Any help on this issue would be greatly appreciated!
Update
The problem magically disappeared after I installed the Azure development workload in VS2017. I already had ASP.Net and .Net Core workloads before, so I really can't figure out which individual component did the trick, but it did solve the problem.
Yes, this answer is correct. The windows-service package only runs on windows. You have to directly target each package you need, because the Microsoft.AspNetCore.App (.NET-Core >= 2.1) and Microsoft.AspNetCore.All (.NET-Core >= 1.1 <= 2.0) packages, contain package(s) that target .NET-Core instead of .NET-Standard.
You could target both frame-works using
<TargetFrameworks>net471;netcoreapp2.1</TargetFrameworks>
and have conditional includes in your project file + compiler directives in your c# code.
<!-- CSPROJ CONDITIONAL REFERENCE -->
<PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.1.1" Condition="'$(TargetFramework)' == 'net471'" />
// c#-code compiler directive
#if net471
using Microsoft.AspNetCore.Hosting.WindowsServices;
#endif
Keep in mind that using the full .NET-Framework will make you lose the performance improvements introduced with .NET-Core.
I am sure you could also have a batch script / windows task that starts your .NET-Core service each time your windows machine restarts.
I just had a similar problem. We have multiple Nuget package stores, and one of them was experiencing certificate issues.
I fixed it by doing the following:
Right-click on project Dependencies in Solution Explorer, and click Manage Nuget packages.
In the Package Manager, in the Installed tab, you should see the package, select the Microsoft.AspNetCore.Hosting.WindowsServices package. It will be showing a version 0 and some indication that it is failing to download.
You may also see the Package source in the top-right pointing to one of the custom Nuget stores. Change the Package Source to ALL. That will cause the window to refresh, and then you may see the correct version and an Update button.
Now click the Update button to update. My version is now 2.1.1.
Looking at the project file now, it changed the package reference to:
<PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.1.1" />
I want to use C# 6 in my project (null propagation, other features).
I've installed VS 2015 on my PC and it works brilliantly and builds test code like
var user = new SingleUserModel(); //all model fields are null
var test = user.User?.Avatar?["blah"];
But when I push my project to the repo and CI starts to build it, build fails because of unsupported ?.
I've installed VS2015 on CI server too but looke like it doesn't use it.
What can I do?
CI - CruiseControl .NET
Builds with C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Make sure you call:
C:\Program Files (x86)\MSBuild\14.0\Bin\MsBuild.exe
That's the version of MsBuild that ships with Visual Studio 2015 and calls the C# compiler that understands this. You can get this version of MsBuild on your system by installing any edition of Visual Studio 2015 or by installing the stand-alone Microsoft Build Tools 2015.
Adding a reference to the following NuGet package will also force use of the new compiler:
Install-Package Microsoft.Net.Compilers
Please note Install-Package will pick the latest available version which may not be the one you are looking for. Before you install, please check the release notes and dependencies to resolve the underlying issue with the version being dealt with, which in this case, was more specific to VS 2015.
So for Visual Studio 2015:
Install-Package Microsoft.Net.Compilers -Version 1.0.0
You can by the way also install the "Microsoft Build Tools 2015" instead of VS2015 on your build server.
https://www.microsoft.com/en-us/download/details.aspx?id=48159
It installs MSBuild to the same path:
C:\Program Files (x86)\MSBuild\14.0\Bin\MsBuild.exe
You probably already have this working, but this might help someone else in the future. I came across this question recently and it got me moving in the right direction and ultimately led to a solution.
Another possible solution to this is manually updating your project files to target the MSBuild version you want your projects to be built with.
I've recently gone through a TeamCity build server update and I've already installed the Microsoft Build Tools 2015 on it. I thought I had everything in place on the build server, I had my solution targeting C# 6.0, and I had every project targeting .net 4.6.1. Like you, everything with C# 6.0-specific code built just fine in my local environment, but my TeamCity build server didn't like any of it.
As mentioned by others, I tried using the Microsoft.Net.Compilers NuGet package. The latest version of it allowed the build to work on my build server, but it wouldn't let me publish my code locally (a requirement of mine). Earlier versions of that NuGet package would let me publish, but the build wouldn't work.
What I found that I had to do was ultimately modify each project file in my solution to specifically target the MSBuild version that could handle C# 6.0 code. In each of my project files, I found a line similar to the following line:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
with the key component of that line being the ToolsVersion portion of it. I simply changed this line on my project files to read the following:
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
The difference here was that I was targeting version 14, not 4. Version 14.0 corresponds with Build Tools 2015. By changing this, my TeamCity build server used the correct MSBuild version and was able to build my C# 6.0 code.
I also had to manually update the TargetFrameworkVersion xml node of this to use 4.6.1 because VS2015 wasn't doing something right and messed up my local build, but that's not relevant here.
Please, someone correct me if I'm wrong, but just for reference, I think the version numbers go something like this:
4.0 = VS2012
12.0 = VS2013
14.0 = VS2015
15.0 = VS2017
I believe if you wanted to use .net 4.7, you'd have to have the Build Tools 2017 installed and have your projects targeting 15.0 instead of 14.0, but I haven't verified this.