Scenario: enable references to any assembly on disk

[eerhardt]

.NET Core projects never supported referencing an assembly sitting on disk. MSBuild support this more naturally.

To enable this we need to ensure:

• The assembly is copied to the build and publish folders.
• The assembly is added to the .deps.json file.
• How does "dotnet pack" handle this scenario?

[Petermarcu]

We should get this fixed when we are ready to support .NET Standard 2.0. People will want to reference lots of libraries that shipped well before NuGet was a thing and we should get out of their way :)

[JohnGalt1717]

It needs to happen sooner than that. People already want to reference .net standard 1.3 dlls in .net core web apps. The use case is an internal library of utilities or a client library for a rest service that is used in multiple client libraries and websites.

You don't want the actual projects cross loaded across repos because that causes continuous deploy issues. Instead you'll use a libs folder in each project and reference them.

(And this is still broken in the latest VS.net 2017 RC with csproj in all but the trivial case. As soon as there are any nuget dependencies like json.net it fails)

[JohnGalt1717]

This is still broken in VS.NET 2017 RC3 FYI.

[NTaylorMullen]

This scenario breaks MVC applications. Aka, if a user attempts to utilize a referenced assembly from disk in their View the view fails to compile because the deps.json doesn't have an entry for the referenced assembly. Looks like there's a decent amount of feedback from the community around this: https://developercommunity.visualstudio.com/content/problem/17274/razor.html

[TheRealPiotrP]

While I do appreciate the need for AssemblyReferences for backwards compatibility, I hope we're able to do something that discourages usage moving forward. It's really hard to figure out what flavor of a given assembly to use in a lot of cases [consider multiple RIDs, multiple TFMs] and I'm very nervous that folks will get really frustrated when trying to carry over their already-well-known usage patterns.

[Petermarcu]

Its not just backwards compatibility. We can't expect that everything is going to be put into a nuget package to be shared. For pure IL .NET Standard libraries, there shouldn't be any RID/TFM concerns. For people that just want to ship a flat folder of assemblies in an sdk, they should be able to tell people to reference them.