Sdk: The "CreateAppHost" task failed unexpectedly. (Version 16.4.5)

[avifatal]

Hi,

Microsoft Visual Studio Community 2019
Version 16.4.5
Randomly getting the bellow error. I have added my root folder to the antivirus exclusion list.

Error   MSB4018 The "CreateAppHost" task failed unexpectedly.
Microsoft.NET.HostModel.HResultException: 8007006E
   at Microsoft.NET.HostModel.ResourceUpdater.Update()
   at Microsoft.NET.HostModel.AppHost.HostWriter.<>c__DisplayClass2_0.<CreateAppHost>g__UpdateResources|1()
   at Microsoft.NET.HostModel.RetryUtil.RetryOnWin32Error(Action func)
   at Microsoft.NET.HostModel.AppHost.HostWriter.CreateAppHost(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String assemblyToCopyResorcesFrom)
   at Microsoft.NET.Build.Tasks.CreateAppHost.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() EyezServices.Client C:\Program Files\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets    393 

Thanks

[brcaswell]

curious... Are you running multiple VS instances or VS Code. Anything in that manner?

Also, have you tried running Visual Studio in Administrator (ADMIN) mode? "Run as Administrator"

[brcaswell]

Well, it does seem a Win32 File Lock may be the cause.

---

Apart from the 'why' concern,
https://github.com/dotnet/sdk/blob/a5f5bb5183517cb301050288b25c9c727e52e8a6/src/Tasks/Microsoft.NET.Build.Tasks/CreateAppHost.cs#L83-L84

Indicates the exception handling should be replaced once https://github.com/dotnet/core-setup/pull/7665 was merged, is that something that should be done?

is capturing the HResultException keeping this exception from being handled differently? @peterhuene ?

[avifatal]

Hi.
It is running as administrator.
Its a multiple startup web projects. Running on docker .

I think only one instance of vs2019 is running.

I use to kill the docker containers to solve this issue.
But since i updated vs 2019 to the latest version this does not help anymore..
Clean rebuild sometime helps but its very very long...

Vs code is running react project in the background from a different folder.
Thanks

[avifatal]

@brcaswell Maybe it is not so related to docker or 2 startup projects...
also happening in the test:

Actually now, vs has become almost in-usable. I need to clean rebuild almost every debug...

[avifatal]

@brcaswell Can you please help with this issue??? I'm dying here...
Thanks

[marekpetak]

Same here. Using net core 3.1, single or multiple VS instance(s) makes no different, running on localhost:5000. Very random, it happens on rebuild, run and and I've seen it happening on IIS once published. I could run/debug the api for a half a day with no problem, then it happens again.

[avifatal]

@marekpetak I think it is starting when you stop and after very very short time debug again. then, after that point, it becomes very random... very hard to work like that

[swaroop-sridhar]

This is a dup of https://github.com/dotnet/runtime/issues/3832.
A fix for this issue was checked into the master branch: https://github.com/dotnet/runtime/pull/32347

This fix is approved for servicing: https://github.com/dotnet/core-setup/pull/9012
It'll be released in an upcoming servicing fix.

[swaroop-sridhar]

CC: @wli3 @nguerrera

[brcaswell]

Indeed. In this scenario, those changes to apply that retry logic should apply. Should fix it

[AlbertoBN]

The problem persists with latest SDK

[ScottHutchinson]

For me, cleaning the solution in VS 2019 16.4.5 and SDK 3.1.101 fixed this build error.
EDIT: Later in the day, it happened again (while I had another VS open), and I had to restart VS to fix it again. The solution files were in my Dropbox folder.

[AlbertoBN]

For me it happens also in command line. And I love command line.

[jrbriones]

curious... Are you running multiple VS instances or VS Code. Anything in that manner?

Also, have you tried running Visual Studio in Administrator (ADMIN) mode? "Run as Administrator"

Thank you! i had both things you mentioned going for me, i closed one of the instances (in a different IDE i was trying out) then i ran as admin and it finally worked!

[marekpetak]

I can almost recreate this problem.

1. project compile fine
2. do some changes that will cause it not to compile
3. fix issue, hit build, it will crash
4. build again, all fine

repeat and it will always crash first time, on 2nd time OK.

[avifatal]

This is a nightmare... nothing helps

[roblohmann]

Running into this issue a lot as wel.. Just running a simple project with 2 docker containers, the docker-compose is my startup and it is the only VS2019 instance running.

What helps me is just to clean to solution, after that I can debug untill it occurs again.

[AlbertoBN]

Called corporate IT... They added an exception on the antivirus on my dev folder. Problem solved

[stimpy77]

That's a workaround, not a resolution, @AlbertoBN . I tried to do the same, but the specific Trend Micro product installed on my machine explicitly doesn't support wildcards on exclusion paths, so I ended up having them completely disable TM. Now I'm stuck without a working antivirus. In the end, a code build process should not be hindered by antivirus. exclusions aside. We can blame the AV vendors, but I don't recall having this problem with any .NET build component in the last 18 years I've been using .NET.

[swaroop-sridhar]

The fix to perform more retries on the AppHost update will be in 3.1.4, scheduled for next week.
Hope this will help alleviate the problem in most cases.

[AlbertoBN]

That's a workaround, not a resolution, @AlbertoBN . I tried to do the same, but the specific Trend Micro product installed on my machine explicitly doesn't support wildcards on exclusion paths, so I ended up having them completely disable TM. Now I'm stuck without a working antivirus. In the end, a code build process should not be hindered by antivirus. exclusions aside. We can blame the AV vendors, but I don't recall having this problem with any .NET build component in the last 18 years I've been using .NET.

True. It is a workaround... And out of a team of 7 it happens to me only on a brand new laptop. However by the time the next version comes out and by the time we get to install it this is the best option for me.

[Nathaire]

I had the same issue as well. Moving the solution folder into a folder not checked by the windows antivirus solve the issue.

[salvatorious]

This is happening on Linux as well, when attempting to run dotnet build for a 3.1.202 application.

[avifatal]

The fix to perform more retries on the AppHost update will be in 3.1.4, scheduled for next week.
Hope this will help alleviate the problem in most cases.

@swaroop-sridhar the fix is not working.
I have installed 3.1.4 and it is still happening...
Please advise another workaround. our efficiency dropped by 40% because of this...
We have 23 projects in the solution. we need to clean the solution every debug.
it is impossible...
Thanks

[swaroop-sridhar]

@avifatal to confirm:

• You tried building an app with the new SDK in 3.1.4 release, right?
• What was the SDK version?
• Do you see the failure during Microsoft.NET.HostModel.RetryUtil.RetryOnWin32Error() during resource-update?
• What was the exception?

As for workarounds, you can try disabling interference from other programs from locking the host when the build is in progress -- for example, whitelisting the executable you are building with anti-virus scanners.

[troygerton]

I just started getting this same issue this afternoon. I have compiled this solution hundreds of times over the past 2 weeks. Additionally, Windows Defender think the output DLL is a Trojan.

I have deleted the bin and obj dirs in my project. Each time I build the project it fails and windows defender logs a virus. I have done a complete virus scan using windows defender and a couple other tools - my machine is clean.
What is going on?

[troygerton]

Updated VS to latest release and allowed my dll thru windows defender as a workaround.

[avifatal]

@swaroop-sridhar ok. no matter what update I made it is still happening. the one thing that helped is updating visual studio to the most recent: 16.6.0
Thanks for helping out.
Avi

[NicolasReyDotNet]

I got it too

[kaldren]

Cleaning the solution fixed this for me.
(Visual Studio 2019 16.6.1)

[NicolasREY69330]

Solved it upgrading to VS 16.6.0, I never had it again

[chendricks16]

Sill having this issue, I'm at VS 16.6.2. Any further resolution?

[swaroop-sridhar]

@chendricks16 can you please add a few more details to your failure?

• What was your solution targetting?
• Did you do a clean rebuild?
• Can you make sure you're using the latest SDK (run dotnet --version from the project root)
• What was the HResult exception code?

[AccsysTTD]

We had a similar issue and it was due to having simultaneously accessing the working folder in WSL and windows. This seemed to cause a locking problem and exhibited with this error.

[danvln]

Same here. This issue for me was caused by WSL locking. I had to shutdown WSL completely to have it working, and in addition I observed (not measured) that the speed of VS 2019 is way better with WSL shutdown.

[dinispeixoto]

Closing VS Code (running on WSL) solved the issue for me. Also worth mentioning that both VS and VS Code were using the same working dir

[safv12]

Closing VS Code (running on WSL) solved the issue for me. Also worth mentioning that both VS and VS Code were using the same working dir

Me too!

[brcaswell]

Thanks everyone for contributing your scenarios, experience and workarounds to this issue; This particular issue was in the context of 16.4.5 and an earlier dotnetcore SDK. It was (has been) designated to be closed as a duplicate. That duplicate, original issue facilitated work on the retry logic that directly affects the reproducibility of this issue, and has been since released.

Given that OP did indicate the issue was resolved with 16.6.0 version, I wouldn't expect reproducibility by the originator of this issue. As such, I think any subsequent issue and observation should be new on the basis of having the new functionality in place and with reproducibility.

So, If you are experiencing this exception and issue on 16.6.X or later, please create a new issue workitem - feel free to link to this closed issue.