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

Created on 22 Oct 2018  路  68Comments  路  Source: dotnet/sdk

Repro steps

  1. Install .NET Core 3.0 SDK (I had 3.0.100-alpha1-009697)
  2. dotnet new wpf
  3. Open VS.
  4. 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.

Bug

Most helpful comment

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.

All 68 comments

I have a fix that's manually verified. Attempting to devise an automated test that would be similarly fixed.

Good to see that a fix is already made!

I have this issue which prevents an automated AppVeyor build, it happens with both 3.0.100-alpha1-009701 and the current 3.0.100-alpha1-009703:

The log is here: https://ci.appveyor.com/project/dapplo/dapplo-caliburnmicro
But if you only want to see the error:

C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018: The "CreateAppHost" task failed unexpectedly. [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018: Microsoft.NET.Build.Tasks.ResourceUpdater+HResultException: 80070002 [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResourceUpdater.ThrowExceptionForLastWin32Error() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018:    at Microsoft.NET.Build.Tasks.AppHost.Create(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String intermediateAssembly, Logger log) [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018:    at Microsoft.NET.Build.Tasks.CreateAppHost.ExecuteCore() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
C:\Program Files\dotnet\sdk\3.0.100-alpha1-009703\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]

How can I see in what version of the SDK the fix is?

Hi @Lakritzator, your failure is unexpected as I would expect Application.Demo.dll to build, but I don't see it building in the log.

Would it be possible to share an MSBuild binlog with me so I can investigate?

@peterhuene I turned on the /bl to generate a binlog which you can find & download here:
https://ci.appveyor.com/project/dapplo/dapplo-caliburnmicro/builds/19797972/artifacts

I hope this works for you, let me know.

I just wanted to report that the error also occurs with 3.0.100-alpha1-009706

msbuild binlog can be downloaded from here: https://ci.appveyor.com/project/dapplo/dapplo-caliburnmicro/build/artifacts

I am running 009706 and when I load this project with Visual Studio 15.8.8 I get:

Severity    Code    Description Project File    Line    Suppression State
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() Fail    C:\Program Files\dotnet\sdk\3.0.100-alpha1-009706\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets  293 

What is weird, the build works... It's something I see in the output panel.

That looks like the same issue, but the change hasn't made it to the .NET Core SDK yet.

What is weird, the build works... It's something I see in the output panel.

This is because it is coming from a design time build

As a workaround, try the following to get VS in a good state:

  • Close VS
  • Delete .vs directory
  • Build on command line
  • Open VS and open solution

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

@nguerrera I already wrote @diverdan92 that it's quite hard to detect where which fixes are, so this doesn't surprise me. I'll just wait for the next build(s) and see if it works there 馃槃

@onovotny thanks for the tip for the patch, this would help me on a PC which I can control, but my build fails on a build server. I think that applying the patch would be quite difficult there 馃榿

The next build will probably arrive Tuesday or Wednesday, I will just wait for it. At least most other issues, which prevent me from working, are solved.

@Lakritzator For me, it was only a design-time build issue, so it wouldn't matter on a build server. Command-line builds always worked for me, but it could be something else for you if that's not working.

Right, if you're seeing this in a command line build, that would have a different root cause, and repro steps would be helpful.

Or, add /bl to your build command line and share the resulting msbuild.binlog

@Pilchie @nguerrera I'm confused, as I already shared the msbuild.binlog

Anyway, I have no problem repeating myself.

Build was made with: 3.0.100-alpha1-009706

The repo version belonging to the build:
https://github.com/dapplo/Dapplo.CaliburnMicro/tree/136f1cad2daded4009e68efd68cb7fa51a44b11b

And the msbuild.binlog can be downloaded here:
https://ci.appveyor.com/project/dapplo/dapplo-caliburnmicro/builds/19842915/artifacts

FYI: I tried the patch linked to by @onovotny by copying it from my repo to the location where it should be installed:
cp "Microsoft.NET.Sdk.targets" -Destination "C:\Program Files\dotnet\sdk\3.0.100-alpha1-009706\Sdks\Microsoft.NET.Sdk\targets"
Unfortunately the build still brings an error.
The link to the console output: https://ci.appveyor.com/project/dapplo/dapplo-caliburnmicro/builds/19854095
The msbuild.binlog for that build can be downloaded here: https://ci.appveyor.com/project/dapplo/dapplo-caliburnmicro/builds/19854095/artifacts

@Lakritzator you should change your keys immediately. binlog records all environment variables and some build systems, like AppVeyor, expose secrets as environment variables. That binlog has leaked things for you. In this case it's your NuGetApiKey.

Only publish binlogs if you're sure their aren't any secrets in the env variables.

FWIW, and I'm not trying to push anything, but Azure Pipelines handles secrets better.

  1. It doesn't expose them to PR fork builds
  2. You can split publish (via release management) and build steps, so the build itself doesn't need any secrets exposed to it. Less surface area.

@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.

@Pilchie @nguerrera I'm confused, as I already shared the msbuild.binlog

Oops. Sorry. I got confused between threads and responded to your last message without seeing the context above.馃槼

(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.)

Looking at the log, we're reading the intermediate assembly right after Fody has done so. Perhaps it left the file locked or something. I haven't dug in to test that guess.

some build systems, like AppVeyor, expose secrets as environment variables

Doh! I knew this, but totally hadn't connected the dots about the exposure there. Thanks for pointing it out, and sorry @Lakritzator!

@Pilchie No problem, I realized it myself after I ran the first job with binlog enabled. It was time to change my API key anyway. So I left it, and just updated the key.

@nguerrera It could be possible, Fody does a lot 馃榿 , but I find it unlikely.

Running the build locally will reproduce the error:

  1. checkout https://github.com/dapplo/Dapplo.CaliburnMicro branch "feature/dotnetcore30"
  2. Powershell in the root of the repo
  3. run .\build.ps1 -Target Build

Is there anything else I can do?

That doesn't reproduce the problem for me:

Finished executing task: Build

Task                          Duration
--------------------------------------------------
Clean                         00:00:00.0600912
AssemblyVersion               00:00:00.0545473
Build                         00:01:28.1879133
--------------------------------------------------
Total:                        00:01:28.3025518

D:\Src\Dapplo.CaliburnMicro (feature/dotnetcore30)
位 dotnet --version
3.0.100-alpha1-009706

D:\Src\Dapplo.CaliburnMicro (feature/dotnetcore30)
位 D:\Src\Dapplo.CaliburnMicro\src\Application.Demo\bin\Release\netcoreapp3.0\Application.Demo.exe

image

@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 Thanks for the apologies, but I still think I am responsible for thinking about this myself too! Anyway the API key could only be used to publish packages and I changed it before someone did.
That said, it's still important to have a concept where it's possible to collect data, without having a risk of leaking.

@nguerrera I'm buff... You are running an unmodified 3.0.100-alpha1-009706? Or did you patch it?
Just in case, I tried a clean checkout and can still reproduce the error every time with the steps you made. The directory where I would expect the exe, "Dapplo.CaliburnMicro\src\Application.Demo\bin\Release\netcoreapp3.0\" is empty.
Any ideas? If you want information, or have files modified, let me know.

P.S.
Just in case, I run with an official Windows 10 Pro, 1809 (build 17763.55) on a Surface Pro (2017)

It's unmodified 9706

Oh, the directory is empty. That's a killer clue.

In the log from appveyor, I see csc [...] /out:obj\Release\netcoreapp3.0\Application.Demo.dll succeed.

Then Fody says:

  Fody:   Writing assembly to 'C:\projects\dapplo-caliburnmicro\src\Application.Demo\obj\Release\netcoreapp3.0\Application.Demo.dll'.
  Fody:   Finished writing assembly 24ms.

Then, CreateAppHost gets IntermediateAssembly = C:\projects\dapplo-caliburnmicro\src\Application.Demo\obj\Release\netcoreapp3.0\Application.Demo.dll and that is failing with the HResult 0x80070002 (ERROR_FILE_NOT_FOUND)!

Does a log on your machine look the same?

Is Application.Demo.dll anywhere on your machine after a build?

I see there's a cake step that wipes all the obj directories after MSBuild runs. Can you disable that and see what you get in src\Application.Demo\obj\Release\netcoreapp3.0\ too?

The cake step that wipes the obj directories was there as it caused issues with tests. Anyway, this step would could be reached as the build failed.

The directory src\Application.Demo\obj\Release\netcoreapp3.0\ has the Application.Demo.dll and also an Application.Demo.exe and .pdb

I'm not used to reading binlogs, I found the following:

Fody task says:
Output file "C:\Projects\Dapplo.CaliburnMicro\src\Application.Demo\bin\Release\netcoreapp3.0\Application.Demo.dll" does not exist.
And something which contradicts?
Fody: Writing assembly to 'C:\Projects\Dapplo.CaliburnMicro\src\Application.Demo\obj\Release\netcoreapp3.0\Application.Demo.dll'.

And the CreateAppHost output:

CreateAppHost
    Assembly = C:\Program Files\dotnet\sdk\3.0.100-alpha1-009706\Sdks\Microsoft.NET.Sdk\targets\..\tools\net46/Microsoft.NET.Build.Tasks.dll
    Parameters
        AppHostSourcePath = C:\Users\robin\.nuget\packages\runtime.win-x64.microsoft.netcore.dotnetapphost\3.0.0-preview1-27024-03\runtimes\win-x64\native\apphost.exe
        AppHostDestinationPath = obj\Release\netcoreapp3.0\Application.Demo.exe
        AppBinaryName = Application.Demo.dll
        IntermediateAssembly = C:\Projects\Dapplo.CaliburnMicro\src\Application.Demo\obj\Release\netcoreapp3.0\Application.Demo.dll
        WindowsGraphicalUserInterface = True
    Errors
        C:\Program Files\dotnet\sdk\3.0.100-alpha1-009706\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(293,5): error MSB4018: The "CreateAppHost" task failed unexpectedly.
Microsoft.NET.Build.Tasks.ResourceUpdater+HResultException: 80070002
   at Microsoft.NET.Build.Tasks.ResourceUpdater.ThrowExceptionForLastWin32Error()
   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() [C:\Projects\reproduce\Dapplo.CaliburnMicro\src\Application.Demo\Application.Demo.csproj]

It's probably Fody related somehow... but I don't understand.
The files are there, so maybe you are right about them not being closed?

Edit above: bin directory being empty wasn't a very big clue after all because the build failed before things would have been copied or written to it. The real place to check is the obj directory.

Output file "C:\Projects\Dapplo.CaliburnMicro\src\Application.Demo\bin\Release\netcoreapp3.0Application.Demo.dll" does not exist.

This is because the Fody task declares that it outputs to the final output path, which doesn't exist yet naturally at this point. It's sketchy to be writing there in compile phase, but then it only logs writing to intermediate location, so maybe that's just a mistaken outputs declaration.

Is it possible to disable Fody rewriting just to narrow things down?

Is it possible to disable Fody rewriting just to narrow things down?

I will modify the solution so it doesn't need to use fody on the exe project as a workaround... I also expect this to work, and if this solves the issue I will try to contact Simon Cropp, maybe he tell us more.
Maybe it's related to: https://github.com/Fody/Fody/issues/582

In the next ~4 hours I'll not be behind a PC, just so you know.

So I managed to remove Fody from the Application.Demo project, but the problem still exists.
Here is the msbuild.binlog

Am I blind, I can't find the reason for it to fail...

FYI: 3.0.100-alpha1-009708 still gives the same error on AppVeyor

Ah! Something I missed before:

The failures in design time builds are in AddResourcesFromPEImage

Microsoft.NET.Build.Tasks.ResourceUpdater+HResultException: 80070002
   at Microsoft.NET.Build.Tasks.ResourceUpdater.AddResourcesFromPEImage(String peFile)

While the failure in your real builds is in ResourceUpdater constructor:

Microsoft.NET.Build.Tasks.ResourceUpdater+HResultException: 80070002
   at Microsoft.NET.Build.Tasks.ResourceUpdater.ThrowExceptionForLastWin32Error()

This means that we're getting file not found in the real builds on the exe we should have just copied from the nuget cache and already rewritten a bit (and not on the intermediate dll as we were in the design time case):

https://github.com/dotnet/sdk/blob/68f87419a7219352677b3c0d28f52f36cc1b3cd3/src/Tasks/Microsoft.NET.Build.Tasks/AppHost.cs#L82-L83
https://github.com/dotnet/sdk/blob/68f87419a7219352677b3c0d28f52f36cc1b3cd3/src/Tasks/Microsoft.NET.Build.Tasks/AppHost.cs#L53

I don't know how this could happen. Maybe we're locking it, but the using block where we rewrite it before adding the resources looks right. Or maybe anti-virus? Grasping at straws here.

With resources you mean .resx? Don't have any... could that cause the issue?

I use the standard windows security as anti-virus, maybe the locale has influence? (German)

With resources you mean .resx

No, I mean win32 resources. This is the step that copies them into the exe from the dll. They are for things like the app icon, windown manifiest, version info you see in File Explorer properties.

I felt kind of stuck, until I noticed that the stacktrace has changed.

This is the error I currently get, without using fody and with the current SDK version (009708), which is a different stacktrace as in the original error I reported:

The "CreateAppHost" task failed unexpectedly. [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
Microsoft.NET.Build.Tasks.ResourceUpdater+HResultException: 80070002 [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
   at Microsoft.NET.Build.Tasks.ResourceUpdater.ThrowExceptionForLastWin32Error() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
   at Microsoft.NET.Build.Tasks.AppHost.Create(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String intermediateAssembly, Logger log) [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
   at Microsoft.NET.Build.Tasks.CreateAppHost.ExecuteCore() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
   at Microsoft.NET.Build.Tasks.TaskBase.Execute() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\projects\dapplo-caliburnmicro\src\Application.Demo\Application.Demo.csproj]

Does this change anything?

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 I'm not sure what relative path you are talking about?

@peterhuene Possible. I wonder how it is that this works on my machine, but not @Lakritzator's.

@Lakritzator The AppHostDestinationPath parameter to the CreateAppHost task, which is obj\Release\netcoreapp3.0\Application.Demo.exe.

AppHost.Create copies the source apphost to that location, then instantiates ResourceUpdater to update the resources. The relative path from AppHostDestinationPath is used for both.

It's weird that the copy would succeed but the update fail with file not found, unless one of the operations is looking in the wrong place.

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.

@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)')"

Given this works elsewhere, it is a total stab in the dark. The 80070002 HRESULT could be a poor error, i.e. "we failed to open the file, set last error to file not found", so I think it's likely to be something unexpectedly locking the file rather than the file not existing.

@nguerrera Ok, going to try it now.

@nguerrera My build ran through!! It works!!!!!

Still I feel a little special, in a dirty way 馃榿 , why does my constellation cause so many problems? Do I do something unusual, maybe something I shouldn't be doing?

I will now roll back my previous changes, to see if everything works again with the fody weaving back in place.

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

@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.

@peterhuene & @nguerrera FYI: with 3.0.100-preview-009722 the error is still there.
The supplied fix still works, actually the file Microsoft.NET.Sdk.targets didn't change.
But I hope I don't have to apply the fix every time I update the SDK.

Are you still tracking this issue and can I help you somehow to supply information?

@nguerrera any idea when this fix will be bundled with the sdk setup?

For the original bug report, we're working through some issues to get the code flow unblocked. Hoping to have a build today.

For the separate issue that @lakrizator has encountered, we still haven't committed the fix. I don't think it's well understood why it fails only on some machines without a full path, but resolving a full path before calling BeginUpdateResource is harmless at worst, so maybe we should just do that. @peterhuene, do you agree?

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.

Not many people following this, but still FYI: there is no fix in 3.0.100-preview-009726.

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.

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 馃憤

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!

@peterhuene Any chance you can slip https://github.com/dotnet/sdk/issues/2599#issuecomment-434451956 or equivalent into the payload with the f# fix?

Can do.

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.

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!

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 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 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.

Still happening in 16.3.2
"CreateAppHost" task failed unexpectedly

Please open a new issue and include the full output.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

timotyweis picture timotyweis  路  81Comments

dasMulli picture dasMulli  路  138Comments

danmosemsft picture danmosemsft  路  137Comments

murali2020kris picture murali2020kris  路  70Comments

NinoFloris picture NinoFloris  路  99Comments