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?

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.