Sdk: The specified framework 'Microsoft.NETCore.App', version '2.0' was not found

[redowl3]

Not sure if this is a cli issue or VS so happy to move to another area if not correct

Steps to reproduce

Update to Visual Studio Professional Preview (v 15.5.0 Preview 2)

Try to add data migration (using IDesignTimeDbContextFactory)

dotnet ef migrations add [MigrationName]

Expected behavior

Migration created

Actual behavior

Error message

The specified framework version '2.0' could not be parsed
The specified framework 'Microsoft.NETCore.App', version '2.0' was not found.

• Check application dependencies and target a framework version installed at:
  \
• Alternatively, install the framework version '2.0'.

Environment data

Product Information:
Version: 2.1.1-preview-007094
Commit SHA-1 hash: f657648f07

Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Filesdotnet\sdk2.1.1-preview-007094\

Microsoft .NET Core Shared Framework Host

Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

[livarcocc]

Can you share your project or a repro of this issue?

[redowl3]

Hi,

Thanks for getting back to me.

The project is pretty big so not practical to share, but since updating to 15.5.0 Preview 2.0, as well as not being able to create migrations due to what looks like core versioning issues, I can no longer publish anything to Azure as the build fails although it builds fine in VS?

Whatever was changed with 15.5.0 Preview 2.0 looks to be creating a few issues.

As the issue appears to be with a project built with the previous version of the Preview, then updating to 15.5.0 Preview 2.0 I'm now unable to repro.

[livarcocc]

You can add a global.json pinning your SDK version to version 2.0.2 (the last release we did with VS 15.4) or 2.0.0.

Just add the global.json file to the root of your repo with contents like this:

{
  "sdk": {
    "version": "2.0.2"
  }
}

This should unblock you. But notice that your SDK will be pinned to whatever version you put there. Let us know if this unblocks you.

It would also be super helpful if you could at least find a minimal repro for this problem. Is this happening on multiple machines?
Can you tell us what are the folders you have under C:\Program Files\dotnet\shared\microsoft.netcore.app? This will tell us which runtimes you have in the box.

[redowl3]

Thanks for the suggestion, I'll try that. I've only tried this on a single machine.

Folder structure below.

[livarcocc]

Could you share the contents of runtimeconfig.json file for your tool? And are you packaging it in your tool nupkg?

[netbidev]

Hello everyone. I have this problem too.

[livarcocc]

@netbidev any chance you have a small repro for us?

[netbidev]

@livarcocc here
TestDB.DBModel.zip

The command here
dotnet ef dbcontext scaffold "Server=.;Database=TestDB;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer

[dls314]

@netbidev That project replicates the error for me as well

[dls314]

@livarcocc The workaround of adding a global.json file specifying 2.0.2 works for me.

Does anyone know if/how the --fx-version argument could be used instead? global.json is tacky.

[livarcocc]

the --fx-version argument is a host argument that can be used to indicate which runtime framework to use when running an application.

Like this: dotnet --fx-version 2.0.0 <app.dll>.

[dls314]

I guess that the dotnet ef command can't be used with host arguments? I've tried putting --fx-version in various places in a command like dotnet ef migrations list without success.

[jeremymeng]

Hit this issue in an xunit test project too. Repro:

1. dotnet new xunit
2. Upgrade to latest xunit 2.3.1, and add dotnet-xunit tool

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.5.0-preview-20170810-02" />
    <PackageReference Include="xunit" Version="2.3.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.3.1" />
    <DotNetCliToolReference Include="dotnet-xunit" Version="2.3.1" />
  </ItemGroup>

1. dotnet build
2. dotnet xunit

Actual:

Detecting target frameworks in test2.csproj...
Building for framework netcoreapp2.0...
  test2 -> e:\temp\test2\bin\Debug\netcoreapp2.0\test2.dll
Running .NET Core 2.0 tests for framework netcoreapp2.0...
The specified framework version '2.0' could not be parsed
The specified framework 'Microsoft.NETCore.App', version '2.0' was not found.
  - Check application dependencies and target a framework version installed at:
      \
  - Alternatively, install the framework version '2.0'.

Notes:
dotnet test works.
dotnet xunit --fx-version 2.0.0 works too.

[Kurtbaby]

I am having the same issue after upgrading to v15.4.4. The only solution I've found so far to fix the CLI tools issue it to add the RuntimeFrameworkVersion inside the property group as such:

<PropertyGroup>
   <TargetFramework>netcoreapp2.0</TargetFramework>
   <RuntimeFrameworkVersion>2.0.3</RuntimeFrameworkVersion>
</PropertyGroup>

[livarcocc]

I can't repro this using SDK 2.1.1-preview-007139 on a Mac or 2.1.1-preview-007165 on Windows. For those that are reproing this, is it always reproing on Windows? If so, can you make sure that you don't have two different dotnet versions installed, one x86 and one x64? And that the one being used by the tool is not being the wrong one? I mean, make sure that the right dotnet installation is coming before the other one in the path environment variable.

[jeremymeng]

I found that I had some preview versions of dotnet sdk installed, including 2.0.3. The latest on dot.net seems 2.0.2. After uninstalling those and only keeping 2.0.0, 2.0.2, and 2.1.1-preview-007118, the issue no longer reproduces for me

[haidelber]

I'm having the same issue ever since I upgraded to Visual Studio 15.4.4 which obviously included the sdk 2.0.3

[jorgeyanesdiez]

Same issue here as @jeremymeng
I have cleaned up my system, and only have the 2.0.3 SDK, runtime (x64 and x86) and windows server hosting packs, therefore, @livarcocc 's solution doesn't work for me, but @Kurtbaby 's does.

[Kurtbaby]

Microsoft recognized some of the errors of their ways and released new versions of the runtime and server hosting for 2.0.3 since my last post, and this has solved our deployment issue (not discussed this thread), but sadly, we still have to use the RunTImeFrameworkVersion tag in the project in order to use dotnet ef ... commands. We are also using a "Data project" and have isolated the context, etc. into this class lib, which uses a DesignTimeFactory for the context. I have not yet tested this behavior against a standard, template-generated web project, but will do so and report the results back here.

[Kurtbaby]

Here's an update. If we leave the context and models in the same aspnet web core project generated by the template, we are able to run the CLI tools without the error. As soon as we extract the context and models into their own class lib, we are forced to use the RunTimeFrameworkVersion tag in order to use the CLI tools. Not sure why as this class lib code/technique was working fine until we upgraded to v15.4.4.

[livarcocc]

@Kurtbaby any chance you can provide a repro project? On github or a zip? I would love to debug this issue.

[livarcocc]

We have gotten a repro for this issue and understand it now. We are working on a fix for it. The best work around available to it right now is setting RuntimeFrameworkVersion in your library project targeting netcoreapp2.0. I will explain why this happens in a next comment when I get a chance.

[livarcocc]

So, the issue here is that the SDK was setting the implicit version of the Microsoft.NETCore.App to 2.0 instead of 2.0.0. NuGet was then restoring using that and finding the closest available package. We then used that version to write the rutimeconfig.json file.

In the cases where this repros, the libraries target netcoreapp2.0, but because they are libraries, no runtimeconfig.json is generated and EF ends up evaluating the RuntimeFrameworkVersion from the project and sees it as 2.0, which the host then does not understand, which leads to the failure here.

This works for apps because in that case we do generate a runtimeconfig.json and use that to run EF.

The real fix here is really just changing the implicit version from 2.0 to 2.0.0.

[jorgeyanesdiez]

@livarcocc can that be done without waiting for fixed packages? eg: using global.json?

[nathannis]

I have this issue as well after upgrading to VS 15.4.4
dotnet --version is printing as 2.0.3

The property group fix by @Kurtbaby fixes it for me as well.

<PropertyGroup>
   <TargetFramework>netcoreapp2.0</TargetFramework>
   <RuntimeFrameworkVersion>2.0.3</RuntimeFrameworkVersion>
</PropertyGroup>

I am adding it before running dotnet ef migrations add ... and then removing it before committing to source control since this seems like a bug that will be fixed soon.
Thanks!

[bricelam]

Workaround (EF Tools)

Adding the following to the project should also make it work.

<PropertyGroup>
  <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
</PropertyGroup>

[bgrainger]

<GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles> didn't fix the problem for me with xunit (e.g., as in this comment).

The <RuntimeFrameworkVersion> and --fx-version workarounds did; this isn't ideal because (I would assume) it now requires all contributors and CI environments to have exactly that SDK version installled.

[bricelam]

Sorry, can't speak for xUnit.net... Updated.

[livarcocc]

@bgrainger I would suggest filling an issue under xunit itself for this. They may have to do the same fix there that we are doing in EF. The fix that we can make on the SDK side won't really fix the problem for tools if they are using the --fx-version option of the host to specify a runtime.

[philippgille]

@livarcocc: I have a similar issue (same error message as the issue title), but not related to EF, xUnit or VS 15, so I thought I'd share my specific issue as well.

I have a simple netcoreapp2.0 console app. I build a Docker image for that app using a multi-stage build with the base images microsoft/dotnet:2.0-sdk-jessie for building and microsoft/dotnet:2.0-runtime for running the app, which works fine. Now I read @shanselman's article Trying out new .NET Core Alpine Docker Images and wanted to run my app in an Alpine image. According to Scott's article you just need to change the base image for running the app to microsoft/dotnet-nightly:2.1-runtime-alpine. But that doesn't work for me. The building works fine, but when running the Docker container I get the error message The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found..

Scott didn't include the source code of the csproj file he used, but I assumed newer .NET Core versions would be backward compatible with older ones, so the .NET Core 2.1 runtime should run .NET Core 2.0 apps just fine.

What do I need to include in my csproj file to make the app work with .NET Core 2.0 and .NET Core 2.1 (Alpine or not)?

It currently looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp2.0;net461;net451</TargetFrameworks>
    <RuntimeIdentifiers>win-x64;linux-x64;linux-arm;osx-x64</RuntimeIdentifiers>
  </PropertyGroup>
</Project>

Using ENTRYPOINT ["dotnet", "--fx-version", "2.0.0", "hello-netcoreapp.dll"] in the Docker image doesn't help.

I also tried using microsoft/dotnet-nightly:2.1-runtime instead of the Alpine version, but it didn't work as well, so it doesn't seem to be an issue with the Alpine image.

[livarcocc]

Your assumption about 2.1 running on the 2.0 runtime is not correct and the root of the problem you are facing right now.

Alpine is only available in the 2.1 runtime and if you want your app to run there, you need to target netcoreapp2.1 and use a nightly from the CLI from our master branch.

[philippgille]

Your assumption about 2.1 running on the 2.0 runtime

I mean the other way around - 2.0 app running on 2.1 runtime. But you mean that doesn't work as well? So my target needs to be 2.1, thus the Docker SDK image needs to be 2.1? Sounds different in Scott Hanselman's blog article, but maybe he left out the details?

His Dockerfile, notice the builder image using 2.0-sdk:

FROM microsoft/dotnet:2.0-sdk as builder  

RUN mkdir -p /root/src/app/dockertest
WORKDIR /root/src/app/dockertest

COPY dockertest.csproj . 
RUN dotnet restore ./dockertest.csproj 

COPY . .
RUN dotnet publish -c release -o published 

FROM microsoft/dotnet:2.0.0-runtime

WORKDIR /root/  
COPY --from=builder /root/src/app/dockertest/published .
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000/tcp
CMD ["dotnet", "./dockertest.dll"]

Then:

Now I'll just change one line, and use the 2.1 alpine runtime

And:

FROM microsoft/dotnet-nightly:2.1-runtime-alpine

[livarcocc]

@philippgille the host, currently, won't you roll you forward across the minor version number. It only rolls you forward on patch versions. Meaning, if you target 2.0.0, it will roll you forward to 2.0.1, 2.0.2, etc. But not to 2.1.0.

The runtime team is considering enabling minor version rollforward for 2.1, but if they do, it will be in the next release.

[philippgille]

@livarcocc: Ah ok, thank you very much for the explanation!

The runtime team is considering enabling minor version rollforward for 2.1

Is there a GitHub issue or UserVoice page where I can vote for that feature?

[livarcocc]

cc @Petermarcu to comment on where the 2.1 rollfoward work is being tracked.

[Petermarcu]

https://github.com/dotnet/core-setup/issues/3462

[Petermarcu]

No need to upvote. It's happening :)

[stakx]

@livarcocc - you wrote:

EF ends up evaluating the RuntimeFrameworkVersion from the project and sees it as 2.0, which the host then does not understand, which leads to the failure here.

What I don't quite understand is, isn't it a bit ridiculous in the first place for the host to not understand that version number? Why isn't it changed to be a bit more lenient, and interpret 2.0 e. g. as "the latest installed 2.0.* version"?

[nathanchere]

@livarcocc I know a lot has happened since your question but this is also happening for me on Linux (Arch, x64, kernel 4.13, .Net Core 2.0.2). Also only with xUnit though. When I use dotnet test it builds and runs fine, but dotnet xunit gives the error reported many times above already.

Will follow it up w/ xunit though.

[cgountanis]

Agree with Stakx, it's just another thing we have to worry about after doing an update via NUGET or whatever.

[bigo92]

<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.3" /> => errror 502 in server deploy
relapce
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" /> => deploy run done !
or you install sdk new version in server in server hostting or await azue update sdk dotnet core new version suport 2.0.3

[DjSloth]

So what is the fix?
All I need is dotnet ef migration add XXXXXX , dotnet ef database update

[cgountanis]

It was previously posted, for now you can just add to your csproj file, later it seems it will be fixed and look up automatically for minor versions.

For example, I am on Core 2.0.3, so I added the RuntimeFrameworkVersion 2.0.3 to the property group as temp fix. Worked on all my projects within my solution.

<PropertyGroup>
   <TargetFramework>netcoreapp2.0</TargetFramework>
   <RuntimeFrameworkVersion>2.0.3</RuntimeFrameworkVersion>
</PropertyGroup>

[DjSloth]

Yes, that seems to fix the ef migration part.thanks for that.the only problem is now the depending projects (API for example) do compile , but do not run on local Host even.any suggestions?

[68681395]

There is the same problem with my project, the workaround to resolve it successfully is that remove the item 'C:\Program Files (x86)dotnet' from the Path of Environment Variable because I found I did not install the right netcore version under X86. I have not tried to install the proper version with x86, appreciate that you tell me if you have done that test.

[cgountanis]

I uninstalled everything but 2.0.3 then did the Target in the csproj file. Worked for me.

[stakx]

I am a little worried about adding something like <RuntimeFrameworkVersion>2.0.3</RuntimeFrameworkVersion> to a project file. Even though that seems to resolve the issue now, doesn't it also imply that I will now have to explicitly manage the runtime host version when previously I didn't have to? Historically, I've almost never had any reason to look into project files, and it's really easy to forget about having to manually upgrade settings in there. Is there no other way?

[VictorioBerra]

When will we see this fix out in the wild so dotnet xunit works again?

If anyone got here from doing dotnet new xunit you can run this without modifying any files:

dotnet xunit -fxversion 2.0.3

[ivanruski]

I found out that the dotnet cli commands can't run from ClassLibraries it needs .exe in order to execute the command. So I fixed my problem by adding new ConsoleApp (.NET Core) then I've added my ClassLibraries as references to the ConsoleApp. Then run the command dotnet ef --startup-project ../ConsoleApp migrations add init but failed with that Microsoft.EntityFrameworkCore.Design is required in order to execute the command I did it. And it worked

[cgountanis]

The latest versions of core seem to fix this problem you do not need to specify the runtime anymore as well.

[ivanruski]

I have decided to post it because I am with .NET Core 2.1.4 and the latest update of VS2017 enterprise and had the problem to add migration

[ronram5126]

Had similar issue with added
<RuntimeFrameworkVersion>2.0.5</RuntimeFrameworkVersion>
like
<PropertyGroup> <TargetFramework>netcoreapp2.0</TargetFramework> <RuntimeFrameworkVersion>2.0.5</RuntimeFrameworkVersion> <IsPackable>false</IsPackable> </PropertyGroup>

Concept: _keep the RuntimeFramework compatible with xunit framework (both should be latest)._

Worked for me but couldn't vouch.

[tsauvajon]

I only have the 2.0.0 and 2.0.5 Microsoft.NetCore.App installed. Though, when I run dotnet --version, I get 2.0.2.

I guess it doesn't reference the version of the same component, but what is the relation between dotnet --version and the runtime version ?

[livarcocc]

dotnet --version gives you the SDK version that is being resolved.

[DouglasMarsh]

The issue is closed but the bug seems to still exist.

I'm experiencing this issue with latest Visual Studio 2017 (15.5.6)
adding RuntimeFrameworkVersion to csproj does not fix the issue of dotnet test not discovering tests
colleagues that are using VS version 15.5.1 are not experiencing this issue.

note: dotnet xunit will discover and run tests after RuntimeFrameworkVersion is added

A sample project that repos this issue with just an xUnit and UnitTest project is attached.
vs2017_15.5.6_UnitTestIssues.zip

---

.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.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Filesdotnet\sdk2.1.4\

Microsoft .NET Core Shared Framework Host

Version : 2.0.5
Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54

[Sotam]

Currently have 2.1.0-preview2-26131-06 installed, but VS2017 doesn't detect the framework. Do I need to install something else? Currently I can only select up to dotnet core 2.0.

[livarcocc]

@mlorbetske for the template question.

[mlorbetske]

@phenning I’m case he has any thoughts here.

@sotam if you run “dotnet new console” at the command line, does a 2.1 project get created?

[Sotam]

@mlorbetske First I must apologize, replied to the wrong issue. But nonetheless, you made my day! I was able to create a new project using the console and then build it in VS2017 :)

[DiginessForever]

I'm having this problem as well. "dotnet --version" is 2.1.4. I am using Visual Studio Enterprise 2017.

[Sotam]

@DiginessForever which version do you have? (dotnet --info)

[DiginessForever]

2.1.4 (updated my comment above).

[Sotam]

@DiginessForever I'm running a preview build .NET Command Line Tools (2.1.300-preview1-008019) . If I remember correctly, gotten from here

[DiginessForever]

One of my issues is that I have my data layer in a separate project (all the layers, App, Domain, Repository, and Data are in separate projects). The data layer is a class library.

[redowl3]

Have you tried adding a global.json file to you data project?
{
"sdk": {
"version": "2.1.4"
}
}

[tiwilson7]

We had this same problem for developers who only had the "Microsoft .NET Core SDK - 2.1.x" installed but did not have a 2.0.x version of the SDK installed.

The solution (work-around, really) was to go the the archive downloads and install the latest 2.0.x SDK version (which can live side by side with 2.1.x).

.NET Core 2.0.3 SDK

[rfuhrer]

@tiwilson7 Thanks for that. I just built a new machine (only has the latest SDK installed) and got everything up and running except xunit CLR. It doesn't work even with dotnet xunit -fxversion 2.1.4. After installing the 2.0.3 SDK and running dotnet xunit -fxversion 2.0.3 it was working again.

[jlanng]

@rfuhrer did you find a solution? same problem here

[rfuhrer]

@jlanng install the old 2.0.3 SDK and then force it to run that sdk using the command dotnet xunit -fxversion 2.0.3. It's just your unit tests running that version so it's not like you're forcing your production copies to use an old version of dotnet core or anything.

I actually ended up not really using dotnet xunit since it didn't seem to play as nice with the dotnet CLI plugin for TeamCity (couldn't figure out how to make it know that it could run dotnet xunit and expect the results coming out to be digested the same way as dotnet test). Shaving a few seconds off my build time wasn't worth the hours i was going to spend trying to figure that out

[cgountanis]

The global.json with 2.1.4 does not help when using dotnet ef commands in a classlib. You still have to manually add the RuntimeFrameworkVersion to the CSPROJ file on all projects in the solution. If you only add to one NUGET wants to consolidate because some projects are using 2.0.0 and only the ones specified with RuntimeFrameworkVersion use 2.0.5. I only have SDK 2.1.4 installed why does it just not use Runtime 2.0.5 by default?

<RuntimeFrameworkVersion>2.0.5</RuntimeFrameworkVersion>

[jg11jg]

Note that it is the Microsoft .NET Core Shared Framework Host framework version not the .NET Command Line Tools version that you need to use in the -fx argument (2.0.5 in the below, NOT 2.1.4)

`PS G:\MyFirstUnitTests> dotnet xunit
Detecting target frameworks in MyFirstUnitTests.csproj...
Building for framework netcoreapp2.0...
MyFirstUnitTests -> G:\MyFirstUnitTests\bin\Debugnetcoreapp2.0\MyFirstUnitTests.dll
Running .NET Core 2.0 tests for framework netcoreapp2.0...
The specified framework version '2.0' could not be parsed
The specified framework 'Microsoft.NETCore.App', version '2.0' was not found.

• Check application dependencies and target a framework version installed at:
  \
• Alternatively, install the framework version '2.0'.
  PS G:\MyFirstUnitTests> dotnet --version
  2.1.4
  PS G:\MyFirstUnitTests> dotnet xunit -fxversion 2.1.4
  Detecting target frameworks in MyFirstUnitTests.csproj...
  Building for framework netcoreapp2.0...
  MyFirstUnitTests -> G:\MyFirstUnitTests\bin\Debugnetcoreapp2.0\MyFirstUnitTests.dll
  Running .NET Core 2.1.4 tests for framework netcoreapp2.0...
  It was not possible to find any compatible framework version
  The specified framework 'Microsoft.NETCore.App', version '2.1.4' was not found.
• Check application dependencies and target a framework version installed at:
  \
• Alternatively, install the framework version '2.1.4'.
  PS G:\MyFirstUnitTests> 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 Filesdotnet\sdk2.1.4\

Microsoft .NET Core Shared Framework Host

Version : 2.0.5
Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54

PS G:\MyFirstUnitTests> dotnet xunit -fxversion 2.0.5
Detecting target frameworks in MyFirstUnitTests.csproj...
Building for framework netcoreapp2.0...
MyFirstUnitTests -> G:\MyFirstUnitTests\bin\Debugnetcoreapp2.0\MyFirstUnitTests.dll
Running .NET Core 2.0.5 tests for framework netcoreapp2.0...
xUnit.net Console Runner (64-bit .NET Core 4.6.26020.03)
Discovering: MyFirstUnitTests
Discovered: MyFirstUnitTests
=== TEST EXECUTION SUMMARY ===
MyFirstUnitTests.dll Total: 0
PS G:\MyFirstUnitTests>`

[andreacassioli]

Any clear solution to this issue? I am running on OSX using dotnet from the CLI:

13:20 $ dotnet --version 2.1.4

`
13:20 $ dotnet xunit
Detecting target frameworks in PreplanningApiTests.csproj...
Building for framework netcoreapp2.0...
PreplanningApiTests -> /Users/aca286/workspace/deacon/preplanning-api/PreplanningApiTests/bin/Debug/netcoreapp2.0/PreplanningApiTests.dll
Running .NET Core 2.0 tests for framework netcoreapp2.0...
The specified framework version '2.0' could not be parsed
The specified framework 'Microsoft.NETCore.App', version '2.0' was not found.

• Check application dependencies and target a framework version installed at:
  /
• Alternatively, install the framework version '2.0'.

`

I have tried some of the proposed workaround but no way.

[replaysMike]

I too have this issue. I think it was caused either when uninstalling preview-2 and installing preview-3. I no longer have a 2.1.0-preview2-final directory in C:\Program Filesdotnet only 2.1.0-preview1-26216-03 and launch using IIS Express anymore because of this issue.

[DiginessForever]

All,

I've figured something out regarding transactions on the latest preview
nuget package (preview2).

I could not get the TransactionScope working, but have successfully gotten
CommittableTransaction working.
Here's a doc link:
https://docs.microsoft.com/en-us/ef/core/saving/transactions (look near
the bottom for the code sample I used to get going)

They are still working on TransactionScope apparently (System.Transactions
is not fully supported the best I can tell in the sqlclient package yet).

Regards,

Jacob

On Sat, Apr 14, 2018 at 5:48 PM, Michael Brown [e-mail]
wrote:

I too have this issue. I think it was caused either when uninstalling
preview-2 and installing preview-3. I no longer have a
2.1.0-preview2-final directory in C:\Program Filesdotnet only
2.1.0-preview1-26216-03 and launch using IIS Express anymore because of
this issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/7901#issuecomment-381368788, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOIMLAt42A7lc_k4Nf1TwLQVM75bNp2Fks5toorIgaJpZM4QFwFD
.

[DiginessForever]

Hey guys,

You might try this:
Try changing the targeted framework to .net standard manually in the
project file.
https://docs.microsoft.com/en-us/dotnet/standard/frameworks

I don't know if that will work, but in our projects we have some .NET 4.7
projects and some .NET Core 2.0 ones. T

The only way to have a .NET 4.7 dependency is to change the .NET Core 2.0
project files manually to target .NET Standard.

Regards.

On Tue, May 29, 2018 at 5:14 AM, Radenko Pavlovic [e-mail]
wrote:

Error

It was not possible to find any compatible framework version

The specified framework 'Microsoft.NETCore.App', version '1.0.0' was not
found.

• Check application dependencies and target a framework version installed at:

  \

• Alternatively, install the framework version '1.0.0'.

Dotnet tools

.NET Command Line Tools (2.0.3)

Product Information:
Version: 2.0.3
Commit SHA-1 hash: 12f0c7e
https://github.com/dotnet/cli/commit/12f0c7efcc875248882fabf6258cd962b430b1f3

Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Filesdotnet\sdk2.0.3\

Microsoft .NET Core Shared Framework Host

Version : 2.0.7
Build : 2d61d0b043915bc948ebf98836fefe9ba942be11
Problem

Hey guys, I have similiar problem, I can not publish my .net core
application because dotnet bundle fails.
I have followed advices from this issue and I downgraded my SDK to 2.0.3
as it was pointed out.
I added 2.0.3 to my
project files too.
But still I am not able to publish as the error keeps occurring.
Some help would be great.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/7901#issuecomment-392725918, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOIMLBFOnyQOVRJxdGOjk-Z9VhkxfVaUks5t3R-FgaJpZM4QFwFD
.

[mistrykam]

First determine which _run time version_ you are using: dotnet --info

Then edit each .csproj and add the tag:

You will have to close and open Visual Studio.

[TheAifam5]

Wow guys,
I have the newest version of dotnet and I still have this issue..... 👏
Just fresh projects and added Api as a reference to Tests. 👏 👏

dotnet --info:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.302
 Commit:    9048955601

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

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

.NET Core SDKs installed:
  2.1.302 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

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

dotnet xunit:

Detecting target frameworks in X.Tests.csproj...
Building for framework netcoreapp2.1...
  X.Api -> D:\Projects\Private Repositories\X.Api\bin\Debug\netcoreapp2.1\X.Api.dll
  X.Api.Tests -> D:\Projects\Private Repositories\X.Api.Tests\bin\Debug\netcoreapp2.1\X.Api.Tests.dll
Running .NET Core 2.1.0 tests for framework netcoreapp2.1...
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
  - Check application dependencies and target a framework version installed at:
      C:\Program Files\dotnet\
  - Installing .NET Core prerequisites might help resolve this problem:
      http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download
  - The following versions are installed:
      2.1.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[bloritsch]

NOTE: the XUnit libraries have another dependency runtime dependency that is not called out specifically: System.Text.Encoding.CodePages

I had to add that to my test project and use dotnet xunit -fxversion 2.1.2 to get Xunit to work.

[yatli]

dotnet xunit is now deprecated:

https://github.com/xunit/xunit/issues/1767