FrameworkReference 'Microsoft.NETCore.App' was not recognized at (264: 5) #3868
Comments
|
How do you acquire .NET Core? The Debian 10 instructions at https://dotnet.microsoft.com/download/linux-package-manager/runtime-current? Can you post more context around the error, maybe a repro project and steps? |
dagood
added
the
needs-more-info
|
I believe @craigjbass hit the same issue and posted more details at #3879 (comment) (many thanks!), copying here because I'm 98% sure it's the same issue and we need to keep track of it:
|
|
The root issue here is that (In future 3.0 patches, this won't be an issue because we won't even build targeting packs we don't intend to release. We didn't have this protection while building 3.0.1. dotnet/core-setup#8827.)
You should never need a targeting pack from a lower patch version. We include major.minor in the package name so that you can install multiple .NET Core versions side-by-side, but only the latest patch of each one. This problem should be self-healing if your machine has access to the internet... the SDK will detect that you don't have 3.0.0 installed, download We intend to support offline scenarios so this is something that I believe needs fixing. |
dagood
added
area-setup
|
@craigjbass taking another look at this, I do think that having |
|
I mentioned to @mmitche that we needed to avoid pushing these, but there was a lot of things having to go on for that release. |
|
I would still not publish packages that aren't intended to be used, even if sdk were stricter about avoiding them. Which is what we will do moving forward, right:not publish unless they are actually needing a patch? |
Agreed completely, and yes, we merged dotnet/core-setup#8827 for 3.0.2+ so that we won't even create these packages unless there's a patch. |
|
Thank's all for helping. But something very strange happened. |
|
Same problem here... Reinstall doesn't help dotnet --info Runtime Environment: Host (useful for support): .NET Core SDKs installed: .NET Core runtimes installed: To install additional .NET Core runtimes or SDKs: |
|
Heads up, I think this is still known and expected to be broken at the moment. It would be helpful if someone could provide a repro project. I'm aware of one scenario that is broken: installing .NET Core SDK, turning off your internet, then trying to build, but that doesn't seem to be what you're hitting in this thread. |
|
I have pretty much the same setup as @mtarlac (and the same problem). I "fixed" it by downloading the version 3.0.100 binary from microsoft (https://dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-3.0.100-linux-x64-binaries) and using that instead of the version 3.0.101 the package manager provides. |
|
3.0.100 is out of date, if you want to use the tar.gz you should use 3.0.101: https://dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-3.0.101-linux-x64-binaries (--At least until the next patch, 3.0.102, comes around. That's a benefit of using the linux repo, you can use your ordinary repo commands to update unless there's an issue like the one being tracked here.) |
|
Sameish issue here on Fedora I think. The "ResolveTargetingPackAssets" task failed unexpectedly. When attempting to run any project(new or old with deleted obj/bin directories) /usr/share/dotnet/sdk/3.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(263,5): error MSB4018: The "ResolveTargetingPackAssets" task failed unexpectedly. [/home/[...].csproj] I did also accidentally dotnet run during the installation...not sure if that has anything to do with my old directory sticking around What fixed it for me:
Using the .gz that dagood referenced. I just copied over and replaced everything. Thanks much, I knew something would break when I saw the upgrading packages..dotnet and Linux don't mix well still. Cheers. |
|
@Perustaja - Same issue on Fedora. The specific issue cited is looking for a file provided by |
|
In at least one of these cases it looks like the packs/microsoft.netcore.app.ref/3.0.0 directory still exists which is why it isn’t downloading from nuget. But then the files inside it are missing. |
|
Cc @dsplaisted |
Oh... I bet it's caused by this bug in our RPM packages: https://github.com/dotnet/core-setup/issues/8235. The targeting pack directory ownership isn't correct, which means uninstalling the 3.0.0 targeting pack (to upgrade to 3.0.1) left the 3.0.0 dir around with no contents. The netcoreapp targeting/apphost packs, netstandard targeting pack, and project template RPMs have this issue. When we delete the bad We should fix the ownership issue anyway because leaving this junk around will eventually cause other problems. @leecow, can you look for and remove any bad targeting packs that are left? I see there's still one on https://packages.microsoft.com/fedora/30/prod/, If you're affected by this, you can manually downgrade to the 3.0.0 version to restore the files: Alternatively, you can simply delete the (Once we remove the remaining bad 3.0.1 targeting pack RPMs, a reinstall will also work, but it looks like they still exist on at least one feed.) |
|
|
Oops, thanks @judep90, corrected. |
|
Ubuntu 18.04 Temporary solution:
|
|
An easier workaround for Ubuntu 18.04 is to do the same as for Fedora - downgrade to the working version.
|
Don't work for me, unfortunetly.... My system: SDK for .NET Core (3.0.101) |
|
fedora 30 error MSB4018: The "ResolveTargetingPackAssets" task failed unexpectedly. |
|
@tosha-ret Can you open a new issue with more info? Full error, sequence of install commands you run to get in that state, output of @valeravorobjev Yes, this issue is tracking getting that fixed. Check #3868 (comment) for workarounds that apply to F30. |
|
I should note that I did a full purge of all dotnet* packages (`apt purge
*dotnet*`) before reinstalling the latest, and then downgrading. That was
coupled with a forcible removal of the nonempty `/usr/share/dotnet`
directory, too. That's most likely the reason it's not working for
@tosha-ret.
…On Mon, 2 Dec 2019 at 20:08, Davis Goodin ***@***.***> wrote:
@tosha-ret <https://github.com/tosha-ret> Can you open a new issue with
more info? Full error, sequence of install commands you run to get in that
state, output of dotnet --info, other things you can think of? That seems
like a different issue since the workaround didn't work, and it deserves
its own investigation.
@valeravorobjev <https://github.com/valeravorobjev> Yes, this issue is
tracking getting that fixed. Check #3868 (comment)
<#3868 (comment)> for
workarounds that apply to F30.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3868?email_source=notifications&email_token=AAR3MTDWCFRCMPM5UYFD6VTQWVMLXA5CNFSM4JPWASV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFURZRQ#issuecomment-560536774>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR3MTELJRAKL2YHCESIG5TQWVMLXANCNFSM4JPWASVQ>
.
|
|
Thanks, that looks like it'll work great! I do see now that you're hitting the error for The error itself comes from: I believe that normally there should be some <ResolveTargetingPackAssets FrameworkReferences="@(FrameworkReference)"
ResolvedTargetingPacks="@(ResolvedTargetingPack)"
RuntimeFrameworks="@(RuntimeFramework)"
GenerateErrorForMissingTargetingPacks="$(GenerateErrorForMissingTargetingPacks)">It looks like ProcessFrameworkReferences isn't able to match up the targeting packs you need... I'm not familiar enough with what it expects to know exactly what's going on though. (Click me for the task call details, note the task has no outputs.)@nguerrera @dsplaisted, can you take a look? What bad/stale state in the project assets file or missing files on disk do you think would cause this to happen? |
|
I arrived at this issue while searching for a resolution to the problem, since I had been receiving the same error upon re-opening a recent project. On a whim, noting that I had .NET Core SDK 3.1.100 installed, I tried changing the TargetFramework to <PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<LangVersion>latestmajor</LangVersion> |
|
I'm also affected by this issue, upgraded from 3.0.0 to 3.1.0 LTS and now it won't compile in Rider. Reverted back to 3.0.0 and it works. |
|
@benelliott It looks like in your case you have a project targeting .NET Standard 2.0 that has a FrameworkReference to Microsoft.AspNetCore.App. That's not supported. You need to be targeting .NET Core 3.0 or higher for that FrameworkReference to work. |
|
I am facing similar issue. however strange thing is the same setup works on one project and fails on another project. This is really confusing. dotnet build on a project throws below error. Strange thing is : we have another project which we also run on the same base dotnet image with above configuration and that project run successfully with out any error. I am not sure why? I saw few solution where it mentioned to downgrade the version of dotnet SDK. But why for few projects we are facing these error? not all if it is a known issue. any help would be appreciated. |
Thanks, this worked for me.
|
|
@mlapaglia In my case only 3.0.101 directory exist in |
|
It is normal to look for 3.0.0. The ref packs should only increment when there is a genuine bug fix in them. There was a problem where 3.0.1 ref packs were built unnecessarily and pushed to linux package feeds where they get installed, then not used. It gets even worse if the 3.0.0 dir is left behind on an upgrade because that blocks pulling 3.0.0 from nuget. @dagood Where are we on fixing all the feeds? I would expect we're at the point where reinstalling would fix things. If so, can we provide instructions to get onto a setup with the 3.0.0 pack. I vaguely recall from an issue I had this might require cleaning apt cache, not sure about other linuxes. I am seeing a lot of folks working around the incorrect state still. It would be good to get closure. |
|
Workarounds for the bad 3.0.1 package are already in the thread:
As for removing the bad targeting packs, I'm still waiting for an update from @leecow. It is still present on https://packages.microsoft.com/fedora/30/prod/, at least, but maybe more. (I don't currently have a tool that scrapes the site but it's looking more and more useful for me to set one up. 😕) Fixing the RPM-specific issue where uninstalling the targeting pack RPM doesn't remove the 3.0.0 directory is tracked by https://github.com/dotnet/core-setup/issues/8235 as a servicing fix. Note that this thread also tracks a more complex issue, and I believe this is what people are running into when they see this message on Debian-package-using distros: after uninstalling a targeting pack, it seems some scenarios still assume the files will be present, and fail to build. This apparently happens on Windows too, when VS upgrades from 3.0.0 targeting pack to 3.1.0 targeting pack. @dsplaisted looked into a binlog we got from a repro, it was apparently a nonsupported scenario: #3868 (comment). From what I see, it sounds like it might be work by coincidence when the targeting packs are installed, but doesn't work with the NuGet fallback path, or something along those lines. |
|
Thank you @dagood and @nguerrera for your prompt reply and help. Actually, I finally found issue in one of my project. As I mentioned in my earlier comment here that it is strange that with same dotnet version it works with one project but throwing error on another project. Turned out : I was running this applications on docker container and for the application which was throwing error contained |
|
So I got the same issue after a Visual Studio upgrade, can't build anything anymore from the commandline. Can I just remove: Microsoft .Net Core SDK 3.1.100 (x64) from Visual Studio ( why can't I select the text? ) and it will work again? I can't seem to uninstall it from the "Programs and Features" list..... I have to use the VS installer. |
|
I have builds failing since today in VS Code, the only update I have done today is the VS update that installs .Net 3.1. it seems that it impact is machine wide. After doing a dotnet build it seems to also do dotnet msbuilds again..... weird. `Microsoft Windows [Version 10.0.18362.476] C:\Dev\repos\solution>dotnet msbuild C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(283,5): error NETSDK1073: The FrameworkReference 'Microsoft.NETCore.App' was not recognized [C:\Dev\repos\solution\solution.fsproj] C:\Dev\repos\solution>dotnet build Restore completed in 5,47 sec for C:\Dev\repos\solution\solution.fsproj. Build succeeded. Time Elapsed 00:00:10.98 solution -> C:\Dev\repos\solution\bin\Debug\netcoreapp3.0\solution.dll |
|
Ok, I think I see. The dotnet build would do an implicit dotnet restore, whereas dotnet msbuild would not. Once the restore is done, the dotnet msbuild starts to work. Am I right in guessing that the project targets netcoreapp3.0 and not netcoreap3.1? There's an issue with VS 16.3 -> 16.4 upgrades where the 3.0 runtime and targeting pack are uninstalled. The issue will be fixed in future runtime version upgrades. In the meantime, you can get 3.0 runtime and targeting back by running Visual Studio installer and selecting .NET Core 3.0 runtime under Individual Components. When a targeting pack is not installed, it can be restored from nuget, but for that to work restore has to run. I imagine there are scenarios where IDEs aren't initiating a new restore when the targeting pack is removed. Simply putting it back as above is probably the best bet. Forcing a restore somehow would also work. (I still think this would have been better on a different issue as it's getting really hard to separate the different threads in this conversation. :() |
|
Yes, it targets 3.0 and not 3.1. Well it seems to be the same core issue, doing an upgrade of .Net SDK, even through VS, seems to impact some other parts. |
|
The root causes of the two issues are unrelated: there's an obvious bug with our RPM package causing problems with upgrade, and some maybe-bug probably due to a bad assumption in VS/Rider/ |
|
|
@mbrautgithub ASP.NET 2.x supported both .NET Core and .NET Framework, and thus supported .NET Standard so you could have one DLL that would work on both. ASP.NET 3.x dropped support for .NET Framework. Given that, why do you need to stay with .NET Standard 2.1? You may be trying to do something that is no longer supported. |
|
I ran into this issue using Rider on Windows. It was caused because my Rider wasn't up to date (was on |
|
Similar problem on Fedora 30: .NET core seems to be very unreliable under Linux. Don't want spend time fixing SDK bugs everytime I use it. Mebus |
|
[macOS Catalina] - resolved for me. This error was reported to me. I don't wanted downgrade then I tried update all. First I update my dotnet core to current LTS version (3.1.101) and saw the problem persisted. After I update my Visual Studio 2019 for Mac (Community) to current version 8.4.5 (build 19) and all problems resolved. |
|
Had faced the same issue after an auto update of dot net core sdk (3.1) to latest version, the issues is the new changes ins sdk is not compatible to monodevelop (7.6) version installed in my system Switched to visual studio code solved the problem |
|
Right now, I get this with the latest updates and sdks: My project is a .net core 3.1 console application that references a Xamarin Forms project. OS: VS details: |
|
I'm also getting "Error NETSDK1073: The FrameworkReference 'Microsoft.WindowsDesktop.App.WPF' was not recognized (NETSDK1073)" The same project works fine in my windows Visual Studio, but fails in MAC. ` |
|
@PokeArsenalist Building projects that depend on WPF (or Windows Forms) is currently only supported on Windows. So that would be why you see that error only on a Mac. |
|
@dsplaisted Mine is Xamarin.Forms app. It builds and deploys successfully in devices as well. But the issue I am facing is with the .Net Core app 3.1 unit test project. |
@PokeArsenalist Can you create a separate issue? |
|
@dsplaisted Opened #5070 to discuss regarding this issue. |
and others
Hi guys.
I am using Debian 10.1, and today I upgraded net core, version 3.0 to 3.0.1 and my application crashed.
Error: "FrameworkReference 'Microsoft.NETCore.App' was not recognized at (264: 5)"
dotnet version :
3.0.101
mono version
Mono JIT compiler version 6.4.0.198 (tarball Tue Sep 24 01:24:35 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: yes(610)
Suspend: hybrid
GC: sgen (concurrent by default)
The text was updated successfully, but these errors were encountered: