search

dotnet / core

.NET news, announcements, release notes, and more!
https://dot.net
MIT License
20.97k stars 4.91k forks source link

It was not possible to find any compatible framework version The specified framework 'Microsoft.NETCore.App', version '2.1.0' was not found. - The following frameworks were found: 3.0.0 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] You can resolve the problem by installing the specified framework and/or SDK. The .NET Core frameworks can be found at: - https://aka.ms/dotnet-download #3487

Closed ghost closed 5 years ago

ghost commented 5 years ago

Problem encountered on https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/run Operating System: windows

Provide details about the problem you are experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.

validide commented 5 years ago

I'm having a similar issue tying to build a netstandard2.1 project on the Debian 10 image mcr.microsoft.com/dotnet/core/sdk:3.0-buster.

Console output:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     debian
 OS Version:  10
 OS Platform: Linux
 RID:         debian.10-x64
 Base Path:   /usr/share/dotnet/sdk/3.0.100/

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  3.0.100 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
Microsoft (R) Build Engine version 16.3.0+0f4c62fea for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
  - The following frameworks were found:
      3.0.0 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

On the local Windows machine the same commands are working. I will try tomorrow to build the hello world example.

validide commented 5 years ago

Ignore my previous comment. The build pipeline was miss-configured and it was trying to analyze the project using SonarQube.

roxxshivamsingh commented 5 years ago

Finally I resolved this problem!! Because of 3.0 version. You need to uninstall completely with following steps: 1.go cmd and type "dotnet tool uninstall -g mlnet"

  1. Go program files and uninstall dotnet core 3.0
  2. download (if you don't have) 2.2.204 version which is capable for dotnet mlnet Thanks!!
pmunshi007 commented 5 years ago

I am facing the same issue . @roxxshivamsingh I did not understand here. So is this error because of mlnet tool only? I need to have dotnet core version 3.0 only. I dont want to downgrade it to 2.2.204

pmunshi007 commented 5 years ago

Hello @roxxshivamsingh , I understand the solution mentioned here is to remove 3.0 version all together and use 2.2.204 version to utilize mlnet capability to not get error mentioned in the subject line.

But is there any work around to use dotnet version 3.0 without error? I am trying to use ./dotnet-ildasm command to get AssemblyFileVersionAttribute from the dll file but I am facing error mentioned in the subject line. This process was running fine with version 2.2.xxx but started failing since we upgraded to dotnet version 3.0

Any help would be appreciated .

dagood commented 5 years ago

I don't think you need to uninstall or install any SDKs, only a .NET Core Runtime that can run the tool. I think the latest Runtime 2.2.x will do the trick: https://dotnet.microsoft.com/download/dotnet-core/2.2.

matttrakker commented 5 years ago

I have the same issue. Project has been 2.x including an xunit project. Everything has been fine.

I have upgraded to version 3.x and now I get the mentioned error and the following output: C:\Users\VssAdministrator\.nuget\packages\microsoft.net.sdk.functions\1.0.29\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(41,5): error : The specified framework 'Microsoft.NETCore.App', version '2.1.0' was not found... I'm running the build on a Hosted agent in devops, image windows-latest I have a seperate install 3.x step in the pipeline ;)

si2030 commented 5 years ago

Yes and me as well.. I have uninstalled all traces of Visual Studio as well as every possible SDK as well as dotnet. I cannot find for the love of god the place it refers to 2.2.0 yet it tries to use it here.

Right now when I try and create a migration the whole process screws up and I end up having fake data that is missing the first records ID in every table... I think the first think is to make sure all is compatible etc but now I find this inconsistency and have no idea where its getting 2.2.0 when I have referenced 3.0.0 everywhere.. I even put in a global.json with SDK 3.0.100 and it STILL wants to go to 2.2.0.

Quite frankly the reason you pick Microsoft's Visual Studio because it works but right now I am chasing my tail on this and wasting time I shouldnt be. Its not good enough.

Why is it trying to use 2.2.0???

It was not possible to find any compatible framework version The specified framework 'Microsoft.NETCore.App', version '2.2.0' was not found.

  • The following frameworks were found: 3.0.0 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
hellfirehd commented 5 years ago

I'm running into what appears to be the same issue on CentOS 7:

[root@xxx feh]# dotnet --info
  It was not possible to find any installed .NET Core SDKs
  Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
      https://aka.ms/dotnet-download

Host (useful for support):
  Version: 3.0.0
  Commit:  95a0a61858

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
[root@xxxx feh]# ./myApp
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The .NET Core frameworks can be found at:
  - https://aka.ms/dotnet-download
am11 commented 5 years ago

You can also try installing .NET Core 3.0 using the following one liners:

Docs: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

Unix Shell (Linux / WSL and macOS)

curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin -Channel 3.0

Windows PowerShell:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; &([scriptblock]::Create((Invoke-WebRequest -UseBasicParsing 'https://dot.net/v1/dotnet-install.ps1'))) -Channel 3.0

Windows cmd:

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; &([scriptblock]::Create((Invoke-WebRequest -UseBasicParsing 'https://dot.net/v1/dotnet-install.ps1'))) -Channel 3.0"
hellfirehd commented 5 years ago 
curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin -Channel 3.0

I gave that a shot but exact same results.

Is there an environment variable that needs to be set that points to .NET? Something equivalent to $JAVA_HOME?

am11 commented 5 years ago

You have found a bug in the install script. Nice catch! 😅

If there is no sdk installed on a system (but only the dotnet-core runtime), dotnet-install script encounters a false positive and skips the installation:

curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin \
    -Channel 3.0 --verbose | grep already

shows:

dotnet-install: .NET Core SDK version 3.0.100 is already installed.

(even after i deleted all sdks sudo rm -fr /usr/local/share/dotnet/sdk and dotnet --info output was identical as yours)

To workaround: mv ~/.dotnet ~/.dotnet.backup followed by curl -sSL https://dotnet.net... command.

hellfirehd commented 5 years ago

Okay, so that didn't help. I ran mv ~/.dotnet ~/.dotnet.backup and then ran the curl ... again. When I ran my program I got the exact same results as previous.

So next I completely remove all traces of .NET Core using both yum and some judicious rm -Rf ...

Then I did some find / -name dotnet and got nothing back.

A quick reboot and then I ran curl ... again. It appears to have installed but does not add ~/.dotnet to my $PATH so I added it myself.

Next up I ran my program again with the following results:

[root@xxxx ~]# cd /opt/myApp
[root@xxxx feh]# ./myApp
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The .NET Core frameworks can be found at:
  - https://aka.ms/dotnet-download

Crap!

[root@xxxx ~]# dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     centos
 OS Version:  7
 OS Platform: Linux
 RID:         centos.7-x64
 Base Path:   /root/.dotnet/sdk/3.0.100/

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  3.0.100 [/root/.dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0 [/root/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0 [/root/.dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

You'll note that this time I have the SDK installed, not just the runtime.

I don't know if it matters, but the app was compiled on Windows 10 with the following:

> "C:\Program Files\dotnet\dotnet.exe" publish --configuration Release --framework netcoreapp3.0 --runtime linux-x64 --self-contained False

And on that machine dotnet --info produces the following:

.NET Core SDK (reflecting any global.json):                                                                                                                                                                                                                            Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100\

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  2.1.700 [C:\Program Files\dotnet\sdk]
  2.1.701 [C:\Program Files\dotnet\sdk]
  2.1.801 [C:\Program Files\dotnet\sdk]
  2.1.802 [C:\Program Files\dotnet\sdk]
  2.2.300 [C:\Program Files\dotnet\sdk]
  2.2.301 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  2.2.402 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

I'm at my wits end!

am11 commented 5 years ago

I don't know if it matters, but the app was compiled on Windows 10

It shouldn't matter; I just published a hello-world on Windows 10 and ran on WSL:

(both Windows 10 and WSL Ubuntu are running dotnet 3.0.100)

~\Source\Repos> dotnet new console -n myApp
~\Source\Repos> cd myApp
~\Source\Repos> dotnet publish --configuration Release --framework netcoreapp3.0 --runtime linux-x64 --self-contained False
~\Source\Repos> bash
adeel@Adeel-PC:/mnt/c/Users/adeel/Source/Repos/myApp$ bin/Release/netcoreapp3.0/linux-x64/publish/myApp
Hello World!

Can you create and run a hello-world app on your CentOS?

hellfirehd commented 5 years ago

All right! Now I think we're getting somewhere!

[root@xxxx helloworld]# ./HelloWorld

A fatal error occurred. The required library libhostfxr.so could not be found.

If this is a self-contained application, that library should exist in [/opt/helloworld/].

If this is a framework-dependent application, install the runtime in the global location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].
am11 commented 5 years ago

Something equivalent to $JAVA_HOME?

How about: DOTNET_ROOT=/opt/dotnet ./HelloWorld? :)

hellfirehd commented 5 years ago

Googling with Bing found this: https://docs.microsoft.com/en-us/dotnet/core/build/distribution-packaging

Relocating ~/.dotnet to /usr/share/dotnet (note there's now no '.') made ./HelloWorld work. But not my original application.

So now that I've got the SDK on that box I'm going to try building it there and see what happens.

hellfirehd commented 5 years ago

Looks like this might be related.

devna13 commented 5 years ago

same problem here https://github.com/dotnet/core-sdk/issues/5287

carlossanlop commented 5 years ago

@dagood @livarcocc @nguerrera can you help with this?

dagood commented 5 years ago

This issue seems to have become a bit of a lightning rod for missing framework issues due to the title.

  1. The original issue didn't include any information about the scenario or how to reproduce.

    • I think this is part of why there was so much pile-on. Without a clear repro project or steps, there's no way to know which scenarios are different and from the outside, it seems like the right idea to add apparently similar issues to this thread.

  2. (https://github.com/dotnet/core/issues/3487#issuecomment-537167564 Another issue came up but turned out to be a configuration problem.)

  3. https://github.com/dotnet/core/issues/3487#issuecomment-538452657 An issue came in about the mlnet dotnet tool, suggesting a workaround of uninstalling 3.0 and installing the required 2.2 version.

  4. https://github.com/dotnet/core/issues/3487#issuecomment-539192968 A 2.1.0 requirement.

    • Some more detail than the original issue, but not enough for me to recognize the scenario. This may be better to ask that package's owners about, and/or browse info about it: it looks like Microsoft.NET.Sdk.Functions is developed in https://github.com/Azure/azure-functions-vs-build-sdk.

  5. https://github.com/dotnet/core/issues/3487#issuecomment-539266483 A migration tool that has a 2.2 requirement. I think this is also a dotnet tool, so the case is similar to (3), mlnet.

  6. https://github.com/dotnet/core/issues/3487#issuecomment-539670974 An issue about dotnet being unable to find a framework at runtime. Looks to me like DOTNET_ROOT wasn't set, and it wasn't able to find the runtimes in the default location either.

I'm closing this: the original issue doesn't have enough info to repro or understand the scenario, and the comments share a symptom but I don't see a significant common thread that's not addressed.

Please do open a new issue if the above doesn't help, and if at all possible, do include a repro project and steps to make sure your individual problem is being addressed.

PaulCombal commented 5 years ago

I think I found a better way around it for myself:

# Check your installed tools with $ dotnet tool list -g
$ dotnet tool uninstall dotnet-ef -g
$ dotnet tool uninstall dotnet-dev-certs -g # If you have it installed
$ dotnet tool install dotnet-dev-certs -g # If you had it installed
$ dotnet tool install dotnet-ef -g
jzabroski commented 4 years ago

5. #3487 (comment) A migration tool that has a 2.2 requirement. I think this is also a dotnet tool, so the case is similar to (3), mlnet.

@dagood tl;dr: I'm searching for answers to three questions:

  1. How do I run a .NET Core 2.2 tool on .NET Core 3.0 without recompiling it?
  2. Is .NET Core 3.0 backwards compatible with .NET Core 2.2 the same way .NET Framework 4.6 is backward compatible all the way to .NET Core 1.0?
  3. Can a .NET Core 2.2 assembly have a TypeForwardTo a .NET Core 3.0 assembly? Or is TypeForwardTo now just a run-time "rename refactoring" for the .NET Linker? It is a confusing to me why TypeForwardTo even exists in .NET Core if we can't roll-forward old exe/dll to new runtimes, since the main use case David Broman presented in 2009 was rolling old exe/dll built against old runtimes and moving those to new runtimes

Background Noise

I wonder if the "migration tool" @si2030 is using is FluentMigrator.DotNet.Cli (or Microsoft's EntityFramework migration tool dotnet tool install --global dotnet-ef). Something I couldn't find the answer to, and simply don't know the answer to, and was hoping you would've "stated the obvious" in your long reply: Why can't users with .NET Core 3.0 installed run a .NET Core 2.0 tool? Does this mean as an open source maintainer of a tool, I need to lock-sync recompile my binaries the day .NET Core x.y is released, every time you guys do a release? Is there no way for my open source customers to simply "roll forward" from .NET Core 2.0 to 3.0? (I have an open pull request asking me to add .NET Core 3.0 support - and I just don't understand what risks there are with such changes, and how to troubleshoot regressions coming in from customers when dotnet tool install dotnet-fm -g is installed.)

THIS is the set of questions that seem to be driving all the confusion, because in the old .NET Framework world, you could run a .NET 2.0 assembly on .NET Framework 4.0. MSDN states .NET Framework 4.6 is version compatible all the way back to .NET Framework 1.0 I found this brief MsDocs note from @Rick-Anderson stating:

The SetCompatibilityVersion method is a no-op for ASP.NET Core 3.0 apps. That is, calling SetCompatibilityVersion with any value of CompatibilityVersion has no impact on the application.

...but then it's not clear to me what the scope of SetCompatibilityVersion is. Is it a .NET Runtime concept, is it specific only to ASP.NET Core, etc.

Then I dug further, and found Select which .NET Core version to use, thinking I'd finally find my answer, but then realized that's for development, not for deployment.

Then I dug further, and found .NET Core application deployment, but it made me wonder, have I been doing .NET Core for 3 years and not even realized what my deployment model is? I couldn't tell from the article what causes a Framework-Dependent Deployment vs. Self-Contained Deployment vs. a Framework-Dependent Executable. I just want to find the light switch, not see all the wiring going back behind the walls to my electrical panel, all the way to the power grid. I think this is why you muse correctly that these problem descriptions are vague - people want the light switch, not the "as built" blueprints for the whole house.

Then I went to the Step-by-step examples linked at the bottom of the .NET Core application deployment page, and went to Publishing .NET Core apps with the CLI, and found this quote:

Your app is configured to target a specific version of .NET Core. That targeted .NET Core runtime is required to be on any machine where your app runs.

I think this is the answer to my questions above... but I'm not really sure. It doesn't definitively say, "John, get used to a world where .NET Framework no longer exists, and you need to stay on top of every single .NET release and re-build your last tagged release on GitHub with a minor incremental change of adding a new TargetFrameworks to your build."

nguerrera commented 4 years ago

I'm searching for answers to three questions:

Take a look at https://github.com/dotnet/designs/blob/master/accepted/runtime-binding.md

The default configuration for an application on .NET Core will not allow roll forward across a major version boundary, but it is possible to opt in with a different configuration. You can specify <RollForward>Major</RollFoward> in .csproj, which is then written to .runtimeconfig.json.

The doc shows the other values for this knob and many other details. It can also be specified as an environment variable or via a command line argument.

Generally speaking there is no 100% guarantee that rolling forward across major versions will work. However, it is very likely to work, especially for typical simple command line tools.

When you use this configuration it is expected that you are staying current with releases and at least testing that your app works. I still tend to prefer this to aggressively multi-targeting to all major versions as that will slow down your build and bloat your packages. Instead of adding a new TFM to my tool/app every time there's a new major version, I'd just opt in to less conservative roll forward and test that things still work without older runtimes installed. If there aren't any issues, then I wouldn't need to publish a new package at all.

jzabroski commented 4 years ago

@nguerrera Thanks - I was searching everywhere for whether it was even possible.

When you use this configuration it is expected that you are staying current with releases and at least testing that your app works. I still tend to prefer this to aggressively multi-targeting to all major versions as that will slow down your build and bloat your packages.

To be honest, after spending the last few days thinking about what the right guidance is for open source developers, I think that:

Orthogonal Concerns:

TheMagnificent11 commented 4 years ago

I fixed this issue by downgrading the Microsoft.NET.Test.Sdk NuGet package from 16.3.0 to 16.0.1.

I'm guessing there's an issue in 16.3.0 where it looks for netcoreapp2.2 shared package only in C:\Program Files x86\dotnet\shared and not also checking C:\Program Files\dotnet\shared.

BrandonDusseau commented 4 years ago

In case other folks find their way here from Google: To add to @TheMagnificent11 's comment: I was able to get my tests working with a Microsoft.NET.Test.Sdk version as new as 16.2.0. It still cannot find .NET Core 2.2 with version 16.4.0.

Update: this is not the correct solution. Visual Studio was configured to run AnyCPU tests as x86, but only the x64 SDK was installed. I re-upgraded to Microsoft.NET.Test.Sdk 16.4.0 and set VS to use x64 for AnyCPU tests, as shown in this StackOverflow answer (note that in VS2019 by default the setting they reference is located inside Test Explorer under the gear icon).

jzabroski commented 4 years ago

@BrandonDusseau Please clear out all your bin and obj files and then try again.

BrandonDusseau commented 4 years ago

I don't want to spend a lot of space on this issue talking about it, since it's not exactly the same problem as the one originally reported, but it is relevant to the comment above mine. Unless something comes up, this will be my last comment on this issue. If you believe this information should result in a new issue being opened, let me know, although it's more of an issue with Visual Studio than with dotnet. I should add that this issue is specific to test projects.

I removed the bin and obj files from all projects as you suggested, but the problem persisted.

As of VS 16.4 it seems to default to running AnyCPU test projects as 32-bit, and so it tries to find 32-bit SDKs. Before the upgrade I had no 32-bit SDKs and the upgrade installed .NET Core 3.1.0 32-bit. I'm not sure what led VS to start trying to run tests with 32-bit SDKs, but it causes the following error:

The framework 'Microsoft.NETCore.App', version '2.2.7' was not found.
  - The following frameworks were found:
      3.1.0 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
You can resolve the problem by installing the specified framework and/or SDK.

As I mentioned in the comment above, the solution to this specific problem is to either set Test Explorer to run AnyCPU tests against the x64 architecture, or install the relevant 32-bit SDKs, or don't use AnyCPU as the platform target in the test projects. The first solution is probably the best.

dj-Query commented 4 years ago

I solved the problem with the installation of the dotnet core SDK version that was not found, specifically the 2.1. After installing dotnet core SDK 2.1 and reinstalling dotnet core SDK 3.1 (latest version at the moment) everything worked correctly.

Sorry for the bad English.

pramilgawande commented 4 years ago

dotnet tool install --global dotnet-ef

For me, this worked 15 days back. But I'm again stuck since the availability of Version 3.1.2

replaysMike commented 4 years ago

@BrandonDusseau worked for me, this was a very misleading error as it was simply the tests were configured for x86 instead of x64. This however ate up a lot of my time trying to figure out why it was complaining about missing .Net Core 2.1 in my multitarget tests.

nateous commented 4 years ago

I was trying to follow the IDS4 demo and was installing the dotnet-ef tool as well. Issue for me what that the latest version of the tool doesn't work 3.1.2 so I had to install a lower version 3.1.0 and it works now. dotnet tool install --global dotnet-ef --version 3.1.0 dotnet add package Microsoft.EntityFrameworkCore.Design

http://docs.identityserver.io/en/latest/quickstarts/5_entityframework.html

DerekFoulk commented 4 years ago

Yeah, I had to install the exact version of dotnet-ef that I have installed on my workstation in order to get things working properly. That seems wrong considering my SDK was a single patch away from the tools version I was trying to use...

My environment:

With the above environment, I began following the docs here. When I ran PM> dotnet ef migrations add InitialCreate, I was greeted with the following error:

"It was not possible to find any compatible framework version"

I was able to get around the error by downgrading all packages and tools to 3.1.1.

I expected newer versions to be backwards compatible with older versions (at least with the same major and/or minor version).

Long story short; run $ dotnet --list-sdks and take note of the latest version listed. Then, downgrade any Entity Framework stuff to that version and you'll be in business...

breakthru2 commented 4 years ago 
# Check your installed tools with $ dotnet tool list -g
$ dotnet tool uninstall dotnet-ef -g
$ dotnet tool uninstall dotnet-dev-certs -g # If you have it installed
$ dotnet tool install dotnet-dev-certs -g # If you had it installed
$ dotnet tool install dotnet-ef -g

This worked for me

Kaspary commented 4 years ago

I run dotnet add package Microsoft.EntityFrameworkCore.Design and work with dotnet 3.1.5 in Ubuntu. https://docs.microsoft.com/pt-br/ef/core/get-started/?tabs=netcore-cli

jzabroski commented 4 years ago

@Kaspary Your link is broken

Kaspary commented 4 years ago

@jzabroski, sorry, now I adjusted

Ofisayomi commented 3 years ago

Changing ${workspaceFolder}/bin/Debug/netcoreapp2.2 to ${workspaceFolder}/bin/Debug/netcoreapp3.1 in configurations=> program section in .vscode/launch.json on ubuntu with vscode fixed it for me

johncrim commented 2 years ago

For anyone coming up against similar issues to those documented above, .NET Core has a great story for forward compatibility, and it's documented.

.NET's roll-forward support allows using newer frameworks with libraries linked to older frameworks.

The workaround for build errors like:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '2.1.0' (x64) was not found.
  - The following frameworks were found:
      3.1.4 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
      3.1.6 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
      3.1.20 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
      3.1.22 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
      5.0.4 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
      5.0.9 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
      5.0.14 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
      6.0.2 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=2.1.0&arch=x64&rid=ubuntu.18.04-x64

was to update our builds to set environment variable DOTNET_ROLL_FORWARD=Major:

      - name: Build site
        run: |
          dotnet wyam build site
        env:
          DOTNET_ROLL_FORWARD: Major
jzabroski commented 2 years ago

@johncrim That does not always work, as is the case when the Microsoft DI HostBuilder pattern changed from 2.0 to 3.1. So, while it is possible in theory, it is not always proven in practice. In your case, Dave Glick I believe switched from Wyam to Statiq. He still supports both, but I believe "Statiq is the future". Wyam in particular is packaged in an strange way that nuget.org doesnt understand.

If your issue is that you are using a 2.1 global tool with a newer version of the framework, ideally you install a local tool instead that is specific to your solution and you download the SDK your solution needs.

johncrim commented 2 years ago

@jzabroski - certainly it's more reliable to use a framework version that the library was compiled against. As long as the newer versions of the framework are backward compatible with regard to the APIs being used, it will work. That's a big if, but .NET is generally quite good in the backward-compatible department.

To your point, I would prefer not to use roll forward support in my own code base in production code - certainly building against newer versions of the framework is preferable. But for build tools or similar, where runtime errors are reported in build logs and fail builds, and logical errors are hopefully caught by automated tests and/or QA, and the build tool is unlikely to be updated and re-released soon, it's a good option.

jzabroski commented 2 years ago

@johncrim Well, I hope your env variable for DOTNET_ROLL_FORWARD is inside a kubernetes pod / docker image so that no other apps see it... it will bite you one day. The alternative is to set a runtime config json so that you set the roll forward there.

But, you may just want to read the porting guide for going from Wyam to Statiq: https://www.statiq.dev/web/porting-from-wyam