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

[tommy86r]

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:

[karelz]

@nguerrera can you please help me route this problem?

[karelz]

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

[nguerrera]

Karel, move this to dotnet/sdk

[nguerrera]

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]

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]

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

[nguerrera]

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?