FrameworkReference 'Microsoft.NETCore.App' was not recognized at (264: 5)

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 <IP_ADDRESS> (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)

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?

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 -

I removed dotnet packages entirely to be able to perform a system upgrade.
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.0 package:
> $ 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]: y

This 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.rpm
But 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.rpm
And 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 Package

I 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.

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.

@craigjbass taking another look at this, I do think that having dotnet-sdk-3.0-3.0.101 depend on exactly dotnet-targeting-pack-<IP_ADDRESS>.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.)

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?

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.

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.

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

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.
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]

@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/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

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.0

Alternatively, you can simply delete the /usr/share/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.)

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

Oops, thanks @judep90, corrected.

Ubuntu 18.04 Temporary solution:

sudo apt-get remove dotnet-sdk-3.0 (uninstall latest sdk 3.0-3.101-1)
download previous sdk
sudo tar -xvf dotnet-sdk-3.0.100-linux-x64.tar.gz -C /usr/share/dotnet
(unpack downloaded archive)
reload project

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

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)

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 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.

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<EMAIL_ADDRESS>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
.

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 an Ubuntu 19.04 Docker container and didn't repro the issue.
Please do open a new issue with repro steps 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.

@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.

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/'

Partial output (click me)
...
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) ...
...
+ dotnet run
Hello World!
+ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.101
 Commit:    bc5f8df0f5

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.0.101/

Host (useful for support):
  Version: 3.0.1
  Commit:  19942e7199

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

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.14 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.14 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.14 [/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
+ ls /usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/
3.0.1
+ ls /root/.nuget/packages/microsoft.netcore.app.ref/
3.0.0

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

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.

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 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
`

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 recognized

I 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?

@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.
A binlog would help here, too (make sure to read the security caution on the page): http://msbuildlog.com/#usingbl

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.

@dagood Here's a build log in XML format (as TXT to allow GitHub upload). Hope it helps.
build-log.txt

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)">

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.)
ProcessFrameworkReferences
    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
        KnownFrameworkReferences
            Microsoft.NETCore.App
                DefaultRuntimeFrameworkVersion = 3.1.0
                IsTrimmable = true
                LatestRuntimeFrameworkVersion = 3.1.0
                RuntimeFrameworkName = Microsoft.NETCore.App
                RuntimePackNamePatterns = Microsoft.NETCore.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = linux-arm;linux-arm64;linux-musl-arm64;linux-musl-x64;linux-x64;osx-x64;rhel.6-x64;tizen.4.0.0-armel;tizen.5.0.0-armel;win-arm;win-arm64;win-x64;win-x86
                TargetFramework = netcoreapp3.1
                TargetingPackName = Microsoft.NETCore.App.Ref
                TargetingPackVersion = 3.1.0
            Microsoft.WindowsDesktop.App
                DefaultRuntimeFrameworkVersion = 3.1.0
                IsWindowsOnly = true
                LatestRuntimeFrameworkVersion = 3.1.0
                RuntimeFrameworkName = Microsoft.WindowsDesktop.App
                RuntimePackNamePatterns = Microsoft.WindowsDesktop.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86
                TargetFramework = netcoreapp3.1
                TargetingPackName = Microsoft.WindowsDesktop.App.Ref
                TargetingPackVersion = 3.1.0
            Microsoft.WindowsDesktop.App.WPF
                DefaultRuntimeFrameworkVersion = 3.1.0
                IsWindowsOnly = true
                LatestRuntimeFrameworkVersion = 3.1.0
                Profile = WPF
                RuntimeFrameworkName = Microsoft.WindowsDesktop.App
                RuntimePackNamePatterns = Microsoft.WindowsDesktop.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86
                TargetFramework = netcoreapp3.1
                TargetingPackName = Microsoft.WindowsDesktop.App.Ref
                TargetingPackVersion = 3.1.0
            Microsoft.WindowsDesktop.App.WindowsForms
                DefaultRuntimeFrameworkVersion = 3.1.0
                IsWindowsOnly = true
                LatestRuntimeFrameworkVersion = 3.1.0
                Profile = WindowsForms
                RuntimeFrameworkName = Microsoft.WindowsDesktop.App
                RuntimePackNamePatterns = Microsoft.WindowsDesktop.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86
                TargetFramework = netcoreapp3.1
                TargetingPackName = Microsoft.WindowsDesktop.App.Ref
                TargetingPackVersion = 3.1.0
            Microsoft.AspNetCore.App
                DefaultRuntimeFrameworkVersion = 3.1.0
                LatestRuntimeFrameworkVersion = 3.1.0
                RuntimeFrameworkName = Microsoft.AspNetCore.App
                RuntimePackNamePatterns = Microsoft.AspNetCore.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86;win-arm;osx-x64;linux-musl-x64;linux-musl-arm64;linux-x64;linux-arm;linux-arm64
                TargetFramework = netcoreapp3.1
                TargetingPackName = Microsoft.AspNetCore.App.Ref
                TargetingPackVersion = 3.1.0
            Microsoft.NETCore.App
                DefaultRuntimeFrameworkVersion = 3.0.0
                IsTrimmable = true
                LatestRuntimeFrameworkVersion = 3.0.1
                RuntimeFrameworkName = Microsoft.NETCore.App
                RuntimePackNamePatterns = Microsoft.NETCore.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = linux-arm;linux-arm64;linux-musl-arm64;linux-musl-x64;linux-x64;osx-x64;rhel.6-x64;tizen.4.0.0-armel;tizen.5.0.0-armel;win-arm;win-arm64;win-x64;win-x86
                TargetFramework = netcoreapp3.0
                TargetingPackName = Microsoft.NETCore.App.Ref
                TargetingPackVersion = 3.0.0
            Microsoft.WindowsDesktop.App
                DefaultRuntimeFrameworkVersion = 3.0.0
                IsWindowsOnly = true
                LatestRuntimeFrameworkVersion = 3.0.1
                RuntimeFrameworkName = Microsoft.WindowsDesktop.App
                RuntimePackNamePatterns = Microsoft.WindowsDesktop.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86
                TargetFramework = netcoreapp3.0
                TargetingPackName = Microsoft.WindowsDesktop.App.Ref
                TargetingPackVersion = 3.0.0
            Microsoft.WindowsDesktop.App.WPF
                DefaultRuntimeFrameworkVersion = 3.0.0
                IsWindowsOnly = true
                LatestRuntimeFrameworkVersion = 3.0.1
                Profile = WPF
                RuntimeFrameworkName = Microsoft.WindowsDesktop.App
                RuntimePackNamePatterns = Microsoft.WindowsDesktop.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86
                TargetFramework = netcoreapp3.0
                TargetingPackName = Microsoft.WindowsDesktop.App.Ref
                TargetingPackVersion = 3.0.0
            Microsoft.WindowsDesktop.App.WindowsForms
                DefaultRuntimeFrameworkVersion = 3.0.0
                IsWindowsOnly = true
                LatestRuntimeFrameworkVersion = 3.0.1
                Profile = WindowsForms
                RuntimeFrameworkName = Microsoft.WindowsDesktop.App
                RuntimePackNamePatterns = Microsoft.WindowsDesktop.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86
                TargetFramework = netcoreapp3.0
                TargetingPackName = Microsoft.WindowsDesktop.App.Ref
                TargetingPackVersion = 3.0.0
            Microsoft.AspNetCore.App
                DefaultRuntimeFrameworkVersion = 3.0.0
                LatestRuntimeFrameworkVersion = 3.0.1
                RuntimeFrameworkName = Microsoft.AspNetCore.App
                RuntimePackNamePatterns = Microsoft.AspNetCore.App.Runtime.**RID**
                RuntimePackRuntimeIdentifiers = win-x64;win-x86;win-arm;osx-x64;linux-musl-x64;linux-musl-arm64;linux-x64;linux-arm;linux-arm64
                TargetFramework = netcoreapp3.0
                TargetingPackName = Microsoft.AspNetCore.App.Ref
                TargetingPackVersion = 3.0.1
            NETStandard.Library
                TargetFramework = netstandard2.1
                TargetingPackName = NETStandard.Library.Ref
                TargetingPackVersion = 2.1.0
        TargetFrameworkIdentifier = .NETStandard
        TargetFrameworkVersion = 2.0
        TargetingPackRoot = C:\Program Files\dotnet\packs
        RuntimeGraphPath = C:\Program Files\dotnet\sdk\3.1.100\RuntimeIdentifierGraph.json
        TargetLatestRuntimePatch = False
        TargetLatestRuntimePatchIsDefault = True
        EnableTargetingPackDownload = True
    OutputItems
        _PackageToDownload =
        RuntimeFramework =
        TargetingPack =
        RuntimePack =
        UnavailableRuntimePack =

@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 netcoreapp3.1 (from netcoreapp3.0), and it then built successfully.
My config now begins with this
  <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

@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.
I am running this in docker container and base container install dotnet-sdk-3.0 on cent os
Inside container ran below command
.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, Func2 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, List1 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.

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.

@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.

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 issue of the directory existing 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.0

Alternatively, 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.)

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.

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.

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?

@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.

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.

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/dotnet msbuild. It's just unfortunately not possible to tell which one's being hit from an error message alone.

@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.

@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.

@dsplaisted - I am also in the same boat. I am upgrading application from 2.1 to 3.1 and have project using .Net Standard 2.1 which has  package reference to
Include="Microsoft.AspNetCore" Version="2.2.0". This package is no more available in .Net core 3.1 and it is absolute.  How to resolve this if I need to stay with .Net Standard 2.1 and use Microsoft.AspNetCore latest one. (3.1.0)

@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.

[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 dt 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:
/usr/local/share/dotnet/sdk/3.1.300/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(5,5): Error NETSDK1073: The FrameworkReference 'Microsoft.WindowsDesktop.App.WPF' was not recognized (NETSDK1073) (MyTrails.CLI)
On Catalina:
System Version:	macOS 10.15.5 (19F101)
Kernel Version:	Darwin 19.5.0

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.
VS Details are as follows:
`=== Visual Studio Community 2019 for Mac ===
Version 8.7.1 (build 15)
Installation UUID: 151a6da6-b82d-4da3-ad54-29cf873ddcb4
GTK+ 2.24.23 (Raleigh theme)
Xamarin.Mac <IP_ADDRESS> (d16-6 / 088c73638)
Package version: 612000090

=== Mono Framework MDK ===
Runtime:
Mono <IP_ADDRESS> (2020-02/d3daacdaa80) (64-bit)
Package version: 612000090
=== Roslyn (Language Service) ===
3.7.0-6.20371.12+917b9dfae12e3b6cb266a3c062fb20a1e9d5fb06
=== NuGet ===
Version: <IP_ADDRESS>02
=== .NET Core SDK ===
SDK: /usr/local/share/dotnet/sdk/3.1.302/Sdks
SDK Version: 3.1.302
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Sdks
=== .NET Core Runtime ===
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
3.1.6
2.1.20
=== Xamarin.Profiler ===
Version: <IP_ADDRESS>
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Updater ===
Version: 11
=== Apple Developer Tools ===
Xcode 11.6 (16141)
Build 11E708
=== Xamarin.Mac ===
Xamarin.Mac not installed. Can't find /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Version.
=== Xamarin.iOS ===
Version: <IP_ADDRESS> (Visual Studio Community)
Hash: 817b6f72a
Branch: d16-7
Build date: 2020-07-18 18:45:00-0400
=== Xamarin Designer ===
Version: <IP_ADDRESS>2
Hash: f5afe667d
Branch: remotes/origin/d16-7-vsmac
Build date: 2020-07-10 18:42:54 UTC
=== Xamarin.Android ===
Version: <IP_ADDRESS> (Visual Studio Community)
Commit: xamarin-android/d16-7/aca845b
Android SDK: /Users/user/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
8.1 (API level 27)
SDK Tools Version: 26.1.1
SDK Platform Tools Version: 30.0.4
SDK Build Tools Version: 29.0.2
Build Information:
Mono: 83105ba
Java.Interop: xamarin/java.interop/d16-7@1f3388a
ProGuard: Guardsquare/proguard/proguard6.2.2@ebe9000
SQLite: xamarin/sqlite/3.32.1@1a3276b
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-7@017078f
=== Microsoft OpenJDK for Mobile ===
Java SDK: /Users/user/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_<IP_ADDRESS>
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL
=== Android SDK Manager ===
Version: <IP_ADDRESS>
Hash: 8380518
Branch: remotes/origin/dev/jmt/d16-7readconfig~2
Build date: 2020-07-23 22:38:02 UTC
=== Android Device Manager ===
Version: <IP_ADDRESS>
Hash: 4b44bc1
Branch: remotes/origin/d16-7
Build date: 2020-07-23 22:38:26 UTC
=== Build Information ===
Release ID: 807010015
Git revision: b2b8f289ffca8f28c585e9137d193c92462cbf14
Build date: 2020-08-07 10:38:31-04
Build branch: release-8.7
Xamarin extensions: b2b8f289ffca8f28c585e9137d193c92462cbf14
=== Operating System ===
Mac OS X 10.15.6
Darwin 19.6.0 Darwin Kernel Version 19.6.0
Thu Jun 18 20:49:00 PDT 2020
root:xnu-6153.141.1~1/RELEASE_X86_64 x86_64
`

@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.

@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.


replSetInitiate quorum check failed because not all proposed set members responded affirmatively

I'm trying this tutorial on macOS 10.12.6.
When running the configure_repset_auth.sh I have the following errors.
I'm new to kubernetes so I'm not sure what is going on.
After running the generate.sh script I have all three mongo pods running.
$ ./configure_repset_auth.sh abc123
Configuring the MongoDB Replica Set
MongoDB shell version v3.6.3
connecting to: mongodb://<IP_ADDRESS>:27017
MongoDB server version: 3.6.3
{
	"ok" : 0,
	"errmsg" : "replSetInitiate quorum check failed because not all proposed set members responded affirmatively: mongod-1.mongodb-service.default.svc.cluster.local:27017 failed with Couldn't get a connection within the time limit, mongod-2.mongodb-service.default.svc.cluster.local:27017 failed with Couldn't get a connection within the time limit",
	"code" : 74,
	"codeName" : "NodeNotFound"
}
Waiting for the Replica Set to initialise...
MongoDB shell version v3.6.3
connecting to: mongodb://<IP_ADDRESS>:27017
MongoDB server version: 3.6.3
{
	"info" : "run rs.initiate(...) if not yet done for the set",
	"ok" : 0,
	"errmsg" : "no replset config has been received",
	"code" : 94,
	"codeName" : "NotYetInitialized"
}
Creating user: 'main_admin'
MongoDB shell version v3.6.3
connecting to: mongodb://<IP_ADDRESS>:27017
MongoDB server version: 3.6.3
2018-03-05T10:57:01.779+0000 E QUERY    [thread1] Error: couldn't add user: not master :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DB.prototype.createUser@src/mongo/shell/db.js:1437:15
@(shell eval):1:1
command terminated with exit code 252

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-07T12:22:21Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"", Minor:"", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2018-01-26T19:04:38Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"}

$ minikube version
minikube version: v0.25.0

you can check error log by using this command
kubectl logs mongod-0

After some other tests, I ended up in a situation where the pods where pending.
So I decided to start from scratch with:
minikube delete
rm -rf ~/.minikube
minikube start

and finally I was able to complete the readme.


Blog Pages

Can I host the blog pages too? Can I create new pages which open up in same website?

I can help to resolve, please assign to me

@RajivRnjan I am sorry, I cannot assign the issue to you. I believe I don't have permission to assign issues.

I have a similar question. I also want to add a blog page, but I'm unsure where to begin. Below is the current structure of my project and the deployed webpage:

https://github.com/1chooo/1chooo.com
https://1chooo.com

@maheshwaripranav Hi, I've developed the blog page!!!
https://github.com/codewithsadee/vcard-personal-portfolio/issues/132


Extracting timing information from requests

Hi,
Since (at least) Requests 2.6.2 elapsed time is recorded and stored in Response.elapsed. I'm about to hackishly expose it for my own purposes (not sure how yet) and was wondering if there was a way you could recommend or if you would be interested in including such a change.

This was the smallest change i came up with.
@@ -29,10 +29,11 @@ class Betfair(object):
         self.cert_file = cert_file
         self.content_type = content_type
         self.session = requests.Session()
         self.session_token = None
         self.API_URL = None
+	self.last_api_time = None

     # Set api_url
     @property
     def api_url(self):
         """Retreive a value for self.API_URL"""
@@ -61,10 +62,11 @@ class Betfair(object):
     def make_auth_request(self, method):
         response = self.session.post(
             os.path.join(IDENTITY_URL, method),
             headers=self.headers,
         )
+	self.last_api_time = response.elapsed
         utils.check_status_code(response)
         data = response.json()
         if data.get('status') != 'SUCCESS':
             raise exceptions.BetfairAuthError(response, data)

@@ -73,10 +75,11 @@ class Betfair(object):
         response = self.session.post(
             self.API_URL,
             data=json.dumps(payload),
             headers=self.headers,
         )
+	self.last_api_time = response.elapsed
         utils.check_status_code(response, codes=codes)
         result = utils.result_or_error(response)
         return utils.process_result(result, model)

     # Authentication methods
@@ -99,10 +102,11 @@ class Betfair(object):
             headers={
                 'X-Application': self.app_key,
                 'Content-Type': 'application/x-www-form-urlencoded',
             },
         )
+	self.last_api_time = response.elapsed
         utils.check_status_code(response, [httplib.OK])
         data = response.json()
         if data.get('loginStatus') != 'SUCCESS':
             raise exceptions.BetfairLoginError(response, data)
         self.session_token = data['sessionToken']

After the request the value is accessed via client.last_api_time which is updated on each invocation of the method. As long as you deal with the time after each invocation (which I am doing now) this seems to work.

I'm not sure how many users of the library are going to need timing information, so my preferred solution would be to implement this logic outside the library. I just pushed a change to the library such that you can create a betfair client with a custom requests session (in https://github.com/jmcarp/betfair.py/commit/af75f98218b379c4712d78687cf57a2001371029). What I would recommend is that you subclass requests.Session and pass your custom session instance to the betfair client. That way, you're only defining the logic once (in the send method of your Session subclass), and we don't need to change betfair.py.
import requests
import betfair

class CustomSession(requests.Session):
    def send(self, *args, **kwargs):
        response = super(CustomSession, self).send(*args, **kwargs)
        self.last_elapsed = response.elapsed
        return response

client = betfair.Betfair(..., session=CustomSession())
client.list_current_orders(...)
print(client.session.last_elapsed)

Does that make sense?

As a long term fix that seems fair enough, and a more OO way of doing things. I haven't tried to rebase my changes onto the latest codebase (still on 0.1.3) so i will add this to my list of things to try when I finally do the change.

I've tested this with git head and one bet fair.py method but it appears to have worked
$ python2.7 ./script.py
all_events elapsed time 0:00:03.687835
result is [<betfair.models.MarketCatalogue object at 0x105a7edd0>, <betfair.models.MarketCatalogue object at 0x106818cd0>, <betfair.models.MarketCatalogue object at 0x106818d10>]


Corruption from threading conflict

In adding HashLog.pm I noticed sometimes that its logFile was getting corrupted, and sometimes locks were getting stuck.  Apache2 normally uses threads, so I suspected that something was not thread-safe.

I changed the apache2 configuration in 000-default.conf to limit each apache2 process to one thread.  So far, that seems to have corrected the problem.
#### dbooth added 9/19/21:
# Limit apache2 to one thread per process, because I am suspecting
# problems cause by thread conflicts.
# https://httpd.apache.org/docs/2.4/mod/worker.html
<IfModule mpm_event_module>
    StartServers             2
    ThreadsPerChild          1
    MaxConnectionsPerChild   0

    ServerLimit              64
    MinSpareThreads          1
    MaxSpareThreads          1
    MaxClients               64
    MaxRequestWorkers        64
</IfModule>


Fix a bug: creating a box with one point

This PR will fix a bug that was possible to create a box with one point, if you single-click without moving a cursor in "Create mode." It wasn't possible to enlarge the zero-sized box by clicking its vertex because it had only one point (also causing an index error), so with this PR a box shape can be changed from the zero size. However, the second commit will prevent from creating a zero-sized box.

Thanks~


[#156224236] Rotate master password in mysql RDS instances

What?
We found out that the RDS broker was not updating the master password of the
mysql RDS instances when the seed or the algorithm changes. This is because
the corresponding engine was not raising the right error when there
was an authentication issue.
In this PR we add the logic to raise the right error for mysql and add unit
tests for this logic.
In order for the tests to work, we need to add authentication to the postgres
database used during testing, both in docker (local) or travis. The reason
is that postgres would accept any password when the authentication is disabled.
In travis the only way is by updating the database in a before_script.
With mysql there was not such problem, because a password different than "" would fail.
How to review?

Code review.
Tests shall pass.
Optional: Deploy the RDS broker, create a mysql and psql instance,
try to change the seed and restart the broker.

Who?
Anyone but @keymon

Regarding MySQL:  I tried to add a password to keep consistency with psql, but I failed to enable password auth in travis. I tried ALTER USER and SET PASSWORD with no luck.
I got the errors like this one: https://travis-ci.org/alphagov/paas-rds-broker/builds/378668482
I had no issues with the local docker.
If the reviewer considers that it is important to have the password configured for both postgresql and mysql, I can try for a while more.

Regarding these comments: We can simply drop all the tests regarding wrong passwords and rely on the integration tests to check that the feature is still working.

@keymon we should not drop the unit tests, they are fine like this

.@keymon we should not drop the unit tests, they are fine like this

Other alternative is to consider a login failure in postgres the fact that the user is missing (role missing), and raise the same error. Then test with a user that does not exists. It is what it was happening in the other tests: https://github.com/alphagov/paas-rds-broker/blob/c152145d3f041e2399bc4a40bdf2b77878ca9f2f/sqlengine/postgres_engine_test.go#L359-L367
But the problem with that is that we are not really testing the actual behaviour that happens in production.


Quantised models (4, 8)

Feature request  / 功能建议
Need already quantised models for MacOS users where bitsandbytes is not supported
Motivation / 动机
bitsandbytes is not supported on MacOS
Your contribution / 您的贡献
https://github.com/ml-explore/mlx

Quantized models rely on bitsandbytes for hf version, not only in memory, but also computation when running forward pass.

mark


gluu

Hi
I was interested in checking out the Gluu Docker cluster. However, when downloading it I recieve this error message. We're Sorry. There seem to be an error: Tag latest not found in repository nekbab/gluu.
Not sure if this is expected or not...

@rashidniazi Which exact docker hub image is this? Does it have the latest tag?

Ouf not sure how to answer this. The image name when searching is "gluu" nekbab.

This seems to be a duplicate of #720
Closing for now

inspectig the existing tags in https://hub.docker.com/r/nekbab/gluu/tags/ i have pulled the v6 tag by issuing  docker pull nekbab/gluu:v6
But it provides no service when the image is started. It seems to be an empty centOS 6.5 image...


Update sbt-scalajs to 1.7.1

Updates org.scala-js:sbt-scalajs from 1.5.1 to 1.7.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-js", artifactId = "sbt-scalajs" } ]

labels: sbt-plugin-update, semver-minor

Superseded by #274.


improve reaction load performance

I assume the slowness is probably due to all my sorts that I call. It should be converted to a single loop with a ranked (additive) system. Should be O(n) or O(2n)

Completed in full rewrite


[WIP] Use callable object for patching dataloaders

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos, doc improvements)
[x] Did you read the contributor guideline?
[ ] Did you make sure to update the docs?

not sure if there's anywhere I need to

[ ] Did you write any new necessary tests?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

What does this PR do?
Fixes #968 .
Changes how we patch dataloaders when passed to trainer.fit() so that it's pickleable
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

@williamFalcon @Borda
Do we need tests for this?
Not sure if this needs a CHANGELOG change either.  would appreciate review!

Getting a very unhelpful error, will keep investigating
Exception                                 Traceback (most recent call last)
<ipython-input-15-bef80bcdc7b4> in <module>()
     16 # trainer = Trainer(num_tpu_cores=8)
     17
---> 18 trainer.fit(model, loader)

2 frames
/usr/local/lib/python3.6/dist-packages/torch/multiprocessing/spawn.py in join(self, timeout)
    110                 raise Exception(
    111                     "process %d terminated with exit code %d" %
--> 112                     (error_index, exitcode)
    113                 )
    114

Exception: process 0 terminated with exit code 1

Update: now if you pass your dataloaders to trainer.fit():

non-slurm ddp works in a VM/linux context
non-slurm ddp does not work in colab

the colab stack trace (my previous message) is unhelpful, and I'm having trouble figuring out how to get to the bottom of it
on the other hand, ddp in a colab context is an impractical scenario

colab TPU worked regardless of this PR
non-colab TPU works

Not sure what a change of this level warrants in terms of testing and documentation for pl.  Please let me know!
I added a gpu-ddp test for passing all the loaders to fit() and confirmed that this branch allows the test to pass

this is awesome! will pr review in a few hours!
thank u

i think ddp in colab needs the spawn flag or something

LGTM, just curious if simple functools would help too which does very similar wrapping
from functools import partial

dataloader = partial(dataloader)

partial is specifically for wrapping functions/callables and freezing sets of arguments, so you couldn't call it on a dataloader:
>>> from functools import partial
>>> x = partial(loader)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: the first argument must be callable


All the endpoint got "404 Not Found - No context found for request" except the /health endpoint.

The docker-compose.yml
version: "3.8"
services:
  redis-server:
    image: redis:latest
    container_name: redis-server-container
    ports:
      - "6379:6379"
    restart: unless-stopped
  mysql-server:
    image: mysql:latest
    container_name: mysql-server-container
    ports:
      - "3306:3306"
    volumes:
      - /home/mysql/data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: password
    restart: unless-stopped
  luckperms:
    image: ghcr.io/luckperms/luckperms
    container_name: luckperms-container
    extra_hosts:
      - "database:host-gateway"
    ports:
      - "3001:3001"
      - "8080:8080"
    environment:
      LUCKPERMS_REST_AUTH: "false"
      LUCKPERMS_STORAGE_METHOD: mysql
      LUCKPERMS_DATA_ADDRESS: database:3306
      LUCKPERMS_DATA_DATABASE: application_schema
      LUCKPERMS_DATA_USERNAME: root
      LUCKPERMS_DATA_PASSWORD: password

The luckperms output
2024-08-12T20:15:01.450792192Z [20:15:01 INFO]:         __
2024-08-12T20:15:01.451280390Z [20:15:01 INFO]:   |    |__)   LuckPerms v5.4.139
2024-08-12T20:15:01.451768840Z [20:15:01 INFO]:   |___ |      Running on Standalone - standalone
2024-08-12T20:15:01.451929624Z [20:15:01 INFO]:
2024-08-12T20:15:01.452595505Z [20:15:01 INFO]: Loading configuration...
2024-08-12T20:15:01.564248624Z [20:15:01 INFO]: Resolved configuration value from environment variable: LUCKPERMS_DATA_ADDRESS = database:3306
2024-08-12T20:15:01.564388711Z [20:15:01 INFO]: Resolved configuration value from environment variable: LUCKPERMS_DATA_DATABASE = application_schema
2024-08-12T20:15:01.564591020Z [20:15:01 INFO]: Resolved configuration value from environment variable: LUCKPERMS_DATA_USERNAME = root
2024-08-12T20:15:01.564724604Z [20:15:01 INFO]: Resolved configuration value from environment variable: LUCKPERMS_DATA_PASSWORD = *****
2024-08-12T20:15:01.565174622Z [20:15:01 INFO]: Resolved configuration value from environment variable: LUCKPERMS_STORAGE_METHOD = mysql
2024-08-12T20:15:01.717387131Z [20:15:01 INFO]: Loading storage provider... [MYSQL]
2024-08-12T20:15:01.731858965Z WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
2024-08-12T20:15:01.761392135Z [20:15:01 INFO]: luckperms-hikari - Starting...
2024-08-12T20:15:01.793041971Z [20:15:01 INFO]: luckperms-hikari - Start completed.
2024-08-12T20:15:02.007815937Z [20:15:02 INFO]: Loading messaging service... [SQL]
2024-08-12T20:15:02.079245717Z [20:15:02 INFO]: Loading internal permission managers...
2024-08-12T20:15:02.092266178Z [20:15:02 INFO]: Performing initial data load...
2024-08-12T20:15:02.117779710Z [20:15:02 INFO]: Successfully enabled. (took 755ms)
2024-08-12T20:15:02.130507445Z [20:15:02 INFO]: Started healthcheck HTTP server on :3001

Send request into http://localhost:3001/health:
{"healthy":true,"details":{"storageConnected":true,"storagePing":1}}

Send request into http://localhost:3001/group:

404 Not Found
No context found for request

Sorry for not reading the example.


Web Server flow - get back username in AuthenticationClient

We are replacing our Username-Password flow with the Web Server flow in a background process. We have two possible users who would use the process and so we want to ensure that we can persist their access and refresh tokens in a database against their usernames.
I see that the AuthenticationClient only gives an Id field (salesforce-based) and not the username. Is it possible to add the username as well which is what our process would know?

My reading of the Web Server flow is that it doesn't return the username: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_web_server_oauth_flow.htm.
@metadaddy-sfdc can confirm.
Using the Id field (which is a URL) you can then query it to get additional information, like the username. See: http://salesforce.stackexchange.com/a/11748

Correct - OAuth response in web server flow does not include the username. See Digging Deeper into OAuth 2.0 on Force.com.


Request for a docker image for ppc64le architecture

Hi Team,
It seems that the image for amd64 and arm64 are currently available from dockerhub, but the ppc64le isn't yet available.
I did try to build it locally and could do so successfully without any code changes and all the tests are passing as well.
Just wanted to check if there are any plans for providing a ppc64le image? I can help as needed.
What would you like to be added:
support for a ppc64le image
Why is this needed:
Thanks!
Priya

@gerrith3

Hi Team, Could you please let me know if this can be considered? I can contribute, as needed, thanks!


Mod Support: Alex's Mobs

Hey, it's me again.
I really liked your mod support for The Bumblezone so, that would be nice if you added support for Alex's Mobs mod.
I know that its gonna be hard for u bc because this mod adds 20 more food items.
Here's the list of food items that this mod adds:
• Maggot;
• Banana;
• Lobser Tail Raw/Cooked;
• Sopa De Macaco (Don't question it);
• Moose Ribs Raw/Cooked;
• Fish Oil;
• Shrimp-Fired Rice;
• Boiled Emu Egg;
• Kangoroo Meat Raw/Cooked;
• Kangoroo Burger;
• Gongulidia;
• Cosmic Cod;
• Rainbow Jelly;
• Catfish Raw/Cooked;
• Flying Fish (Just raw fish, no cooked form);
• Mosquito Repellent Stew.

oke


Allow Nullable Currency/Number Values

Very early testing out this package. Thanks for putting it together. Noticed the error is thrown from the code below when number or currency values are undefined/null (not sure how airtable defines a missing value).
With my use case, I have a lot of these number/currency fields and often they will have undefined values, so this is a pretty significant assumption to enforce non-nullable number values.
https://github.com/domdomegg/airtable-ts/blob/ac8baed4b3119dc8da1bdb24ab5752922212f46c/src/mapping/fieldMappers.ts#L237

In your schema, try setting the type of your number of currency field that is sometimes empty to number | null (rather than number. Does this fix it?

Going to +1 this, I think this is super important as well. Manually changing all fields of the autogenerated schema defeats the purpose of this project. While strong typing of databases is important, we have to accept that realistically databases themselves will likely not be perfect. At the least, I would hope a config option would be considered, I'd be happy to make a PR if you want.

Manually changing all fields of the autogenerated schema defeats the purpose of this project [...] I would hope a config option would be considered, I'd be happy to make a PR if you want.

@adammakesthingsdev This makes sense! I'd be happy to accept a PR to airtable-ts-codegen to add an option (can be enabled by default) to allow nullable values in columns!

Thanks for the response. I ended up making a fork with that change exactly, plus a few more (toyed with requiring type for single select, gave up on that one). I'll make a PR for that when I have time.
Another thing I'd like to see is better schema naming - for example, I have a table called "Addresses". Dealing with each "Addresse" is mildly annoying - maybe an option to ask what each should be called when the script is ran? No idea if it's possible to scrape that from the metadata api ("What should each record be called?").
Cheers!
Adam

Another thing I'd like to see is better schema naming - for example, I have a table called "Addresses". Dealing with each "Addresse" is mildly annoying - maybe an option to ask what each should be called when the script is ran? No idea if it's possible to scrape that from the metadata api ("What should each record be called?").

In airtable-ts-codegen, index.ts:52 is probably where you want to look. We could make the logic for autoconverting things into the singular better (either adding some basic logic, or using a library like pluralize).
If that doesn't suit your usecase, we could add config here - although I'd prefer to avoid adding config options like this where possible as it does add complexity.


Add progress tracking to the top of Getting Started pages

Currently, progress in the Getting Started flow is tracked in the left-hand nav. We would like to understand if making a user's progress more visually prevalent will help decrease the drop off rate. By doing a better job of communicating progress to a user we can provide them with a better sense of what is next.
This change does clash with https://github.com/pulumi/docs/issues/3226 so we will first need to determine if combining the first few steps is effective.

we redesigned this to be on one page, so closing


[ENHANCEMENT] Enhanced public API for detecting and loading languages

In order to support languages reasonably in RobotCode (and other tools), it would be nice if we could talk about the Language API again.

To give the user a good error message which language or custom language was not loaded or found, it should be possible to load individual languages and import custom language files.

In the current implementation I can either create the Languages class in the hope that it works, in case of error I can not easily filter out the language that does not work.
add_language can't load user defined language files

There should be a public API that returns all available languages.

already exists, is just not public

The process of loading custom language files should be separated from loading the real language.

Before loading the real languages, the custom language files should be loaded, only then you can load the language
I think this should also be done with the command line parameters, there should be 2 arguments, one for loading the custom language files and the current one for the real language

it should be possible to create a Languages instance that does not insert English and the deprecated single forms of the headers automatically

I currently have to filter it out again if I want to show only the specified languages e.g. in the completion.

Let's discuss ;-)

I can make a proposal, but not before the end of the week...

Could you give examples of what you'd like to do and how you'd like to use these APIs? It's kind of hard to understand this otherwise. If there's something simple, we can still get it done but anything bigger needs to wait for 6.1. I definitely want rc 2 out still this week so that we get the final release out at some point as well.

I would like to get a list of all available languages to show them in autocompletion
given that I have two settings, one with a list of custom language files and a list of languages to be supported, then I want to load these entries individually to filter out invalid languages and tell the user that they are invalid, but still load the valid ones.

To make sure that the custom languages can be instantiated, you have to make sure that the custom language files are already loaded. If the user specifies them in the wrong order in the current implementation, there will be an error.

To make sure that the custom languages can be instantiated, you have to make sure that the custom language files are already loaded. If the user specifies them in the wrong order in the current implementation, there will be an error.

I was hoping you could give concrete code examples using new/enhanced APIs so that I could implement them. It seems you already started implementation (c7d4bb9611430853856dedf6222ca05c4e605808) and just providing a PR obviously works as well. New APIs should get unit tests to make sure we don't accidentally break them in the future. When do you have time to continue with this? I'd hope we get rc 2 out latest on Monday.

Just got back from RoboConDE and the imbus QS-Day.
I thought the changes speak for themselves. i didn't actually change anything, just changed the visibility of the methods and made them static and introduced a new parameter.
But you are right, if it is a public API there should be tests for it. I will add some unittests this weekend.

Few things to fix and enhance in the code:

Static methods cannot accept self.
Usages of the renamed methods haven't been updated. Tests will obviously catch this and the above issue.
get_available_languages and import_languages should get docstrings now that they are part of the public API. Especially the latter would need it because its name isn't too clear. Perhaps it should be renamed to import_language_module to make it more explicit. Also argument name could possibly be better than the current lang.

I already fixed the self and the usages, because failing tests ;-) if you go to the Files Changed tab you will see.
The other things I will add/change.
One point I did not implemented yet: I think there should be 2 commandline parameters regarding the language, one for loading the custom language files and one for enabling the language. The other way is, at using the --language command line parameter, we must add a hint to the documentation, that if the user want's to use a custom language module, the module must be given before the language.
What do you think?

I only looked at the commit that referred this issue and thus didn't see additional changes.
I don't think another cli option is needed. If you have a custom language in lang.py, you can simply use --language lang.py and it will be loaded and enabled.

The PR implementing this is #4496.

add some docs and tests for the public API's. Can you review it?

Reviewed.

I labeled this issue as a task to not get it listed in release notes. Localization is already covered there. Should probably enhance the tooling we use for generating release notes template to make it possible to use a label like no release notes instead of task for that purpose.

We've spent some time tidying the PR, but now that I look at this again from a bit higher level I got a feeling the PR adds unnecessary and non-generic public methods to the Languages class. The problem with them is that we most likely need to enhance Languages in the future and then need to maintain all such methods.
I think there are better ways to support what the original description asks for. Following comments apply to matching points in the description.

We can easily enhance add_language so that it works also with modules. Then you can initialize Languages without any languages, add languages one-by-one, and report errors as needed.

You can already get all loaded languages like list(Languages(...)) and all available languages like Language.__subclasses__(). You may need to add some code to turn what you get from these into a dict or other structure, but I don't see why the caller couldn't do that.
The problem with exposing the current _get_available_languages publicly is that we needed to decide what it should return. It currently returns a dict with normalized language codes and names as keys, but I don't think that would be convenient in a public API. Trying to access languages with keys like Fi or pt-br wouldn't work, you needed to normalize keys as well and that needed to be documented.

This is not correct. Using --language lang.py or Language(['lang.py']) will both import the language module and activate languages it contains.
Notice that the proposed import_language_module actually only imports the module, doesn't activate languages it has. That's really strange because it means that if you do langs = Languages(...); langs.import_language_module('lang.py'), it doesn't change the state of langs but it can affect Languages instances created later. To update langs, you needed to call langs.add_language() for all languages in the language module which isn't convenient at all. Enhancing add_language to support language modules, like discussed in 1., makes this much easier and doesn't require adding new public method.

Making it possible to not active English by default is a good idea. I think the argument should be add_english instead of add_default, though.

Another enhancement we could do is changing Language.code/name propertys so that they work also with classes. That makes usages like this possible:
for lang in Languge.__subclasses__():
    if lang.code == ... or lang.name == ...:
        ...

ok, now I'm a little bit confused where we should discuss, here or in the PR ;-)

I wanted to add that higher level comment here. Discussion about the PR implementation belongs to the PR. It could be best if we used Slack, though. :smile:

Extending add_language so that also language modules can be loaded was also my first thought.

On RobotCode side I have to create a new language instance every time I want to check if a language or a language module exists and can be loaded. This can happen very often, in the simplest case when the user changes the settings, in principle every time the user changes the file, because it always has to be parsed and analyzed again. It is enough to determine the languages to create them later if needed.
With code completion (I type `language: ' and the code completion shows all possible languages) I only need the names and the codes of the language, but no complete instances of the languages.
It costs time and memory to instantiate the classes each time.
In addition, I would like to load the language modules in a new process, so I don't pollute the language server instance. Once a module is loaded, you can't get it out again. Topic language bleeding ;-) Transferring whole instances or just the class names is a difference.

i think there should be a unified way to get all possible languages and also their names and codes. This is not given if I only use the Language.subclasses, because then I also have to rebuild the algorithm, how RobotFramework determines the names and codes. Whether they are normalized or not. But you can specify that, you can also return the robot.utils.normalizing.NormalizedDict.

I just noticed that: subclasses returns only the direct subclasses, if I want to override e.g. the BDD_prefixes for a certain language this does not work.
If on RobotFramework side the implementation is changed, I have to reprogram that too.

see 1 and:

import_language_module and get_available_languages are static methods in PR, in current implementation they are not, but could be, since they do not use self. You could also move them from class to global namespace. Then it is no longer possible to call langs.import_language_module like this.

Just to clarify, I want to stay as close as possible to RobotFramework with RobotCode and like to reuse as much as possible and dislike reprogramming code. Preferably with a good API!

I don't understand why any of these points would require adding import_language_module or get_available_languages. It would be easier to understand if you showed concrete code where enhancing add_language and making English optional doesn't work. With the earlier example you showed in the comments of the PR, that approach made the code a lot simpler.
I understand you want as much of the logic to be on Robot side as possible, but that adds more maintenance burden to Robot which is not what I want. I want simple APIs that provide needed functionality and that we can preserve in the future. This is especially important with these new language APIs because they will certainly need to be enhanced in the future anyway. More convenience can be added to these APIs when they are otherwise stable.

Most of the functionality was added in PR #4496 by @d-biehl. My commit above did these additional changes:

More doc strings.
Change exception used by Languages.add_language on error to match exception used when initializing Languages.
Make Language.code/name propertys accessible also from class.  This required implementing new @classproperty decorator.

I consider this issue now ready, but I leave it open to give Daniel some time to review my changes and see how everything works in practice with RobotCode. If there are small and/or critical enhancements, then can still be considered but anything bigger and less urgent can wait for RF 6.1.

Did you @d-biehl have time to look at the latest changes? The commit above added support to use add_language with Language instances and what the earlier commit did was explained in my previous comment.
If there's something still to be changed, let me now ASAP. I just got RF 6.0 rc 2 release notes ready and plan to create the release candidate very soon.

It's OK. Everything fits.

Awesome! Looking forward for the new RobotCode release with enhancements related to this and other recent features.


Role Based Embedding in Graphs

❓ Questions & Help
I want to discover Role Based Similar Nodes, when Two Communities that come together. I also have a lot of Edge Feature(which are not just scalar weights). I thought of treating the Nodes Identification between communities as a Link Prediction  Task. So basically seeing all the features into account. Is there any efficient way of doing this? I also want to learn an inductive representation. I want to use this as a Feature extractor.

I'm not sure I fully understand your task. It looks like you have two graphs and you want to match similar nodes between those two graphs. Is that correct?


GEODE-8684: Setting a session's maxInactiveInterval does not work when the commit valve is disabled

Co-Authored-by: Jens Deppe<EMAIL_ADDRESS>Co-Authored-by: Sarah Abbey<EMAIL_ADDRESS>(cherry picked from commit ba8f9015530af10c3e9d1df1e73524bdc6c8a3cc)

Closed in favor of a large PR with all the commits applied in the same order they were made originally.


lcms2: 2.7 -> 2.8

Motivation for this change
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

is our lcms2 vulnerable, or is this just an upgrade?

The latter one.