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.

[martincostello]

I'm getting this problem, but only when trying to run unit tests in Visual Studio that exercise code paths that render views such as described under Accessing Views in this testing documentation.

[martincostello]

Turns out the simple fix was to set <PreserveCompilationContext>true</PreserveCompilationContext> in my tests' .csproj file...

[gimlichael]

Will a fix be ready for your shipment of VS 2017 in early march?!

[eerhardt]

Will a fix be ready for your shipment of VS 2017 in early march?!

Unfortunately, no. The fix will come as part of ".NET Core 2.0", which is after VS 2017 RTMs.

[gimlichael]

Thank you @eerhardt , for the reply. When you write ".NET Core 2.0", does that mean we are forced to upgrade our projects that are co-compatible with .NET 4.6.1 and .NET Platform Standard 1.4? Because that is a no-go for me :-/

[eerhardt]

does that mean we are forced to upgrade our projects that are co-compatible with .NET 4.6.1 and .NET Platform Standard 1.4?

No, this doesn't mean you will have to upgrade to 2.0. The reason this feature comes as part of ".NET Core 2.0" is because:

1. It didn't fit time-wise into VS 2017 RTM.
2. .NET Core 2.0 will allow you to take existing IL assemblies (for example, built for net40 or net45) and run them on .NET Core. Allowing these assemblies to be referenced from disk (and not forcing them into a NuGet package) will allow you to use these assemblies easier. So it fits with the "theme" of .NET Core 2.0 - which is easier migration of code from desktop .NET Framework to .NET Core.

[gimlichael]

Thank you for the excellent news, @eerhardt. Keep up the good work 👍

[dasMulli]

Nearly everyone I talked to (mostly on slack) who wanted to "just reference an assembly" would run into type-forwarder/facade-hell without having the right packages in the graph to resolve conflicts. So I agree with @piotrpMSFT that the use of assembly references should be discouraged.
My experience has been that there is a lack of knowledge that:

• nuget.exe can generate and pack a nuspec file for a given dll using nuget.exe spec that.dll.
• Any folder can be a nuget package source, so having a solution-local folder with .nupkg files inside which is added to a NuGet.Config is enough to reference custom packages.

Maybe it is enough to just document how to make use of that to wrap dlls into local nuget packages that live in the same GIT repository and don't require to set up a nuget server/feed.

[Metamorphus]

So, is the problem fixed? I still sometimes get runtime errors like: "System.IO.FileNotFoundException: Could not load file or assembly '...'. The system cannot find the file specified" for the DLLs that I reference directly from the disk.

[eerhardt]

@Metamorphus - yes this problem is fixed. If you are having problems, please open a new issue with your .csproj and which version of the .NET Core SDK you are using (by copying the output of dotnet --info). And any other information you think would help diagnosing the problem.

[eerhardt]

Also, please set COREHOST_TRACE=1, run your app, and attach the output to the bug as well.

[los93sol]

Please re-open this as dotnet pack does not work

[eerhardt]

dotnet pack issues are tracked in https://github.com/NuGet/Home/.

@rohit21agrawal - is there an existing issue for this scenario? or should @los93sol open a new one in NuGet/Home?

[rohit21agrawal]

what about dotnet pack does not work? could you please elaborate?