Sdk: Useless and incorrect message if a tool does not have "emitEntryPoint": true

[moozzyk]

Steps to reproduce

Create a tool but don't put "emitEntryPoint": true in the project json.
Try to use the tool from a different project

Expected behavior

Either a warning/error during compilation or a helpful error when trying to run the tool

Actual behavior

PS C:\Users\XXXX\Documents\Visual Studio 2015\Projects\dotnet-scratch> dotnet list-tools
Expect required library hostpolicy.dll to be present in [C:\Users\XXXX\.nuget\packages\.tools\dotnet-list-tools\1.0.0-t2016050317041\netcoreapp1.0]
  - This may be because of an invalid .NET Core FX configuration in the directory.

Note that the error is:

• incorrect - I don't think we ever should expect hostpolicy.dll in ~.nuget\packages.tools subfolder
• useless - not really actionable
• misspelled (?) - shouldn't it be Expected required library... instead of Expect required library?

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc2-002655)

Product Information:
 Version:     1.0.0-rc2-002655
 Commit Sha:  3e96a05f9c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[schellap]

If there are no bugs, and this error is encountered it is too late at the host layer to be more useful.

@moozzyk, Could you please paste with dotnet -v, verbose the command you are using?

@brthor, are tools activated with corehost? This could be an RC2 bug, can you help me understand this scenario?

[schellap]

https://github.com/dotnet/cli/blob/3e96a05f9cb2668dacabc5f8b6bd0aac9f3b823d/src/Microsoft.DotNet.Compiler.Common/Executable.cs#L102

This code doesn't copy the required library if entrypoint is false as an optimization. @brthor should these be copied for tools?

[TheRealPiotrP]

tools without entry point are not a thing. We can improve the experience here in two ways:

• dotnet.exe should provide a useful message when passed any dll that does not have an entry point
• restoring such tools should fail with a useful error

[schellap]

The dotnet.exe does not know if the dll has entry point or not directly. Coreclr already gives a entrypoint not found exception when run. But to execute managed code we need hostpolicy.dll which is not copied in this case as an optimization, this should be fixed. See code above. Otherwise host has to read compilationoptions from deps file... which is probably not the best way to solve this.

[schellap]

See related: dotnet/sdk#5489 same issue.

Unhandled Exception: System.MissingMethodException: Entry point not found in assembly 'App1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

[moozzyk]

What @piotrpMSFT said. This is about experience - people will make mistakes and if they do they need to be able to understand the error messages enough to be able to fix the mistake.

[moozzyk]

@schellap dotnet -v output:

PS C:\Users\XXXX\Documents\Visual Studio 2015\Projects\dotnet-scratch> dotnet -v list-tools
Telemetry is: Enabled
Running C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.0-rc2-3002655\corehost.exe --depsfile C:\Users\XXXX\.nuget\packages\.tools\dotnet-list-tools\1.0.0-t2016050317041\netcoreapp1.0\dotnet-list-tools.deps.json --additionalprobingpath C:\Users\XXXX\.nuget\packages C:\Users\XXXX\.nuget\packages\dotnet-list-tools\1.0.0-t2016050317041\lib\netcoreapp1.0\dotnet-list-tools.dll
Process ID: 56128
Expect required library hostpolicy.dll to be present in [C:\Users\XXXX\.nuget\packages\.tools\dotnet-list-tools\1.0.0-t2016050317041\netcoreapp1.0]
  - This may be because of an invalid .NET Core FX configuration in the directory.

[schellap]

@moozzyk, just to confirm there are no functional issues going into RC, you have tried this out with emitEntryPoint true as well right? In that case, do you get the hostpolicy by the tool's side or in the .nuget packages cache? This could be a bug if tools relied on a hostpolicy.dll next to corehost instead of the above two locations. @brthor need some help understanding if the latter is true for tools.

@moozzyk, if everything worked correctly CoreCLR already handles this by throwing the right exception: and a missing entry point message. The user should be able to fix it with this error message. The problem here is we are unable to get to CoreCLR because the library that loads coreclr is missing. So before we do any more work in the host to read compilationOptions which now became buildOptions, why not just leave it to the coreclr which gives out the right error message in this case? Why is dotnet build optimizing this...

[moozzyk]

1) When I added emitEntryPoint the tool was successfully resolved and executed. No, hostpolicy.dll is still not in the folder (and I don't think it should be there). Here is what I have:

2) As you can see in the screen dumps - I did not get the MissingEntryPointException (not sure if throwing MissingEntryPointException in the user's face is the best option but still it is closer to the issue than This may be because of an invalid .NET Core FX configuration in the directory (btw. in this message what is _the directory_ - dotnet directory, shared runtime directory, sdk directory, ,nuget directory, application directory? And similarly what _.NET Core Fx configuration_ means?)

[schellap]

@moozzyk, thank you for confirming this works. We will give it some thought for RTM.

To answer your questions, this is like a fatal configuration error. Improper setup to run the app is the right word. There is no more context than this to give out unless we bake build time info in the runtimeconfig manifest.

"Could not load from dir" ... that directory.

"In the face" is a Windows error reporting policy which the user can configure. On Unix, it would be a little silent.

I will fix the spelling for RC2.

[brthor]

@schellap

Tools are not activated using CoreHost, but when no entry point is present we don't emit a runtimeconfig.json IIRC. This would cause the tool to look as if it were standalone and it looks like the muxer is looking next to the deps file for hostpolicy.dll.

Since this isn't blocking functionality, I don't think there's any work for RC here, but we should definitely improve the error experience.

I think simply adding a check that a runtimeconfig.json is present next to the tool .dll would solve this particular case before the host activation.

[moozzyk]

@brthor - this is what I was just thinking about. This:

C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.0-rc2-3002655\corehost.exe --depsfile C:\Users\XXXX\.nuget\packages\.tools\dotnet-list-tools\1.0.0-t2016050317041\netcoreapp1.0\dotnet-list-tools.deps.json --additionalprobingpath C:\Users\XXXX\.nuget\packages C:\Users\XXXX\.nuget\packages\dotnet-list-tools\1.0.0-t2016050317041\lib\netcoreapp1.0\dotnet-list-tools.dll

can only be executed only _after_ a tool was resolved. As a result this is not like we fail even before loading CoreClr. Rather we do a bunch of work first where we could add some additional checks and return a better message.

[schellap]

Yes. I agree with @moozzyk and @brthor, that this has to be handled before the activation.

If there are no bugs, and this error is encountered it is too late at the host layer to be more useful.

[lajones]

I just tested this for RC2. I see the same issue. Not having previously worked in this area, I would have liked to see a message like "Loaded matching assembly named <assembly_name> from package <package_name> but that assembly does not contain an entry point. This link <fwlink> explains how to properly create a tool." or some such thing. I.e. Help me identify where the problem is and then tell me the details I need to know to fix it.

[nbarbettini]

I experienced the same or similar error in RTM: http://stackoverflow.com/questions/38085430/the-library-hostpolicy-dll-was-not-found

[aggieben]

I am currently experiencing this issue, but I have emitEntryPoint: true in my project.json.

[chilch]

@schellap and team,

Interestingly, I see this issue still happening with emitEntryPoint: true however if I do dotnet -v run it works just fine. What is it about the -verbose flag that causes it to run successfully?

[sergiyd]

I have the same issue as @chilch wrote. It works in _VS 2015_ or via cmd dotnet run -v, but doesn't from _VS Code_ or _EAP Rider_. The last thing that I did before that I've updated project. I'm not sure that it's related on emitEntryPoint option.

[TheRealPiotrP]

The message is improved in RC3:

Unable to run your project.
Please ensure you have a runnable project type and ensure 'dotnet run' supports this project.
The current OutputType is 'Library'.

I think it would be better if we recommended Exe as the appropriate OutputType. Unfortunately, strings have been sent out for localization so we cannot make the change in 1.0.

/cc @blackdwarf

[rolandh]

I am now having this problem when I didn't previously. It only occurs in debug mode and not in release mode. Is anyone about to assist? What information do you need from me to help resolve this?

edit: It appears all my projects were targetting AnyCPU in debug mode with the main project having "prefer 32bit" ticked. In release mode all projects were targetting AnyCPU except the main project which was targetting x86. Why would this give this bizarre error about Hostpolicy.dll? Very confusing to track down, wasted a lot of time on this.

[StevenOlson]

Getting this error still in Nov 2018 when trying to call "dotnet [app dll]" from the obj/Debug folder on a .net core 2.1 app. The error message is really not very helpful.