DCan we make all our libs target net6? Seems sometimes the CLI can't properly figure out which target to use and ends up using netstandard2.1 on net6....
Pcan you send me the error
Por whatever evidence supporting this
TI had a case where it wouldn’t link at all when directly including Silk.NET from .Net 6, had to fall back to 5
Pthis is to be expected
Pnuget still downloads .net 6 dependencies where possible
Dno error, just it seems that the net6 target isn't really considered compatible with the net5 target
Pplease send evidence
Dduring a net6 build
TWhat? You can’t include .net 5 projects in .Net 6?
Dit just builds random versions of libs
Pno you can
Pit's expected to fall back to 5 though
Pwhere we don't have a 6 tfm
Pcan you send me a zip of the build output
TSo why can’t I include Silk.Net in .Net 6 project directly
Dit doesn't build so no 
Pyou tell me ¯\_(ツ)_/¯
Pi don't really have a lot of info here
Padding a net6 tfm won't help here because... silk.net.core already has one
DI disabled that for testing, forgot to mention 
Pnot a fan of the package size increases but fine go ahead
DI mean in some cases it seems we rely on the tool to figure out that it should figure out
net6 -> netstandard2.1 -> net5 -> net6
net6 -> netstandard2.1 -> net5 -> net6
Pyeah, nuget is meant to download the most appropriate version of a package on a package-by-package basis
Pso if a NS20-only package referenced a NS20 package that also had a net6 TFM and the consumer is net6, it will download the net6 version of the package
TFFS VS!!!! It's started working now 
Phaha
P(but also if you're implying you were doing
PackageReference Include="Silk.NET", please don't)TPah ok cool
Pinteresting setup 
TI just set
When I build against a local repo
When I build against a local repo
Palso i know ProjectReferences do not necessarily behave this way
Pso this could be the cause of the issues you're both seeing
TOoo interesting
TDoesn't surprise me, I've started to think the MSBuild team is where they send failed ASP.NET devs
Dthat could be it yeah
TNo to be fair, ASP is worse
TBut you gotta wonder who was like "lets make MSBUILD use json instead"...
Doh god, building for WASM generates a {GUID}.gz file on each build
DI had hundreds
Dmaybe that was the issue
TI can also set using command line of course
Pbasically consider
A (net6) -> B (net5;ns21) -> C (ns21;net6)
how MSBuild will do it is go:
"hey B, i'm referencing you using net5. get me your dependencies"
"hey C, i'm referencing you usign ns21. get me your dependencies"
A (net6) -> B (net5;ns21) -> C (ns21;net6)
how MSBuild will do it is go:
"hey B, i'm referencing you using net5. get me your dependencies"
"hey C, i'm referencing you usign ns21. get me your dependencies"
Pand all of that is combined into one bag
PC will never know that A targets net6
Ponly that B targets net5 and thus should use ns21
Dyeah that is what I was trying to get at here
Pwhereas all NuGet sees is
"i'm net6, get me Silk.NET.Core" - the restoration happens at the last consumer
"i'm net6, get me Silk.NET.Core" - the restoration happens at the last consumer
Ddidn't know that was only ProjectReferences
