search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.75k stars 1.07k forks source link

Self-contained asp.net core application gives the error “This executable is not bound to a managed DLL to execute” #3300

Open tommy86r opened 5 years ago

tommy86r commented 5 years ago

Self-contained asp.net core application gives the error “This executable is not bound to a managed DLL to execute”

When I publish my asp.net core application as self-contained I succesfully get the myproject.exe. This exe file doesn't work if I double click on it and doesn't work if I try to run it from the cmd console. The project has been update from .net core 2.0 to 2.2 The exception is:

This executable is not bound to a managed DLL to execute. The binding value is: 'c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2' A fatal error was encountered. This executable was not bound to load a managed DLL.

I tried to publish throught Visual Studio (using Method: File System - Target Framework: netcoreapp2.2 - Deployment Mode: self-contained - Target Runtime: win-x64) and also throught cmd console "dotnet publish -r win-x64". But I get the same error.

I added a repo to replicate the issue (I removed almost everythings from the project, it contains only the skeleton, but it seems sufficient to replicate the issue) https://github.com/tommy86r/TempProject

Al last, this is my .net core configuration: dot-net-info

karelz commented 5 years ago

@nguerrera can you please help me route this problem?

karelz commented 5 years ago

@nguerrera ping? cc @dsplaisted if he can help ...

nguerrera commented 5 years ago

Karel, move this to dotnet/sdk

nguerrera commented 5 years ago

The error indicates that the apphost was not correctly customized. @peterhuene I think you worked through one or more issues like this not too long ago. Do you see if this is something we've seen before?

peterhuene commented 5 years ago

I've only seen this before in https://github.com/dotnet/sdk/issues/2989 and the root cause of that was building from VirtualBox where the filesystem driver didn't support MAP_SHARED in the mmap system call, resulting in a failure that left an unmodified apphost in obj/ which was subsequently used in following builds due to it being "up-to-date" with respect to the input dll.

It could be something similar with a previous failure to customize the apphost left it invalid in the obj/ directory, which should be solved by cleaning the project.

We should at least delete the intermediate apphost when the customization fails; I haven't yet made that fix yet though.

karelz commented 5 years ago

@nguerrera BTW: You should be able to move it too now ... Transfer Issue is out of Beta :)

nguerrera commented 5 years ago

We should consider not giving the file its final name until we've successfully customized. That would be more robust than deleting on failure. I think we have to copy then customize in order to preserve file permissions or other metadata, but we could copy to different name, customize, rename to final name, right?