Open rodrigodevelms opened 5 years ago
dagood
commented
5 years ago 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
commented
5 years ago I believe @craigjbass hit the same issue and posted more details at https://github.com/dotnet/core/issues/3879#issuecomment-557151044 (many thanks!), copying here because I'm 98% sure it's the same issue and we need to keep track of it:
A few things here @dagood -
1) I removed dotnet packages entirely to be able to perform a system upgrade. 2) Went to reinstall dotnet 3.0.0 - so I followed the advice here: https://github.com/dotnet/core/issues/3853#issuecomment-556101411
I think there is something not quite right with the published dependency graph from the
dotnet-sdk-3.0package:> $ sudo dnf install dotnet-sdk-3.0 ⬡ 10.7.0 Last metadata expiration check: 0:09:35 ago on Thu 21 Nov 2019 15:38:13 GMT. Dependencies resolved. ============================================================================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================================================================== Installing: dotnet-sdk-3.0 x86_64 3.0.101-1 packages-microsoft-com-prod 64 M Installing dependencies: aspnetcore-runtime-3.0 x86_64 3.0.1-1 packages-microsoft-com-prod 7.5 M aspnetcore-targeting-pack-3.0 x86_64 3.0.1-1 packages-microsoft-com-prod 1.4 M dotnet-apphost-pack-3.0 x86_64 3.0.1-1 packages-microsoft-com-prod 66 k dotnet-host x86_64 3.0.1-1 packages-microsoft-com-prod 39 k dotnet-hostfxr-3.0 x86_64 3.0.1-1 packages-microsoft-com-prod 147 k dotnet-runtime-3.0 x86_64 3.0.1-1 packages-microsoft-com-prod 29 M dotnet-runtime-deps-3.0 x86_64 3.0.1-1 packages-microsoft-com-prod 2.8 k dotnet-targeting-pack-3.0 x86_64 3.0.1-1 packages-microsoft-com-prod 3.4 M Transaction Summary ============================================================================================================================================================================================================================================== Install 9 Packages Total download size: 105 M Installed size: 105 M Is this ok [y/N]: yThis completed successfully, with the manual install of
sudo dnf install -y https://packages.microsoft.com/centos/7/prod/netstandard-targeting-pack-2.1.0-x64.rpmBut I then got this error
15:50 Project 'Frank.EndToEndTests' load finished with warnings: The FrameworkReference 'Microsoft.NETCore.App' was not recognized at (264:5)Which seemed rather odd.
I then manually installed this package
https://packages.microsoft.com/centos/7/prod/dotnet-targeting-pack-3.0.0-x64.rpmAnd everything worked!
- I think the dotnet-sdk-3.0 package should have a dependency on
dotnet-targeting-pack-3.0.0, unless I'm missing something?- It's more than a checksum issue, I think there are some issues with the yum repos
Hmm - just relooking over the dnf transaction output - it does include
dotnet-targeting-pack-3.0
These are for 3.0.1!
============================================================================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================================================================== Downgrading: dotnet-targeting-pack-3.0 x86_64 3.0.0-1 @commandline 3.4 M Transaction Summary ============================================================================================================================================================================================================================================== Downgrade 1 PackageI think the packages are missing the minor version which is causing major confusion!
Notice that yum is treating this as a downgrade, so I can't target 3.0.1 and 3.0.0 on the same machine. :sadface:
EDIT: dnf repos expect these packages to respect semver. I think we should have dotnet-targeting-pack-3.0.0 and dotnet-targeting-pack-3.0.1 packages published separately so that they can both be installed side-by-side
EDIT EDIT: :thinking: so the alternative here I see is that the 3.0.1-1 is supposed to be backwards compatible, and there's actually a defect in it.
dagood
commented
5 years ago The root issue here is that dotnet-targeting-pack-3.0-3.0.1 shouldn't have been published at all. 3.0.0 should be the latest. @leecow, can these be removed?
(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. https://github.com/dotnet/core-setup/pull/8827.)
I think we should have dotnet-targeting-pack-3.0.0 and dotnet-targeting-pack-3.0.1 packages published separately so that they can both be installed side-by-side
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 Microsoft.NETCore.App.Ref 3.0.0 from nuget.org to your user directory, and use that. Targeting packs (".Ref") don't roll forward so the version match needs to be exact.
We intend to support offline scenarios so this is something that I believe needs fixing.
dagood
commented
5 years ago @craigjbass taking another look at this, I do think that having dotnet-sdk-3.0-3.0.101 depend on exactly dotnet-targeting-pack-3.0.3.0.0 would be another way to solve this, and would be more robust for other situations too. I opened https://github.com/dotnet/core-sdk/issues/5738 to track and discuss this. (There might be reasons to keep this version "floating" that I forgot or don't know, we'll see there.)
nguerrera
commented
5 years ago 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.
nguerrera
commented
5 years ago 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?
dagood
commented
5 years ago 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 https://github.com/dotnet/core-setup/pull/8827 for 3.0.2+ so that we won't even create these packages unless there's a patch.
rodrigodevelms
commented
5 years ago Thank's all for helping. But something very strange happened. I installed netcore by adding the repository to debian repo. I deleted the obj and bin folders and the error continued. Even creating a new project, the error persisted. So I decided to restart the laptop, and everything worked. Very strange.
mtarlac
commented
5 years ago Same problem here...
Reinstall doesn't help
dotnet --info .NET Core SDK (reflecting any global.json): Version: 3.0.101 Commit: bc5f8df0f5
Runtime Environment: OS Name: linuxmint OS Version: 18.3 OS Platform: Linux RID: linuxmint.18.3-x64 Base Path: /usr/share/dotnet/sdk/3.0.101/
Host (useful for support): Version: 3.0.1 Commit: 19942e7199
.NET Core SDKs installed: 3.0.101 [/usr/share/dotnet/sdk]
.NET Core runtimes installed: Microsoft.AspNetCore.App 3.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download
dagood
commented
5 years ago 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.
togamid
commented
5 years ago 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.
dagood
commented
5 years ago 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.)
Perustaja
commented
5 years ago Sameish issue here on Fedora I think. When attempting to open a project I get
The "ResolveTargetingPackAssets" task failed unexpectedly. System.IO.FileNotFoundException: Could not find file "/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/data/FrameworkList.xml"
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:
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.
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.
judep90
commented
5 years ago @Perustaja - Same issue on Fedora. The specific issue cited is looking for a file provided by dotnet-targeting-pack-3.0-3.0.0-1. After installing that exact version I now end up with a different issue
PS /tmp> New-Item -Type Directory DotnetTest
Directory: /tmp
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 11/22/19 6:13 PM DotnetTest
PS /tmp> cd ./DotnetTest/
PS /tmp/DotnetTest> dotnet new console
The template "Console Application" was created successfully.
Processing post-creation actions...
Running 'dotnet restore' on /tmp/DotnetTest/DotnetTest.csproj...
Restore completed in 62.78 ms for /tmp/DotnetTest/DotnetTest.csproj.
Restore succeeded.
PS /tmp/DotnetTest> dotnet build
Microsoft (R) Build Engine version 16.3.0+0f4c62fea for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 13.57 ms for /tmp/DotnetTest/DotnetTest.csproj.
/usr/share/dotnet/sdk/3.0.100/Microsoft.Common.CurrentVersion.targets(4563,5): error MSB3030: Could not copy the file "/tmp/DotnetTest/obj/Debug/netcoreapp3.0/DotnetTest" because it was not found. [/tmp/DotnetTest/DotnetTest.csproj]
Build FAILED.
/usr/share/dotnet/sdk/3.0.100/Microsoft.Common.CurrentVersion.targets(4563,5): error MSB3030: Could not copy the file "/tmp/DotnetTest/obj/Debug/netcoreapp3.0/DotnetTest" because it was not found. [/tmp/DotnetTest/DotnetTest.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.69
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.
nguerrera
commented
5 years ago Cc @dsplaisted
dagood
commented
5 years ago In at least one of these cases it looks like the packs/microsoft.netcore.app.ref/3.0.0 directory still exists
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 dotnet-targeting-pack-3.0-3.0.1 RPMs, this issue will no longer happen when someone performs a new upgrade because dotnet-targeting-pack-3.0-3.0.0 will be the latest version as expected. If we didn't publish the bad dotnet-targeting-pack-3.0-3.0.1, this uninstall issue wouldn't have shown up in this release.
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/, dotnet-targeting-pack-3.0.1-x64.rpm.
If you're affected by this, you can manually downgrade to the 3.0.0 version to restore the files:
sudo dnf install dotnet-targeting-pack-3.0-3.0.0Alternatively, you can simply delete the /usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0 directory to clean up after the bad uninstall and let the SDK download the targeting pack from nuget.org.
(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.)
judep90
commented
5 years ago Alternatively, you can simply delete the /usr/share/packs/Microsoft.NETCore.App.Ref/3.0.0 directory to clean up after the bad uninstall
/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0 for anyone looking for it
dagood
commented
5 years ago Oops, thanks @judep90, corrected.
tosha-ret
commented
5 years ago Ubuntu 18.04 Temporary solution:
1) sudo apt-get remove dotnet-sdk-3.0 (uninstall latest sdk 3.0-3.101-1)
2) download previous sdk
3) sudo tar -xvf dotnet-sdk-3.0.100-linux-x64.tar.gz -C /usr/share/dotnet
(unpack downloaded archive)
4) reload project
Nihlus
commented
5 years ago An easier workaround for Ubuntu 18.04 is to do the same as for Fedora - downgrade to the working version.
sudo apt install dotnet-targeting-pack-3.0=3.0.0-1
tosha-ret
commented
5 years ago An easier workaround for Ubuntu 18.04 is to do the same as for Fedora - downgrade to the working version.
sudo apt install dotnet-targeting-pack-3.0=3.0.0-1
Don't work for me, unfortunetly....
My system: elementary OS 5.0 Juno Ubuntu 18.04.2 LTS Linux 4.15.0-70-generic GTK 3.22.30
SDK for .NET Core (3.0.101)
valeravorobjev
commented
5 years ago fedora 30 error MSB4018: The "ResolveTargetingPackAssets" task failed unexpectedly.
dagood
commented
5 years ago @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 Yes, this issue is tracking getting that fixed. Check https://github.com/dotnet/core/issues/3868#issuecomment-557770908 for workarounds that apply to F30.
Nihlus
commented
5 years ago 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 notifications@github.com 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) https://github.com/dotnet/core/issues/3868#issuecomment-557770908 for workarounds that apply to F30.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dotnet/core/issues/3868?email_source=notifications&email_token=AAR3MTDWCFRCMPM5UYFD6VTQWVMLXA5CNFSM4JPWASV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFURZRQ#issuecomment-560536774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR3MTELJRAKL2YHCESIG5TQWVMLXANCNFSM4JPWASVQ .
dagood
commented
5 years ago I'm actually surprised you're seeing this on Ubuntu, come to think of it.
The underlying issue in this thread is incorrect directory ownership, but Debian packages (like Ubuntu uses) don't have directory ownership as a concept, only owning files. When upgrading from 3.0.0 to 3.0.1, the 3.0.0 dir is cleaned up. This means the nuget.org fallback should work fine. I tested the upgrade scenario in Ubuntu 19.04 and 18.04 Docker containers and didn't repro the issue.
Please do open a new issue with repro steps (or just more info) if you can... very interested in this problem, but I'm not able to repro myself and want to keep this thread focused on the RPM issue that has a known cause and fix that we're working on.
Nihlus
commented
5 years ago @dagood Are you sure? Since the original issue is about Debian, and the RPM issue was only discovered later in the thread, it might be best to keep everything under the same roof.
As for my Ubuntu 18.04 (Linux Mint, actually, but same difference), installing dotnet-sdk-3.0 from scratch (sdk-2.1 installed) currently produces a broken install on it. The versions installed of the various packages are as below:
Setting up dotnet-hostfxr-3.0 (3.0.1-1) ...
Setting up netstandard-targeting-pack-2.1 (2.1.0-1) ...
Setting up dotnet-apphost-pack-3.0 (3.0.1-1) ...
Setting up dotnet-runtime-deps-3.0 (3.0.1-1) ...
Setting up dotnet-targeting-pack-3.0 (3.0.1-1) ...
Setting up dotnet-runtime-3.0 (3.0.1-1) ...
Setting up aspnetcore-targeting-pack-3.0 (3.0.1-1) ...
Setting up aspnetcore-runtime-3.0 (3.0.1-1) ...
Setting up dotnet-sdk-3.0 (3.0.101-1) ...Going from never having sdk-3.0 installed to installing it produces the reported error, same as everyone else. Performing a package downgrade using sudo apt install dotnet-targeting-pack-3.0=3.0.0-1 returns the install to a functional state.
dagood
commented
5 years ago Well, I'm sure I'd prefer them separate, but you're right that I messed it up by thinking the RPM issue was the same early on, and forgot the original issue mentioned Debian. 😛 My concern is a confusing conversation thread. Would take effort to split it out now though, I'm fine continuing here.
I'm not able to repro the issue from a fresh container with a fresh project--this works fine for me, printing "Hello World!" and having restored the 3.0.0 app.ref package as fallback:
docker run -it --rm ubuntu:18.04 bash -c '
set -x
apt update ; apt install wget sudo -y
wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt-get update
sudo apt-get install dotnet-sdk-2.1 -y # Simulate how your machine has 2.1
sudo apt-get install dotnet-sdk-3.0 -y
dotnet new console -o consoleapp
cd consoleapp
dotnet run
dotnet --info
ls /usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/
ls ~/.nuget/packages/microsoft.netcore.app.ref/'There could certainly be stuff that's different with a "real" fresh machine... will need more details. A binlog might help quite a bit (but make sure to read the security caution on the page before uploading one): http://msbuildlog.com/#usingbl
Nihlus
commented
5 years ago I think I've got it figured out. Updating to 3.0.1-1 reintroduces the problem, so I went from there, and did the steps above using dotnet new and dotnet run - that does, indeed, restore a local fallback, and everything works as expected.
Until now, I'd been using an existing project, and performing a restore through Rider, which probably has some sanity checks in terms of packages already being restored, and because of that, probably doesn't run dotnet restore unless it thinks it needs to.
That behaviour should probably be pinged to the JetBrains devs for reconsideration, along with seeing a fix for the broken debian package.
dagood
commented
5 years ago Aha, that makes sense. I wouldn't actually be surprised if something similar came up when using the dotnet CLI commands in some way. I'm not able to get it to happen with a simple "install the SDK with the 3.0.0 targeting pack => dotnet run => install 3.0.1 targeting pack => dotnet run". Other simple examples like the xunit template and dotnet test don't seem to do it either. The general idea makes sense, though, that things can break when the intermediate bin/obj dirs exist and point to these things. VS Code Omnisharp might also break.
The plan is to remove all 3.0.1 dotnet-targeting-pack packages from the repos, which will solve this for new installs for both RPM and Deb package users. The RPM has an extra underlying bug that makes it a little nastier, but there is no bug in the Debian package other than it existing.
@leecow, where are we at with removing the bad dotnet-targeting-pack-3.0 3.0.1 packages?
tosha-ret
commented
5 years ago @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 Yes, this issue is tracking getting that fixed. Check #3868 (comment) for workarounds that apply to F30.
It is my working environment:
dotnet --info
Пакет SDK для .NET Core (отражающий любой global.json):
Version: 3.0.100
Commit: 04339c3a26
Среда выполнения:
OS Name: elementary
OS Version: 5.0
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/3.0.100/
Host (useful for support):
Version: 3.0.1
Commit: 19942e7199
.NET Core SDKs installed:
2.2.402 [/usr/share/dotnet/sdk]
3.0.100 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
dsajanice
commented
4 years ago I hit a similar issue on Windows in a very obscure way. I had VS 16.3 on my machine and had .NET Core SDK versions 2.2.103 and 3.1.100. My code was compiling fine. I updated VS to 16.4 and then started to see the following error.
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 recognizedI installed SDK version 3.0.101 and then compile succeeded. Is there documentation stating that there is a dependency between 3.1.x and 3.0.x?
dagood
commented
4 years ago @dsajanice That's interesting... seems similar to the Rider issue. I wasn't able to repro with a simple netcoreapp3.0 console project that I built with 16.3 then built again after upgrading to 16.4. It builds fine with just the 3.1.100 SDK installed at that point. It used the fallback targeting pack download from nuget.org.
For background:
A binlog would help here, too (make sure to read the security caution on the page): http://msbuildlog.com/#usingbl
benelliott
commented
4 years ago I have the same issue as @dsajanice - Installed SDK 3.1.100 on a Windows 10 x64 machine, using Rider. Can't build through the IDE or the command line. Installing SDK 3.0.101 didn't fix it.
dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.1.100
Commit: cd82f021f4
Runtime Environment:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.100\
Host (useful for support):
Version: 3.1.0
Commit: 65f04fb6db
.NET Core SDKs installed:
1.0.1 [C:\Program Files\dotnet\sdk]
1.1.10 [C:\Program Files\dotnet\sdk]
2.1.105 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.402 [C:\Program Files\dotnet\sdk]
2.2.102 [C:\Program Files\dotnet\sdk]
2.2.103 [C:\Program Files\dotnet\sdk]
3.0.101 [C:\Program Files\dotnet\sdk]
3.1.100 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
λ dotnet build
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 54.82 ms for [my project].
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.AspNetCore.App' was not recognized [my csproj]
Build FAILED.
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.AspNetCore.App' was not recognized [my csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.73
@benelliott Unfortunately there's not much I can do without more info. A repro project would be a minimum for me to attempt to repro again by upgrading VS 16.3 => 16.4, or a binlog would be more direct if you're ok with what it stores. Since you're able to repro with dotnet build it's particularly easy in your case to get a binlog via dotnet build /bl.
benelliott
commented
4 years ago @dagood Here's a build log in XML format (as TXT to allow GitHub upload). Hope it helps. build-log.txt
dagood
commented
4 years ago Thanks, that looks like it'll work great! I do see now that you're hitting the error for Microsoft.AspNetCore.App rather than Microsoft.NETCore.App, but I would expect a common root cause since they're both being upgraded.
The error itself comes from:
ResolveTargetingPackAssets
Assembly = C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\..\tools\netcoreapp2.1/Microsoft.NET.Build.Tasks.dll
Parameters
FrameworkReferences = Microsoft.AspNetCore.App
GenerateErrorForMissingTargetingPacks = True
Errors
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.AspNetCore.App' was not recognized [C:\git\dotnet-build-repro\src\MyProject\MyProject.csproj]
OutputProperties
PackageConflictPreferredPackages = I believe that normally there should be some ResolvedTargetingPacks item parameters:
<ResolveTargetingPackAssets FrameworkReferences="@(FrameworkReference)"
ResolvedTargetingPacks="@(ResolvedTargetingPack)"
RuntimeFrameworks="@(RuntimeFramework)"
GenerateErrorForMissingTargetingPacks="$(GenerateErrorForMissingTargetingPacks)">@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?
bashenk
commented
4 years ago 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 netcoreapp3.1 (from netcoreapp3.0), and it then built successfully.
My config now begins with this
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<LangVersion>latestmajor</LangVersion>
prcdpr
commented
4 years ago 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.
dsplaisted
commented
4 years ago @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.
pmunshi007
commented
4 years ago 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. I am running this in docker container and base container install dotnet-sdk-3.0 on cent os Inside container ran below command
> dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.0.101
Commit: bc5f8df0f5
Runtime Environment:
OS Name: centos
OS Version: 7
OS Platform: Linux
RID: centos.7-x64
Base Path: /usr/share/dotnet/sdk/3.0.101/
Host (useful for support):
Version: 3.0.1
Commit: 19942e7199
.NET Core SDKs installed:
3.0.101 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:dotnet build on a project throws below error.
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: The "ResolveTargetingPackAssets" task failed unexpectedly. [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: System.IO.FileNotFoundException: Could not find file '/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/data/FrameworkList.xml'. [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: File name: '/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/data/FrameworkList.xml' [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials, IWebProxy proxy, RequestCachePolicy cachePolicy) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.XmlTextReaderImpl.FinishInitUriString() [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.XmlTextReaderImpl..ctor(String uriStr, XmlReaderSettings settings, XmlParserContext context, XmlResolver uriResolver) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.XmlReaderSettings.CreateReader(String inputUri, XmlParserContext inputContext) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings settings) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at System.Xml.Linq.XDocument.Load(String uri) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at Microsoft.NET.Build.Tasks.ResolveTargetingPackAssets.AddReferencesFromFrameworkList(String frameworkListPath, String targetingPackDllFolder, ITaskItem targetingPack, List`1 referenceItems) [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at Microsoft.NET.Build.Tasks.ResolveTargetingPackAssets.ExecuteCore() [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at Microsoft.NET.Build.Tasks.TaskBase.Execute() [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [abc.csproj]
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [abc.csproj]
0 Warning(s)
1 Error(s)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.
mlapaglia
commented
4 years ago 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.
Thanks, this worked for me.
pmunshi007
commented
4 years ago @mlapaglia In my case only 3.0.101 directory exist in microsoft.netcore.app.ref direcrotory and somehow program is looking for 3.0.0 .. How you were having 3.0.0 and 3.0.1 both.
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(264,5): error MSB4018: File name: '/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/data/FrameworkList.xml'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.
dagood
commented
4 years ago Workarounds for the bad 3.0.1 package are already in the thread:
If you're affected by this, you can manually downgrade to the 3.0.0 version to restore the files:
sudo dnf install dotnet-targeting-pack-3.0-3.0.0Alternatively, you can simply delete the
/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0directory to clean up after the bad uninstall and let the SDK download the targeting pack from nuget.org.(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.)
An easier workaround for Ubuntu 18.04 is to do the same as for Fedora - downgrade to the working version.
sudo apt install dotnet-targeting-pack-3.0=3.0.0-1
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: https://github.com/dotnet/core/issues/3868#issuecomment-563396717. 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.
pmunshi007
commented
4 years ago 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 yum upgrade command which was upgrading the dotnet version to 3.0.1 and due to that application contained empty /usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/data/ directory and it was throwing error for /usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/data/FrameworkList.xml file not found.
My issue is resolved by removing that yum upgrade command for now. however if the dotnet sdk version get upgraded then it should also point to or look for right path for FrameworkList.xml file.
boeremak
commented
4 years ago 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.
nguerrera
commented
4 years ago @boeremak can you start a new issue with VS in the title on dotnet/sdk and provide a binlog of a failed build. The simpler the repro project the better, if possible.
There are distinct issues in this thread and I think it will be best to have separate issues.
boeremak
commented
4 years ago 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) 2019 Microsoft Corporation. All rights reserved.
C:\Dev\repos\solution>dotnet msbuild Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core Copyright (C) Microsoft Corporation. All rights reserved.
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:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(283,5): error NETSDK1073: The FrameworkReference 'Microsoft.AspNetCore.App' was not recognized [C:\Dev\repos\solution\solution.fsproj]
C:\Dev\repos\solution>dotnet build Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 5,47 sec for C:\Dev\repos\solution\solution.fsproj. solution -> C:\Dev\repos\solution\bin\Debug\netcoreapp3.0\solution.dll
Build succeeded. 0 Warning(s) 0 Error(s)
Time Elapsed 00:00:10.98 C:\Dev\repos\solution>dotnet msbuild Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core Copyright (C) Microsoft Corporation. All rights reserved.
solution -> C:\Dev\repos\solution\bin\Debug\netcoreapp3.0\solution.dll ` No clue.
nguerrera
commented
4 years ago 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. :()
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)