.net Core App 1.1 doesn't resolve file linked .net standard libs

[BoasE]

I had a project in .net core 1.0 which is refrencen a standard 1.4 library. this works fine.

No i tried to switch to .net core 1.1 an I get AssemblyNotFoundExceptions.

To isolate the problem I tested the same thing by creating a new project with the released VS2017

Fir this I created a solution with 2 projects. A .net core 1.1 host (console) and a .net standard 1.4 class library.

I changed the standard lib to 1.6

Then I add the reference to the client as project refrence in the core console project.

Then at runtime i get the exception that the assembly of the client is not found. And this at the first place i use a type of the .net standard assembly so my test console looks as trivial as this:

 class Program
    {
        static void Main(string[] args)
        {
            var foo = new Class1();

When I switch the host project to .net core 1.0 everything is working fine.

I published a sample here: https://github.com/Gentlehag/coreapp11bug

Is this expected behavior ?

Which .net standard library version should work with .net core 1.1 ?

PS: I also posted here:
http://stackoverflow.com/questions/42677625/net-core-app-1-1-doesnt-resolve-external-net-standard-libs

[gkhanna79]

@Gentlehag If you set Microsoft.NETCore.DotNetHostPolicy.SetAppPaths to true in your runtimeconfig.json, then does the application work?

[eerhardt]

I'm investigating.

[eerhardt]

@Gentlehag - which version of the SDK are you using? I did the following:

$git clone https://github.com/Gentlehag/coreapp11bug.git
$dotnet restore coreapp11bug\ConsoleApp1
$dotnet run -p coreapp11bug\ConsoleApp1\ConsoleApp1.csproj
Hello World!

I tried with both

dotnet --info
.NET Command Line Tools (1.0.0)

Product Information:
 Version:            1.0.0
 Commit SHA-1 hash:  e53429feb4

and

.NET Command Line Tools (2.0.0-preview1-005383)

Product Information:
 Version:            2.0.0-preview1-005383
 Commit SHA-1 hash:  22816d7958

And they both run fine (prints "Hello World!").

UPDATE: I also opened the .sln in VS 2017 RTM, and F5'd. It also printed "Hello World!".

[eerhardt]

Looking into this a bit deeper (which I was able to do since you commited the bin and obj directories to git 😀), the runtime error is caused by the deps.json file not listing Service.dll in it.

The reason it doesn't show up in this deps.json file is because it is not listed as a library in the project.assets.json file, which NuGet writes.

@emgarten @rohit21agrawal - any ideas why this would be the case? My VS 2017 RTM version lists the P2P as a library in the project.assets.json.

@Gentlehag - which version of VS are you using? Can you do "Help -> About" and "Copy Info"?

[BoasE]

I made some further tests. it seems to work "sometimes" .
It has the biggest change to fail when i make the reference to a fail not to a project.

You can try to remove the refernce to the service which is currently a project reference and then set the reference to the .net standard assembly. this is the way i can reproduce it now on all machines

my Visual studio version is :

Microsoft Visual Studio Professional 2017
Version 15.0.26228.4 D15RTWSVC
Microsoft .NET Framework
Version 4.6.01586

Installed Version: Professional

Visual Basic 2017 00369-60000-00001-AA208
Microsoft Visual Basic 2017

Visual C# 2017 00369-60000-00001-AA208
Microsoft Visual C# 2017

Visual C++ 2017 00369-60000-00001-AA208
Microsoft Visual C++ 2017

Application Insights Tools for Visual Studio Package 8.6.00209.10
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2017 15.0.30223.0
ASP.NET and Web Tools 2017

ASP.NET Web Frameworks and Tools 2017 5.2.50127.0
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0 15.0.30209.0
Azure App Service Tools v3.0.0

Azure Data Lake Node 1.0
This package contains the Data Lake integration nodes for Server Explorer.

Azure Data Lake Tools for Visual Studio 2.2.5000.0
Microsoft Azure Data Lake Tools for Visual Studio

Command Bus, Event Stream and Async Manager Merq
Provides ICommandBus, IEventStream and IAsyncManager MEF services for loosely coupled Visual Studio extension components communication and integration.

Common Azure Tools 1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Fabric.DiagnosticEvents 1.0
Fabric Diagnostic Events

GitHub.VisualStudio 2.1.1.4
A Visual Studio Extension that brings the GitHub Flow into Visual Studio.

JavaScript Language Service 2.0
JavaScript Language Service

JetBrains ReSharper Ultimate 2016.3.2 Build 107.0.20170126.120331
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2017 JetBrains, Inc.

KofePackagePackage Extension 1.0
KofePackagePackage Visual Studio Extension Detailed Info

MenuCommands Extension 1.0
MenuCommands Visual Studio Extension Detailed Info

Microsoft Azure Hive Query Language Service 2.2.5000.0
Language service for Hive query

Microsoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 2017 - v2.9.50131.1

Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio Mono.Debugging.VisualStudio
Support for debugging Mono processes with Visual Studio.

NCrunch
Continuous Testing Tool for .NET
Copyright © 2010-2016 Remco Software Ltd

NuGet Package Manager 4.0.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

SQL Server Data Tools 15.1.61702.140
Microsoft SQL Server Data Tools

ToolWindowHostedEditor 1.0
Hosting json editor into a tool window

TypeScript 2.1.5.0
TypeScript tools for Visual Studio

Xamarin 4.3.0.459 (7c3dcf2)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin.Android 7.1.0.13 (72366f7)
Visual Studio extension to enable development for Xamarin.Android.

Xamarin.iOS 10.4.0.33 (d93ae7e)
Visual Studio extension to enable development for Xamarin.iOS.

[BoasE]

Just recognized that it works when i put the dependency ina nuget package. I uipdated the repo with a second console project which uses the nuget package and which is always working

Ok Summarized: It failes 100% in my tests when both are true

• starting from within vs 2017 with F5
• the reference is set to a .net standard file ( not project reference)

And it always wroks when:

• i use the dotnet command line to build and run. regardless wether i have file or project references
  -- OR --
• When I put the .netstandard lib in a nuget package

So shortcut to reproduce the bug:
Create .net core 1.1 console app and file reference a .net standard (1.4 /1.6) assembly

[gkhanna79]

@eerhardt Is there a more appropriate repo to move this issue to for the right folks to drive it further?

[eerhardt]

@eerhardt Is there a more appropriate repo to move this issue to for the right folks to drive it further?

At this point, I'd say https://github.com/nuget/home. NuGet isn't writing the correct information into the project.assets.json file.

[gkhanna79]

Closing the issue in favor of NuGet/Home#4772

[emgarten]

Based on this it sounds like a direct reference issue:

So shortcut to reproduce the bug:
Create .net core 1.1 console app and file reference a .net standard (1.4 /1.6) assembly

Using for ConsoleApp1:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="..\Service\bin\Debug\netstandard1.6\Service.dll" />
  </ItemGroup>
</Project>

I see with dotnet run:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Service, Version=1.0.0.0, Culture
=neutral, PublicKeyToken=null'. The system cannot find the file specified.
   at ConsoleApp1.Program.Main(String[] args)

On the project.assets.json differences:

At this point, I'd say https://github.com/nuget/home. NuGet isn't writing the correct information into the project.assets.json file.

@Gentlehag can you provide more details on why the project.assets.json files checked into the repro have different results than what I see locally when running? It looks like Service.csproj was missing when restore was run. When trying from both VS and dotnet I see an entry for Service.csproj in the output.

[BoasE]

I'm not sure where this offset comes from. But i think thats another issue. The easiest way to reproduce the bug is with a single .net core solution which only has a file reference to an existing .net standard library dll.

So for this way:

• open the Existing ConsoleApp1 form the sample repo
• remove the reference to the service .
• Also remove the service project from the solution
• re add it to the precompibled service.dll
• Compile and Run (F5)

It is also reproduceable when you fo:

• in vs2017 Create a new .net core app in a fresh new solution
• Add a file reference to the precompile .net standard library
• Compile and Run (f5)

In this case the exception occurs without missing the project.
I pushed it in the example repo in : https://github.com/Gentlehag/coreapp11bug/tree/master/Example3/FileReferenceExample

this one has only a single project and a file refrence to the preexisting .net standard library assembly.

[BoasE]

to avoid misconceptions i made a short screencast.
in this i create a plain new c ore app and reference the service dll which i comitted in the sample repo (see above)

https://www.youtube.com/watch?v=08uMd5wSyXc

to demonstrate it is only realted to core 1.1 you can see that it fails at first and after changing to core 1.0 its working.

[eerhardt]

Ok, this new information makes sense now.

Since this is a reference to an assembly on disk, that's why NuGet wasn't writing the information into the project.assets.json file, which is correct.

@Gentlehag, the .NET Core SDK v1.0 (Visual Studio 2017 RTM) doesn't support direct references to assemblies on disk. Basically the options that will give you success are either <PackageReference> or <ProjectReference>.

We did enable this scenario for 2.0 though. See dotnet/sdk#120, but those bits have not been released yet. They will be when .NET Core 2.0 comes out later this year.

[BoasE]

Well thats not exactly corret in .net core 1.0 it works. it only doesn't work in 1.1. @eerhardt is that expected ?

Also it would be nice that the IDE wouldn't allow a feature that the clr is not supporting :-(

[eerhardt]

Well thats not exactly corret in .net core 1.0 it works. it only doesn't work in 1.1. @eerhardt is that expected ?

You are right. @gkhanna79 - is this expected? The 1.1 host has become more restrictive and won't load assemblies that aren't in the deps.json file? But the 1.0 host will happily load them?

Also it would be nice that the IDE wouldn't allow a feature that the clr is not supporting :-(

Agreed. This feature is coming in for 2.0, so it may not be worth changing the IDE now. /cc @davkean

[BoasE]

ok. Thx for the detailed informations

[gkhanna79]

Yes, the host in 1.0.x had a bug that was fixed in 1.1.0 to only honor closure from deps.json.

[Jonathan34]

same issue here, cannot use a .net standard 1.6 with .net core 1.1.
i am trying to create a nuget package following this issue.

[WallaceKelly]

Steps to repro using CLI:

1. mkdir lib
2. cd lib
3. dotnet new library
4. dotnet restore
5. dotnet build
6. cd ..
7. mkdir app
8. cd app
9. dotnet new console
10. Edit app.csproj, adding the following:

<ItemGroup>
   <Reference Include="..\lib\bin\Debug\netstandard1.4\lib.dll" />
</ItemGroup>

11. Edit Program.cs, adding the following to the main method:

new lib.Class1();

12. dotnet restore
13. dotnet build
14. dotnet run
15. See the System.IO.FileNotFoundException.

My environment
Windows 10
Microsoft .NET Core Shared Framework Host
Version : 1.1.0
Build : 928f77c4bc3f49d892459992fb6e1d5542cb5e86

[Jonathan34]

use dotnet pack to create a nuget package (or from vs 2017, right click the project and select pack option)

[gkhanna79]

@WallaceKelly Can you please move your repro steps into an issue in the CLI repo where it is best discussed?

[WallaceKelly]

@gkhanna79 I (mistakenly?) thought it was more of a runtime issue, since it seems to compile fine and fails at runtime.

Regardless, I found the duplicate issue at https://github.com/dotnet/cli/issues/5847, which says it will be supported on 2.0.

[xplicit]

Why is this closed? The referencing external dlls worked pretty well since dotnet 1.0.0 to "1.0.0-preview2-1-003177" SDK and now it's broken with released SDK 1.0.1/1.0.2. We are moving from json to csproj format and this bug does not allow to run executables at all. How to workaround it? I tried several ways and no one helps.
Is it possible to manually edit assets and *.deps.json files after dotnet restore and dotnet build commands to make final executable not crashing with "File not found" message? If yes, what need to be changed? We will write build script to update these files if dotnet can't do this.

[davidfowl]

@eerhardt Did we ever close on the referencing assemblies discussion? Is there an issue for it?

[eerhardt]

Why is this closed?

Because there is no more work to do regarding this issue. netcoreapp1.0 had a bug that would load assemblies in the app's directory, even if they weren't listed in the .deps.json file. This bug was fixed with netcoreapp1.1.

In the .NET Core SDK 1.0, there wasn't support for straight <Reference>s to assemblies on disk. We supported <ProjectReference> and <PackageReference>.

In .NET Core SDK 2.0 (which hasn't been released yet), we added support for straight <Reference>s to assemblies on disk. See dotnet/sdk#120.

To use this, you will need to either:

1. Move to a daily build of the .NET Core SDK 2.0: https://github.com/dotnet/cli#installers-and-binaries
2. Alternatively, if you want to implement this functionality yourself, you can re-write the .deps.json file to include these references. See Allow .NET Core 2.0 projects to reference assemblies on disk sdk#876 for how we implemented it. Basically, you'll want to take all @(ReferencePath) metadata items meeting this condition: https://github.com/dotnet/sdk/pull/876/files#diff-5b160d7a1168edb7ef7cc818d8a70e75R53 and add them to the .deps.json file.

My recommendation would be to either stay on netcoreapp1.0, or move to .NET Core SDK 2.0 daily builds.

[xplicit]

@eerhardt we used assembly wrapping into project with netcoreapp1.0 and netcoreapp1.1 and it worked without issues with project.json files. You can look at our old projects
https://github.com/ServiceStack/ServiceStack/blob/netcore/src/ServiceStack.Text/project.json - this is referenced assembly
https://github.com/ServiceStack/ServiceStack/blob/netcore/tests/ServiceStack.WebHost.Endpoints.Tests/project.json - this is main netcoreapp1.1 executable

Then we decided to move to *.csproj and now nor assembly wrapping nor referencing assembly from csproj does not work. I don't know has it done by the some bug resolution or something else, but I think it's quite strange, that functionality which worked with project.json does not work with *.csproj and when I run dotnet build -v d and see that csc.exe command line has /reference:myRefAssembly.dll but compiler says that the types which are located in that assembly could not be found (Are you missing an assembly reference? error).

[eerhardt]

What does your .csprojs look like?

[xplicit]

Wrapper project does not contain any source files, only assembly reference.

TestAsm.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
    <NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="TestAsm.dll" />
  </ItemGroup>

</Project>

Main project is typical netcoreapp1.1 project which has ProjectReference

  <ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp1.1' ">
    <ProjectReference Include="..\TestAsm\TestAsm.csproj" />
  </ItemGroup>

When I run dotnet build I see that csc.exe has got /reference:/path/to/TestAsm.dll in command line but compiler can't get types are defined in that assembly.

If you interested I can create solution on github which shows the reference assembly issue.

[eerhardt]

The feature you are using in project.json to use a project.json to wrap a pre-built assembly (https://github.com/ServiceStack/ServiceStack/blob/netcore/src/ServiceStack.Text/project.json#L24-L30) is not supported in dotnet migrate. I would have thought it would have given you an error.

But what you are doing in your .csproj is not the equivalent of what was happening in project.json. To do the equivalent in a .csproj, you would need to fake out the build system to tell it that THIS .csproj produces a pre-built assembly. I can imagine 2 ways of doing that:

1. Override CoreCompile and other Build targets to do nothing. Then set all the properties/items that normally would get set during build to your pre-built assembly.
2. No import anything in your .csproj (no Common targets) and then stub out all the required targets for P2P references, which are documented here: https://github.com/Microsoft/msbuild/blob/master/documentation/ProjectReference-Protocol.md

But I think that would be way too much work. So I would suggest either:

1. using the real .csproj for ServiceStack.Text.dll and not having this "wrapper" project at all.
2. Put ServiceStack.Text.dll in a NuGet package and use a <PackageReference> to it. You can still check the .nupkg in to your repo and point your nuget.config to a repo-local path.

@livarcocc - FYI on the take-back from project.json.

[xplicit]

nuget pack does not work, because current structure is:

  ServiceStack.Text - real project
  ServiceStack.Text.Tests --> ServiceStack.Text 
                          --> ServiceStack.dll --> ServiceStack.Text.dll

When we pack ServiceStack.dll to ServiceStack package we add dependency of package ServiceStack.Text where SericeceStack.Text.dll is located

So when I add ServiceStack package as nuget reference to ServiceStack.Text.Tests it also installs ServiceStack.Text package which conflicts with ServiceStack.Text project and build fails with message that ServiceStack.Text.dll already loaded.

This is the simplest scenario, in more complex scenarios packages have more dependencies to other libraries. So adding nuget packages produce a mess which is very difficult (if even impossible) to manage.

Making real project from ServiceStack.dll is impossible too, because it's dependent on ServiceStack.Text.dll (and alot of other libraries) and this produce circular reference and even if it were not circular it would have been huge project which must contain all Servicestack solutions together.

With wrapper projects or referenced assemblies this schema works without issues.

[xplicit]

@eerhardt do you have any idea why the reference is passed to csc.exe via /reference:/path/to/assembly.dll is not resolved and produces compile errors when using types from the assembly? Maybe this can be fixed more easily?