Working in a team we have solution in Git that is being developed by 3 different devs. I went temporarily to different place with my laptop where I have fresh Win 10 Pro as well as VS 2019 Community (16.7.1). Having pulled out solution from team's Git I have a lot of NU1701 warnings and NU1202 errors. Other devs work with this very solution fine.
Target framework - .Net Core 3.1. Have installed dotnet core 3.0, 3.1.
Have read a lot of similar issues here, so tried to clean NuGet cache, deleting bin/obj folders, re-installed VS, installed VS 16.8 Preview along with 16.7.1 - no effect. The most confusing point is that the same solution builds fine on boxes of my colleagues but doesn't on mine.
Please advise what I can me missing in OS/VS setup?
Finally, after couple more hours of try-and-fails, I got my solution built. Hard to say what exactly prevented VS to build before, but generally what I did is one more time to remove .vs, bin, obj from solution, some cache-like folders in %user%/AppData/local, added Windows features like .NET Framework 3.5, turned on 3.5 in Internet Inf Services/App Development Features, some Security settings like Basic Auth, Centralized SSL Certificate Support etc.
Related
When I try to right click (in the Solution Explorer) and add the existing project to solution, I get the error:
The .NET Core SDK cannot be located. .NET Core debugging will not be enabled. Make sure the .NET Core SDK is installed and is on the path
I checked here (where they get the same error on VS Code) and tried repairing, installing, reinstalling Visual Studio and my .Net 6.0 and 7.0 SDKs. Made sure to install the SDKs even with VS not open, even after a fresh restart. Nothing worked. Plus, some of those solutions seemed specific to VS code, not VS Studio.
Not sure how relevant this detail is, but this my first attempt at installing Visual Studio on this computer.
The problem persisted regardless of project type (WPF and Console were attempted), .Net version (tried making .Net 6.0 and 7.0 apps, which are the 2 sdks I've got installed), and whether or not I indicated I wanted the project and solution in the same directory.
Those were my guesses, and nothing's worked.
Here's what it looks like when I create a new project:
Open visual studio installer and make sure you have installed .Net Framework Developer correctly.
Select .Net 6.0 on this page
Can you create a wpf .net 6 project according to this flow.
If it still doesn't work, please try the repair button in the installer.
The problem turned out to be that the SDKs weren't ordered correctly in the environment variables. C:\Program Files (x86)\dotnet was listed before C:\Program Files\dotnet. I found the solution here.
Not exactly a duplicate issue though, as issues were sort of different, but had the same fix.
Just downloaded and installed SDK Net 7.0.100 and it broke existing applications and they won't load any more in VS 2022 or Rider.
Copied the follwing error:
error : SDK Resolver Failure: "The SDK resolver "Microsoft.DotNet.MSBuildSdkResolver"
failed while attempting to resolve the SDK "Microsoft.NET.Sdk". Exception: "Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadManifestCompositionException: Workload definition 'wasm-tools' in manifest 'microsoft.net.workload.mono.toolchain.net7' [C:\Program Files\dotnet\sdk-manifests\7.0.100\microsoft.net.workload.mono.toolchain.net7\WorkloadManifest.json] conflicts with manifest 'microsoft.net.workload.mono.toolchain' [C:\Program Files\dotnet\sdk-manifests\7.0.100\microsoft.net.workload.mono.toolchain\WorkloadManifest.json]
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.ComposeWorkloadManifests()
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.Create(IWorkloadManifestProvider manifestProvider, String dotnetRootPath, String sdkVersion, String userProfileDir)
at Microsoft.NET.Sdk.WorkloadMSBuildSdkResolver.CachingWorkloadResolver.Resolve(String sdkReferenceName, String dotnetRootPath, String sdkVersion, String userProfileDir)
at Microsoft.DotNet.MSBuildSdkResolver.DotNetMSBuildSdkResolver.Resolve(SdkReference sdkReference, SdkResolverContext context, SdkResultFactory factory)
at Microsoft.Build.BackEnd.SdkResolution.SdkResolverService.TryResolveSdkUsingSpecifiedResolvers(IList`1 resolvers, Int32 submissionId, SdkReference
I experienced a similar problem.
I uninstalled the 7.0.100-preview.5.22307.18 sdk using add remove programs and then changed the TargetFramework in the project file to use 7.0 and then I was able to load the projects.
EDIT: This is officially documented in the release notes known issues.
I'm from the .NET SDK team. Sorry you're going through this. I would love to comment on the other answers, but I don't have the reputation to do so.
What Tim Farley suggested is an officially endorsed workaround; uninstalling any preview 7 SDKs with add/remove programs should resolve the problem.
As for why this happened and why uninstalling preview SDKs will fix the issue, there's a bit of an explanation I put here: https://github.com/dotnet/sdk/issues/28947#issuecomment-1307987337.
TLDR: Some workloads were renamed in the middle of .NET 7 preview development to support things like multitargeting, and when you download the new RTM old preview files interfere can with it.
Updating the TargetFramework is recommended but it's unrelated to this issue. Usually breaking changes for each .NET version and related new features are gated behind your TargetFramework (TFM), so things don't break until you update the TFM, not when you update the SDK. (Unfortunately, not true in this case.)
In response to whether this will happen again or not when upgrading to .NET 8, per Scott: with how workloads are currently structured this issue would happen again. We're discussing how to make changes to prevent this from happening again though as it's not ideal. We're also considering adding dotnet workload clean or something to repair this for you. Communicating with us on the SDK GH thread, or with me here, is a good way to send us feedback about this.
Repairing Visual Studio installation did not help me. Neither did uninstalling .net 7 faulty workload ('wasm-tools'), since any attempt to uninstall or repair it ended up in the same error message.
Being ran out of conventional options to address the issue, I just went ahead and physically deleted the conflicting folder: microsoft.net.workload.mono.toolchain, leaving second one microsoft.net.workload.mono.toolchain.net7 intact. It luckily solved problems on my machine. From now on I'll be more cautious on installing Ms RC packages
I had a similar problem, even on new .Net projects. I uninstalled the 7.0.100-preview.2.22153.17 SDK using add remove programs and I was able to create a new project again. I am now left with only one .Net 7.0 SDK (from Visual Studio) as shown below.
Uninstall Microsoft .Net SDK 7.0 preview
I had the same issue as above except on my M1 mac. I followed the following guide and manually removed all the directories for all the .net 7 runtimes and sdks. Then reinstalled .net7 and all seems to be well now. rider can open my projects and the dotnet cli no longer complains
Not sure if a similar scorched earth approach will work for the windows folks.
https://devkimchi.com/2021/11/24/removing-dotnet-sdks-from-macos-manually/
I had the same issue, except that no preview version of .NET 7 was currently installed on my system, but the preview artifacts were still in the C:\Program Files\dotnet\sdk-manifests\7.0.100 directory. My solution was to uninstall the stable version of .NET 7 (not the version from VS 2022), then install and uninstall 7.0.100-preview.7. Doing so resulted in the preview artifacts being removed and this error being resolved.
I had same problem, but i think the problem because M1 mac
Had the same problem. Deleted manually installed net 7 sdks in windows uninstaller.
I found out that I needed to rm -rf **/obj
(delete all folders named obj) in the solution root folder after upgrading from net 6 to net 7, in addition to dotnet clean
I made a WPF and Console application for someone to use on their private server which I can't have access to. I used Visual Studio 2019's built-in "Publishing Wizard" to create Framework Dependant single-file apps. When the person opened the WPF app they were greeted with the standard warning:
They clicked yes and to my understanding, they installed .Net Core 3.1 which is what the applications target.
After they restarted the computer they got the exact same warning again. I wasn't sure what was going on so I repackaged the apps as self-contained since the installed version of .Net Core was the same as what my applications were targeting.
That seemed to work for a little bit. We ran into some unrelated issues that I had to fix in the code on my end and then I re-published the projects and sent them out.
They tried to use the WPF application and they got the install warning again.
Now no matter what combination of options I pick in the "Publish Wizard" they keep getting the warning.
I'm not sure what to do.
Here's a picture of my publish settings
In my case I had the same issue, and the problem was that I was not deploying the file "MY_PROGRAM_NAME.runtimeconfig.json". After copying this file, which is present in the build output, the application is launched without problems.
Turns out the issue was the fact that the applications were targeting win-x86 and the user only had access to 64-bit runtimes of .Net Core.
For some reason, I thought it would be able to handle a 32-bit version even if it was running 64-bit runtimes.
I guess live and learn.
I have installed VS2019 on the E: drive of my machine rather than the smaller c: boot drive. I had it installed before I Wiped the machine on the c: drive and it took up WAY to much space. Now It gives me this error message AND WILL NOT allow me to pick any targeting .NET Framework on C# WFA before 4. I have NO Idea what to do, Ive followed the advice and went to the website listed and manually downloaded the .NET Core SDK for 2.0 and installed it, then tried to repair it, and it JUST KEEPS SAYING ITS NOT INSTALLED, the project needs .net 2.0 to work. Am I gonna have to wipe the WHOLE computer again and take up ALL the space on my boot drive to get this damn thing to work? I just don't understand, It does this on enterprise & community, how the hell can Microsoft NOT excpect an ENTERPRISE to install VS 2019 ON another drive then the boot drive, ESPECIALLY WHEN ALL THE TOOLS YOU NEED ARE GARGANTUAN.
IVE TRIED EVERYTHING THE ERROR MESSAGE SAYS. there are 2 options it gives to load the project, 1. DOWNLOAD the sdk manually for .NET FRAMEWORK 2.0 WHICH IVE INSTALLED AND REPAIRED, 2. CHANGE THE PROJECT TO .NET 4.0, WHICH I CANNOT DO. or the worst option JUST CLOSE THE SOLUTION
I want to be clear that I Have another machine that this project pulls up perfectly with VS 2019 and I know people are gonna jump to the Microsoft doesn't support something that old bandwagon. It gives me the option to target .NET Framework 2.0 on the other machine RIGHT NOW, and did on this one for VS 2019 Community AND ENTERPRISE BEFORE INSTALLING ON AN OTHER THAN BOOT DRIVE, so wheteher they TECHNICALLY SUPPORT IT IN ALL THE DOCUMENTATION IS A VOID ARGUMENT, it worked perfectly before on this exact machine, and does an another one with VS 2019, if it was a support issue I seriously doub MS would give an error messae saying to install .net 2.0, I knew installing CORE probably wouldn't work, but that's the websit it sent me to.The point is they DID just 2 days ago, Microsoft randomly stops supporting legacy features like that on an ENTE#RPRISE PRODUCT with NO warning after release? Now I see why a lot of c++ people DESPISE VS.
If something in your project absolutely requires the .NET framework 2.0, try installing it from https://www.microsoft.com/en-us/download/details.aspx?id=19988 (this is NOT .NET Core)
Visual Studio 2019 doesn’t support older .NET Framework versions than 3.5, see documentation. If you really need .NET 2.0 you need to install an older Visual Studio that has support for that version.
.NET Core is completely different thing than .NET Framework 2.0 so installing that doesn’t help.
This has nothing to do with where you install applications.
Also note that support for 2.0 has ended a decade ago so if this project is needed it would be highly recommended to update it into a newer version. There usually aren’t many reasons why this cannot be done.
Fixed it for anyone that EVER has this problem again, you've got to search through some deprecated websties but im absolutely sure If you've made it this far you can figure out how to install the .net faramework 2.0 sdk if you just search hard enough lol
I am working on a project on TFS. This project was created on someone else's PC on VS 2017 and the newest .NET framework and published to Azure.
I got the project on my PC, I have VS 2015 and I had to change the .NET framework of the project to 4.6. Everything was fine, I could make changes to the project and commit.
But when I tried to publish to Azure from my PC, I got a very unclear error:
Publish Failed
Connecting to ...
Looking for solutions online, I had to downgrade the version of the package Microsoft.Net.Compilers from 2.6.1 to 2.4.0 . And that worked !
I turned off my PC. Next day when I opened the project and ran it, I got this error locally :
Could not load file or assembly 'Microsoft.ApplicationInsights, Version=2.6.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
I tried to uninstall Microsoft.ApplicationInsights and reinstall it with version 2.6.1 , but it says i need a newer version of nuget.
I am not sure how to proceed from here. I already installed all the updates in my Tools -> Extensions -> Updates but nothing changed.
Why are all these things happening to my project and how can i fix it?
PS: upgrading my VS to 2017 is currently not an option due to many exterior reasons.
Thank you.
I've gotten that error locally as well and was actually able to resolve by manually adding the file to my project folder, may be worth a shot.
Downgrading .NET Framework causing packages issues
Just like Hans said nuget packages change quite rapidly, which often require the latest version NuGet. Some new features in the package only supported by the newer NuGet (like PackageReference) or some issues fixed on the newer version. For example, install package Microsoft.EntityFrameworkCore.SqlServer 2.1.1 on Visual Studio 2015, which requires NuGet client version '3.6.0' or above.
So, the workaround for this issue is create a new project with Visual Studio 2015, copy the code from previous projects, then add those nuget package one by one to find out the reason why it needs the newer version nuget.
However, I want to talk more over about this question is that the best way to resolve this issue is to install Visual Studio 2017 alongside Visual Studio 2015. As we known, using a lower version of the Visual Studio and .net framework to open a higher version of the Visual Studio and .net framework is not recommended, it will always bring a lot of incompatibility errors and some other weird issues. Since upgrade your Visual Studio to 2017 is currently not an option due to many exterior reasons, so I suggest that you can install Visual Studio 2017 alongside Visual Studio 2015. Besides, developing the same project with different versions of Visual Studio and submitting it to the TFS server may bring many unpredictable risks.
Hope this helps.