Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Apphost.exe was not found
Options
Previous Topic Next Topic
bhugot
#1 Posted : Wednesday, July 21, 2021 5:28:17 PM(UTC)
Rank: Member

Groups: Registered
Joined: 8/19/2018(UTC)
Posts: 10
Location: France

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Hello. Since today i updated to last visual studio 2019. I have build error on netcoreapp project
Could not copy the file obj\debug\netcoreapp3.1\apphost.exe because it was not found.
Back to top
cheil
#2 Posted : Wednesday, July 21, 2021 9:20:52 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 4/5/2019(UTC)
Posts: 7
Location: United States of America

Thanks: 4 times
Was thanked: 2 time(s) in 2 post(s)
I am experiencing the same issue in VS2019. Project is running net5.0 with the error message

NCrunch: If you are experiencing problems in getting this project to build, have a look at http://www.ncrunch.net/d...ng_project-build-issues
..\..\..\..\..\..\program files (x86)\microsoft visual studio\2019\professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets (4964, 5): Could not copy the file "C:\Users\myuser\AppData\Local\NCrunch\47552\1\MyProject\obj\Debug\net5.0\apphost.exe" because it was not found.
Back to top
Remco
#3 Posted : Thursday, July 22, 2021 12:55:19 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks for sharing this issue. Are you able to provide a self contained code sample that can reproduce this issue? Or otherwise guidance on which VS project template can cause it?
Back to top
bhugot
#4 Posted : Thursday, July 22, 2021 6:42:45 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/19/2018(UTC)
Posts: 10
Location: France

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Just create a new netcoreapp3.1 app and I got it
Visual studio Version 16.10.4
Ncrunch 4.9.0.8

On another computer with same configuration I don't get the error (and the apphost.exe does not exists in obj directory)
It's due to the use of the last net6 preview (6.0.100-preview.6 -> 6.0.100-preview.6.21355.2)
If i put a global json with a net5 or net3 sdk it's working
Back to top
 |  Edit by user
Remco
#5 Posted : Thursday, July 22, 2021 11:23:39 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks to your help, I've managed to reproduce this issue. Even after I had it consistently happening for me, it took a while to figure out what was actually going on. I'm not terribly impressed with how MS have implemented this under the hood.

Basically, the root problem appears to be due to a bug in .NET6. Because this platform is in preview, these sorts of issues are probably to be expected. The next problem is that under NCrunch, MSBuild is automagically rolling forwards to use the new preview build of .NET, where under VS it doesn't do this.

My preference is usually to have NCrunch try to emulate VS's behaviour, but in this case such a thing is extremely difficult to achieve. The component responsible for rolling the platform forward is built as a black box with minimal opportunity for effective override. To determine whether it should use preview versions of .NET, it actually performs a memory test to see which version of VS is hosting it, then uses this as a way to adapt its behaviour. Because NCrunch isn't VS, naturally we can't easily do this. So at this stage it doesn't appear to be feasible for us to implement a workaround in NCrunch itself.

The good news it that before NET6 leaves its preview state, MS will need to fix this problem. Otherwise the whole toolchain will break for everyone as soon as the preview tag gets removed.

So from here you have the following options:

1. Remove NET6 preview from your machine until MS have fixed it

2. Use a global json to override the SDK target to force MSBuild to use a version you specify (i.e. 5.0.302)

3. Under your NCrunch custom environment variables, set the following two variables:

DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR = SDK dir for the version of .NET you want to use
DOTNET_MSBUILD_SDK_RESOLVER_SDKS_VER = version of .NET you want to use

Example:

DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR = C:\Program Files\dotnet\sdk\5.0.302\Sdks
DOTNET_MSBUILD_SDK_RESOLVER_SDKS_VER = 5.0.302
Back to top
2 users thanked Remco for this useful post.
rgwood on 8/18/2021(UTC), Kelon on 9/11/2021(UTC)
bhugot
#6 Posted : Thursday, July 22, 2021 11:40:05 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/19/2018(UTC)
Posts: 10
Location: France

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Ok thanks last option is fine for me.
Did you see or posted an issue to microsoft on this?
Back to top
Remco
#7 Posted : Thursday, July 22, 2021 12:45:58 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
bhugot;15553 wrote:
Ok thanks last option is fine for me.
Did you see or posted an issue to microsoft on this?


No. I think it's extremely unlikely that they don't know about the issue. You are welcome to report it to them if you can find the time.
Back to top
MarcChu
#8 Posted : Wednesday, July 28, 2021 4:31:01 PM(UTC)
Rank: Member

Groups: Registered
Joined: 9/26/2014(UTC)
Posts: 22

Thanks: 3 times
Was thanked: 1 time(s) in 1 post(s)
I'm having this same problem. However, I'm having it in VS2022 preview (it seems that others are having it in VS2019), and I'm not having the problem locally. Rather, I'm having the problem on 2 out of 3 of my distributed nodes (the other one builds just fine). When I first ran into this problem, I thought it might be because I did not have VS2022 Build Tools installed on the nodes, so I went ahead and installed it on all 3 machines. The 3 distributed nodes are virtual machines, and they may each have different environments, e.g. OS version.

I'd rather not uninstall my VS2022 preview, but the global.json solution doesn't seem to have any effect, and neither does the custom environment variable solution. Is there something about the fact that these are distributed nodes affect the way these solutions are supposed to work?

As an aside, I'd really like to see a feature that allows me to control the UI for when 1 or more distributed nodes fail to build. I think my biggest annoyance with this problem is that even though my projects all successfully build locally and on one other distributed node, each affected project is displayed as a build failure, and the NCrunch icon in the VS status bar reflects the number of failed builds, rather than the number of successful/failed tests. My feeling on this matter is that this should only be the case when every node fails to build, as I'm much more interested in a syntax/compilation error that would prevent any build and any tests from being run on a project, rather than something like this, which is due only to environment issues.
Back to top
Remco
#9 Posted : Wednesday, July 28, 2021 11:33:07 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
MarcChu;15560 wrote:
I'm having this same problem. However, I'm having it in VS2022 preview (it seems that others are having it in VS2019), and I'm not having the problem locally. Rather, I'm having the problem on 2 out of 3 of my distributed nodes (the other one builds just fine). When I first ran into this problem, I thought it might be because I did not have VS2022 Build Tools installed on the nodes, so I went ahead and installed it on all 3 machines. The 3 distributed nodes are virtual machines, and they may each have different environments, e.g. OS version.


Can you check for me which versions of DotNet are installed on your grid nodes? Usually these install to C:\Program Files\dotnet\sdk. I'm curious as to whether the preview of NET6 was rolled out onto them.

MarcChu;15560 wrote:

I'd rather not uninstall my VS2022 preview, but the global.json solution doesn't seem to have any effect, and neither does the custom environment variable solution. Is there something about the fact that these are distributed nodes affect the way these solutions are supposed to work?


In theory, the custom environment variables fix should also work for the grid nodes. However, it's quite possible that the nodes have slightly different versions of DotNet installed. If the environment variables point to versions of DotNet on the nodes that aren't installed, they may be disregarded. We use a grid here internally and I've noticed our minor versions of DotNet often don't seem to be aligned between the machines.

MarcChu;15560 wrote:

As an aside, I'd really like to see a feature that allows me to control the UI for when 1 or more distributed nodes fail to build. I think my biggest annoyance with this problem is that even though my projects all successfully build locally and on one other distributed node, each affected project is displayed as a build failure, and the NCrunch icon in the VS status bar reflects the number of failed builds, rather than the number of successful/failed tests. My feeling on this matter is that this should only be the case when every node fails to build, as I'm much more interested in a syntax/compilation error that would prevent any build and any tests from being run on a project, rather than something like this, which is due only to environment issues.


It's possible to do this using the required capabilities setting on the projects involved. Basically, you use the capabilities to tell the system which nodes are expected to build which projects. If you have a node where you expect a failure, you use the capabilities to exclude it from building the project. There are no plans to prevent reporting of redundant build failures, as these are actually still problems that users should be made aware of. If a node can't build a particular project, it also can't run any tests that require this project. Such a situation can have a significant impact on the performance of the grid and the usefulness of the node.
Back to top
Remco
#10 Posted : Thursday, July 29, 2021 4:23:59 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
I've done a bit more experimentation around this issue. Right now it looks to me like the AppHost.exe error appears when attempting to build using the preview version of .NET6. Because MSBuild always rolls forwards into the preview versions under NCrunch (as described in the thread above), this means NCrunch will always use .NET6 unless specifically configured not to through the use of environment variables.

When VS2022 is installed, the issue seems to disappear. This suggests that .NET6 has some kind of dependency on VS2022, which makes sense given that a normal installation of VS2019 can't seem to target .NET6 under project configuration even when it is installed.

I haven't yet managed to test this using the VS2022 Build Tools, so I can't say if installing this is likely to solve the problem. Given that you have an environment which I expect has .NET6 and the VS2022 Build Tools installed and the problem appears, my expectation right now is that installing VS2022 Build Tools will not solve this problem.

At the moment I am sceptical as to whether we can actually work around this problem in NCrunch, even when we understand it fully. I'm reluctant to commit serious work to trying to find a way to solve it given that this seems to be a problem existing between MS toolsets which are all in a preview state. Spending two weeks ineffectively trying to solve this would be a tragic waste if the problem magically went away with the next preview build of .NET6. This is the reason we don't usually implement support for preview tooling (VS2022 was an exception to this policy).

We'll revisit this when the 2022 toolstack is more mature. If the problem still exists around RTM, we'll have no choice but to try and introduce hacks or workarounds. Personally, I think the problem will likely be gone long before then.
Back to top
1 user thanked Remco for this useful post.
rgwood on 8/18/2021(UTC)
MarcChu
#11 Posted : Tuesday, August 3, 2021 3:26:33 PM(UTC)
Rank: Member

Groups: Registered
Joined: 9/26/2014(UTC)
Posts: 22

Thanks: 3 times
Was thanked: 1 time(s) in 1 post(s)
An interesting new revelation is that the one working grid node server now no longer builds after a restart.

All grid nodes have Visual Studio Build Tools 2022 Preview installed, 17.0.0 Preview 2.1. They also all have SDK 6.0.100-preview.6.21355.2 installed, and at least 5.0.302 and 5.0.101 also.

Whenever a new version of VS comes out and I update to it locally, I manually update all of the grid node environments using Visual Studio Installer. I would assume that this should make all environments identical, but I always also run into the warning that "Compiler results are not consistent between machines in the grid." This warning has always confused and vexed me.

I agree it's not worth the effort to try to find a fix for the moving target that is a preview version. But it would be nice to be able to get this to work using the custom build properties, assuming the currently available facilities should work.
Back to top
Remco
#13 Posted : Thursday, October 14, 2021 5:01:22 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
I've eventually caved on this and implemented a workaround in NCrunch to get us around this problem.

Essentially, NCrunch will now try to detect a scenario when the IDE is operating in non-preview mode while a preview SDK is installed on the system. When this happens, NCrunch will set the DOTNET_MSBUILD_SDK_RESOLVER_SDKS_* environment variables itself to force the underlying system to use the latest non-preview SDK installed on the system. So basically we're automating the steps suggested in the thread above so that it shouldn't be necessary for people to do these themselves.

The downside is that the workaround is not perfect. We're emulating the search logic performed by the toolset when it tries to find the SDK, and there's quite a bit of implied stuff .. which increases the risk of something breaking in future. Unfortunately, it doesn't look to me like this problem will entirely go away when VS2022 hits RTM, as MS are always going to release preview tools and we can't just keep failing like this, hence the workaround. Hopefully we won't need to deal with this again now.

The workaround is implemented in the v4.10 build just released.
Back to top
 |  Edit by user
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.115 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download