I did not, but if MS tools give you the same results as EBuild now does after my fix/change, then thats the desired outcome, no?
IU’ll research more tomorrow/next week, but it seems that maybe instead of getting the file from ‘ref’, it shut fall back to what’s in Microsoft.NET.Build.Extension. no idea. This hole thing is so f#$%ing messed up, it’s not even funny anymore.
Yes that is the desired outcome I just dont want refs ending up in the bin folder
Oddly, Microsoft.NET.Build.Extensions doesn’t have System.Buffers.dll though… so if I fix this to grab stuff from Builds Extensions when building for a too-low SDK, you still won’t be getting System.Buffers. from there 
Wondering: if the one you’re getting noe from ref is not the right version (can you conform whether it is? does it work?), can you tell where the one that VC# gives you comes from?
What I do find is
…/dotnet/sdk/5.0.100-preview.2.20176.6/Sdks/Microsoft.NET.Sdk/tools/net472/System.Buffers.dll
but it seems a weird place to grab it from, being in a folder named “tools” (and it would only apply to .NET Core 5.0, and .NET 4.7.2).
Maybe the correct thing to do is to reference the ref version from net4, but then still copy the lib version from netstandard?
What f***ing mess…
Another concern is: both Microsoft.NET.Build.Extensions and the above tools path are part of a specific version of the .NET Core SDK. Building a .NET project does not involve .NET Core all att (and shouldn’t even have to have .NET Core installed). So I cant believe taking anything out of the .NET Core install folder when building a non-Core project is “correct”.
I would agree
I created a .net 4.7 console app and did a file compare
FC: …\PACKAGES\SYSTEM.BUFFERS.4.5.1\LIB\NETSTANDARD2.0\System.Buffers.dll longer than SYSTEM.BUFFERS.DLL
so they arent the same
but
Comparing files System.Buffers.dll and …\PACKAGES\SYSTEM.BUFFERS.4.5.1\LIB\NET461\SYSTEM.BUFFERS.DLL
FC: no differences encountered
Yes 
I think its like this If you imagine there are 3 flavors (core, standard and .net ), you only copy local from a lib folder of that flavor.
I dont think a standard lib folder is ever used at runtime for either core or .net ?
At compile time use ref if present, otherwise use lib ?
Hmm, by do you have a lib for System.Buffers? I thought the whole reason this is happenjfgn is because its ONLY in ref, for net!?
I have this:
Only “ref” has a net subfolder at all. (but also, i’m on 4.5.0, nor 4.5.1).If you have 4.5.1 and that one has a lib folder, the whole issue should be moot? I’ll retest against 4.5.1 in a sec.
Did I mention: what a mess?
Oddly I get:
System.Buffers:4.5.0]
as reference, hard-capped to not use a newer one. Why do you get 4.5.1?
If I add a hard reference to System.Buffers:4.5.1, I get these files:
D: System.Buffers.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.buffers/4.5.1/lib/net461/System.Buffers.dll)
D: System.Buffers.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.buffers/4.5.1/lib/net461/System.Buffers.xml)
so all is working fine then. I’ll revert my fix from two days ago.
The question is, should the dependent ref be capped as 4.5.0] or not. IIRC we fixed that for a reason…
March 2, 3d9e3d8fe “NuGet: make indirect dependencies restricted to "]"”
Yes sorry I got myself into a mess
4.5.1 has ref for net45 and lib for 461
4.5.0 has ref for net45 but no lib
4.4.0 only has standard lib and ref
No references should always use the lowest acceptable otherwise I start requiring lots of binding redirects and it turns into a nightmare.
I’ll perform the test with System.Buffers 4.4.0 and do comparisons
ok, lowest would be 4.5.0, so its behaving correctly. and 4.5.0 has no lib, so you not getting the dll copied is also correct? 
Why do you get a dll from 4.5.1, from VC#?
I picked the latest version because I thought it wouldn’t make a different but that was wrong. I’ll go back and test with the other 2 versions
For both 4.4.0 and 4.5.0 the lib\netstandard2.0 is what appears in the bin directory. Being standard it pulls in more libraries.
I thought we did that before ?
Ok, so even though there’s a netXX folder, it will (i assume) reference the file fron ref/etXX, but copy it from lib/netstandardXX?
The inmates truly are running the asylum, now.
I’ll see if i can get that hooked up later today or Monday.
Insane.
In 4.5.0 for Ref a net45 and a standard2.0. I dont know what its using when it compiles but it deployed the netstandard20 from lib
Can you see if a highest-log-level build gives that info?
No it just mentions the lib folder
:(. 
Maybe the netXX folder is always only used when the current .NET version does not support one of the provided netstandardXX versions, and otherwise netstandard takes precedence?
If only any of this was documented, like, at all…
If I change it to favor a matching .NET Standard version over a more concrete (.NET, .NET Core), I get this output:
D: Echoes.dll (/Users/mh/Code/Elements/Bin/References/Echoes/NET/Echoes.dll)
D: Echoes.dll.mdb (/Users/mh/Code/Elements/Bin/References/Echoes/NET/Echoes.dll.mdb)
D: Echoes.pdb (/Users/mh/Code/Elements/Bin/References/Echoes/NET/Echoes.pdb)
D: Elements.dll (/Users/mh/Code/Elements/Bin/References/Echoes/NET/Elements.dll)
D: Elements.dll.mdb (/Users/mh/Code/Elements/Bin/References/Echoes/NET/Elements.dll.mdb)
D: Elements.pdb (/Users/mh/Code/Elements/Bin/References/Echoes/NET/Elements.pdb)
D: JsonNetConsoleApplication.exe (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Obj/JsonNetConsoleApplication-B3E0F985FB5B468C29CD713562A17E5482D3E6BB/Debug/Echoes/JsonNetConsoleApplication.exe)
D: JsonNetConsoleApplication.exe.mdb (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Obj/JsonNetConsoleApplication-B3E0F985FB5B468C29CD713562A17E5482D3E6BB/Debug/Echoes/JsonNetConsoleApplication.exe.mdb)
D: Microsoft.Bcl.AsyncInterfaces.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.bcl.asyncinterfaces/1.1.0/lib/netstandard2.0/Microsoft.Bcl.AsyncInterfaces.dll)
D: Microsoft.Bcl.AsyncInterfaces.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/microsoft.bcl.asyncinterfaces/1.1.0/lib/netstandard2.0/Microsoft.Bcl.AsyncInterfaces.xml)
D: System.Buffers.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.buffers/4.5.0/lib/netstandard2.0/System.Buffers.dll)
D: System.Buffers.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.buffers/4.5.0/lib/netstandard2.0/System.Buffers.xml)
D: System.Memory.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.memory/4.5.3/lib/netstandard2.0/System.Memory.dll)
D: System.Memory.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.memory/4.5.3/lib/netstandard2.0/System.Memory.xml)
D: System.Numerics.Vectors.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.numerics.vectors/4.5.0/lib/netstandard2.0/System.Numerics.Vectors.dll)
D: System.Numerics.Vectors.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.numerics.vectors/4.5.0/lib/netstandard2.0/System.Numerics.Vectors.xml)
D: System.Runtime.CompilerServices.Unsafe.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.runtime.compilerservices.unsafe/4.7.1/lib/netstandard2.0/System.Runtime.CompilerServices.Unsafe.dll)
D: System.Runtime.CompilerServices.Unsafe.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.runtime.compilerservices.unsafe/4.7.1/lib/netstandard2.0/System.Runtime.CompilerServices.Unsafe.xml)
D: System.Text.Encodings.Web.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.text.encodings.web/4.7.0/lib/netstandard2.0/System.Text.Encodings.Web.dll)
D: System.Text.Encodings.Web.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.text.encodings.web/4.7.0/lib/netstandard2.0/System.Text.Encodings.Web.xml)
D: System.Text.Json.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.text.json/4.7.1/lib/netstandard2.0/System.Text.Json.dll)
D: System.Text.Json.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.text.json/4.7.1/lib/netstandard2.0/System.Text.Json.xml)
D: System.Threading.Tasks.Extensions.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.threading.tasks.extensions/4.5.2/lib/netstandard2.0/System.Threading.Tasks.Extensions.dll)
D: System.Threading.Tasks.Extensions.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.threading.tasks.extensions/4.5.2/lib/netstandard2.0/System.Threading.Tasks.Extensions.xml)
which looks like what we want. however, I’ll lose a previous fix for “prevents .NETStandard-Library from being included projects targetting other types”; not sure if/when thats still relevant, we’ll see what breaks, there…
I’ll commit this for a 2516 build, would appreciate of you could put it thru its paces.