sdk: CreateAppHost runs and fails during VS design time build if project isn't already built

Repro steps

Install .NET Core 3.0 SDK (I had 3.0.100-alpha1-009697)
dotnet new wpf
Open VS.
Open the project created in 2.

Result

Error    MSB4018    The "CreateAppHost" task failed unexpectedly.
Microsoft.NET.Build.Tasks.ResourceUpdater+HResultException: 80070002
   at Microsoft.NET.Build.Tasks.ResourceUpdater.AddResourcesFromPEImage(String peFile)
   at Microsoft.NET.Build.Tasks.AppHost.Create(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String intermediateAssembly, Logger log)
   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()

(from C:\Program Files\dotnet\sdk\3.0.100-alpha1-009697\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets Line 293)

Expected

We probably shouldn’t run this target if the assemblies it’s going to work on don’t exist.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 68 (39 by maintainers)

Commits related to this issue

Ensure inputs exist for CreateAppHost task. This commit fixes design time builds where the intermediate assembly may not exist, causing the `CreateAppHost` task to fail. The change is to condition t... — committed to peterhuene/sdk by deleted user 6 years ago
Use full path for apphost destination CreateAppHost task. This commit uses the full path when specifying the `AppHostDestinationPath` parameter to the `CreateAppHost` task. It appears that `BeginUpd... — committed to peterhuene/sdk by deleted user 6 years ago
Use full path for apphost destination in CreateAppHost task. This commit uses the full path when specifying the `AppHostDestinationPath` parameter to the `CreateAppHost` task. It appears that `Begin... — committed to peterhuene/sdk by deleted user 6 years ago
With the fix mentioned in dotnet/sdk#2599 I can remove the patching of the Microsoft.NET.Sdk.targets — committed to dapplo/Dapplo.CaliburnMicro by Lakritzator 6 years ago
Update dependencies from https://github.com/aspnet/websdk build 20190904.3 (#2599) - Microsoft.NET.Sdk.Web - 5.0.100-alpha1.19454.3 — committed to dotnet/sdk by dotnet-maestro[bot] 5 years ago

Most upvoted comments

Figured it out. For anyone viewing this thread, the culprit was Windows Security. I was getting the above error about 40% of the time I did a build (F5 and Control-F5). The fix:

go to Virus & threat protection

Manage settings Add or remove exclusions Add an exclusion to the parent folder for all your repositories

I didn’t see this specific fix anywhere else on the web, so hopefully this helps someone.

bzapata-thr on Oct 8, 2019

Hi Nick, thanks for writing that.

I’m not frustrated, in fact I think you are doing a great job by doing this in the open, which is certainly not easy. And I am sorry if that comment felt like stressing you, I actually didn’t think about that. I really wanted to prevent something I had experienced, like issue x was fixed but it wasn’t clear in which build it arrives. I have no problems at all waiting much longer for a fix, especially if this gives you time to improve the build pipeline and maybe even make something like rudimentary release notes. And there are probably issues which deserve a higher priority!

I know what it means to run alpha or beta software, I wouldn’t be doing this if it doesn’t bring something. This makes it possible to adapt my product way quicker than to wait until it’s released. It also gives me a possibility to influence the framework with some of my experiences, and learn something while doing this. For instance: I actually learned today that there is no such thing as an “Any Cpu” .exe, it’s a .NET Framework thing. I should bring this up with Daniel. It’s a mystery why I didn’t know… but not having this this does complicate my product and a lot of others.

I actually got most of the foundation code for Greenshot running on dotnet core 3.0, it might still have a few small quirks, but this is really amazing work in such a short time!!! Just seeing the shear amount of APIs that you guy processed, is mind boggling. I hope to have a running Greenshot soon, much sooner as I expected!

Lakritzator on Nov 4, 2018

I understand it’s frustrating, but please understand that you are picking up CI builds that span changes from many teams and many repos (closed and open). This is necessarily more painful than picking up traditional, official preview 1,2,3 builds that undergo coordinated testing, have release notes, etc. We’re doing our best, but we’re just not equipped to have perfect release details with every CI build. Things are bound to be broken with such builds, and they are bound to remain so for a number of builds before code flows to its final destination.

On top of that, we have not even committed the fix for the second issue that you reported here that just happened to have a similar looking stack, but was in fact completely different.

We genuinely appreciate that you have been willing to test out these builds, and thank you for reporting these issues that will be addressed in official previews, and make the final product better for everyone!

nguerrera on Nov 3, 2018

I agree, that would be fine.

Regarding the builds, we’re a little behind on getting changes from dotnet/sdk into the core-sdk builds due to needing changes from previous release branches, which currently requires a bit of manual labor to make work because our repos are undergoing a change in build infrastructure. As Nick said, we hope to have this in the actual builds soon.

peterhuene on Nov 2, 2018

@Lakritzator - you’re just very early (and we appreciate these explorations very much!!!)

diverdan92 on Oct 30, 2018

@Lakritzator: my apologies as well for requesting the binlog without proper guidance on how to get it to us and on removing any sensitive data it might contain for even your public CI builds. Thanks to @onovotny for being on the ball and making you aware of the problems with your API key before it became an issue.

Perhaps we can add a feature to MSBuild to exclude properties sourced from the environment (with an “include these properties list”) so that sensitive data like this doesn’t make its way into the log accidentally. If it became clear that a particular property’s value was needed to determine why some conditional wasn’t evaluating as expected, then an additional collection could be performed including that property.

peterhuene on Oct 29, 2018

@Lakritzator thanks for following up and glad it’s now working for you! Let’s continue the dotnet run discussion on the other issue you filed.

peterhuene on Nov 6, 2018

@peterhuene Thanks, this works great! This makes using newer builds a lot easier, without having to check if I can use the same patch, fixing the path etc.

So, the build is running fine, starting the application is not. Since 3.0.100-preview-009726 I cannot run dotnet core UI applications, I reported another issue, but I am actually not sure if core-sdk is the correct location: https://github.com/dotnet/core-sdk/issues/135

Lakritzator on Nov 6, 2018

We now have a build that should contain the fix. @Lakritzator could you try with 3.0.100-preview-009730 and let us know how it goes? Thanks very much for your patience!

I’ll close the issue to signal the fix is in the build, but feel free to continue commenting with any additional feedback.

peterhuene on Nov 6, 2018

I just want to make sure that others (if there are any) don’t need to do the same test.

I apologize for missing this noble intent. I am actually fine with that. It’s just a little stressful to get “still not fixed in build X” notifications when we’re all working as hard and fast as we can.

nguerrera on Nov 3, 2018

Can do.

peterhuene on Nov 3, 2018

The main “problem” with current builds is that I can’t find which fixes are in it and which not. I already have seen some issues closed, but the fix not yet available in any build. I know it was slightly irritating, but I just want to make sure that others (if there are any) don’t need to do the same test.

I like it more the way you described, so I do not need to test every build 👍

Lakritzator on Nov 3, 2018

This should really be a separate issue, but reopening this one to track without losing context.

Well close again when a build is available with the second fix. No need to report on each build in the meantime. Thanks.

nguerrera on Nov 3, 2018

@diverdan92 You are just being kind! I don’t directly meant it in a bad way, but maybe I have some weird settings which don’t make sense and could be done a lot more efficient. Also, why does it not work on my system (and the AppVeyor build server) but the same repository works on Peters and Nicks systems?

So far I have no problem with exploring, and you can always send me a Surface Book 2 to make me go faster 😁

@nguerrera I reverted back locally to before getting Fody out of the picture, the build still works with the change you suggested. I cannot tell you if this makes sense for the final product, I’m to far away from the build internals, but now you should have a better idea of what is wrong.

Lakritzator on Oct 30, 2018

@Lakritzator To test @peterhuene’s theory, can you try changing this:

https://github.com/dotnet/sdk/blob/4cafd94e923f1464ec6de92d9ca14f72189d8c25/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L294

To:

AppHostDestinationPath="@(_NativeAppHostNETCore->'%(FullPath)')"

nguerrera on Oct 30, 2018

I’d also expect MemoryMappedFile.CreateFromFile to fail if the copy didn’t do the correct thing, so seems like it’s related to BeginUpdateResource.

peterhuene on Oct 30, 2018

I wonder if BeginUpdateResource is somehow being tripped up by the relative path, from MSDN:

If pFileName does not specify a full path, the system searches for the file in the current directory.

That doesn’t really make it clear that it will properly combine pFileName with with CWD, but I assume it would.

Although, that doesn’t explain why it’s working on other systems 😕

peterhuene on Oct 30, 2018

(Aside: I’m following up with the team about standardizing how we request binlogs to make sure it is clear what they may contain and the risks of sharing publicly.)

nguerrera on Oct 28, 2018

@onovotny I already changed the key, thanks for the hint.

Didn’t find the time yet to migrate, and I really want to use Azure Pipelines as I find the release management very appealing.

Lakritzator on Oct 28, 2018

What I’ve done for now is to manually make that patch in the installed targets file. It’s pretty small:

https://github.com/dotnet/sdk/pull/2604/files

clairernovotny on Oct 27, 2018