NETSDK1145: 'The Apphost pack is not installed' error while building C++\CLI project (targeting .NET 5) with Visual Studio 2019 16.11.1 if Visual Studio 2022 17.0.0 Preview 3.1 is installed

[bairog]

Hello.
I have C++\CLI project (targeting .NET 5) that was building correctly with latest Visual Studio 2019 16.11.1 yesterday.
Today I've installed Visual Studio 2022 17.0.0 Preview 3.1 (than includes .NET 6 preview 7). And today I cannot build my project:

C:\Program Files\dotnet\sdk\6.0.100-preview.7.21379.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkRefere
nceResolution.targets(127,5): NETSDK1145: The Apphost pack is not installed and NuGet package restore is not supported. Upgrade Visual Studio, remove global.json if it specifies a certain SDK version, and uninstall the newer SDK. For more options visit https://aka.ms/targeting-apphost-pack-missing Pack Type: Apphost, Pack directory: C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86, targetframework: net5.0, Pack PackageId: Microsoft.NETCore.App.Host.win-x86, Pack Package Version: 5.0.8.

Strange thing is that now C:\Program Files\dotnet\sdk\6.0.100-preview.7.21379.14\Sdks\Microsoft.NET.Sdk is used to build my C++\CLI project (targeting .NET 5)..

In C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86 the following folders are present:

Adding this to MyProject.vcxproj (as recommended at https://aka.ms/targeting-apphost-pack-missing) changes nothing:

<ItemGroup>
  <KnownAppHostPack Update="@(KnownAppHostPack)">
    <AppHostPackVersion Condition="'%(TargetFramework)' == 'TARGETFRAMEWORK'">5.0.9</AppHostPackVersion>
  </KnownAppHostPack>
</ItemGroup>

.NET SDK 5.0.8 refuses to install because a newer version (5.0.9) alsready present in my system.

Any help is appreciated.

[bairog]

BTW. Docs page https://aka.ms/targeting-apphost-pack-missing (which actually leads to https://docs.microsoft.com/en-gb/dotnet/core/tools/sdk-errors/netsdk1145) has absolutelly same XML code for both For apphost pack block and For targeting pack block. Is that by design or a misprint?

[KalleOlaviNiemitalo]

The docs issue has been filed as dotnet/docs#25073.

[elinor-fung]

@bairog The TARGETFRAMEWORK in that snippet is also a placeholder. In your case, it should be net5.0. Can you try with that updated?

[bairog]

@elinor-fung Adding this to MyProject.vcxproj changes nothing:

<ItemGroup>
  <KnownAppHostPack Update="@(KnownAppHostPack)">
    <AppHostPackVersion Condition="'%(TargetFramework)' == 'net5.0'">5.0.9</AppHostPackVersion>
  </KnownAppHostPack>
</ItemGroup>

Even if we make this workaround to work - it's hardly acceptable for our company. Our company has 50+ C++\CLI projects in a solution - it will be a real pain to modify them all..

P. S. I've also reported same problem at Developer Community and got a comment by @marcpopMSFT :

The 6.0 preview 7 SDK was prepared before 5.0.9 was available so it includes version 5.0.8 in its implicit version targeting for 5.0. You can disable loading of preview versions of the sdk in 16.11 to get unblocked, install 5.0.8, or add a knownapphostpack reference to the project to work around this: https://docs.microsoft.com/en-us/dotnet/core/tools/sdk-errors/netsdk1145

So my questions are:

1. Did I understand correctly that this problem will disappear when a .NET 6.0 preview 8 will be released? And will appear again when for example Visual Studio 2019 16.11.vnext (containing .NET 5.0.10) will be released aftewards?
2. Why Visual Studio 2019 (Vusial Studio 2022 works the same way - I've already tested) compiles my C++\CLI project that targets .NET 5.0 with .NET 6.0 SDK? I expect it to be NET 5.0 SDK..
3. Why does this problem affects only C++\CLI project compilation? My C# projects compile with no errors..
4. When Visual Studio 2019 compiles my project and there is no .NET Apphost 5.0.8 present in my system - why doesn't it simply try to select a higher version (5.0.9 that is present)? I've expected it to work the same way like .NET version roll-forward..

[elinor-fung]

Another thing to note is that the item group with the KnownAppHostPack item update needs to come after the import of Microsoft.Cpp.targets (at the bottom of the project for a new vcxproj).

Using a Directory.Build.targets could help with sharing across all projects.

I just hit this issue myself (on a simple solution), so I'm just commenting based on my experience applying the workaround. Definitely not familiar enough with the SDK or how it integrates with VS - so I'll leave your questions for folks like @marcpopMSFT and @wli3.

[bairog]

Another thing to note is that the item group with the KnownAppHostPack item update needs to come after the import of Microsoft.Cpp.targets (at the bottom of the project for a new vcxproj).

Thank you for a workaround, my sample project builds correctly now.

Using a Directory.Build.targets could help with sharing across all projects.

Thank you again, I will try it.

Definitely not familiar enough with the SDK or how it integrates with VS - so I'll leave your questions for folks like @marcpopMSFT and @wli3.

All my 4 questions are still relevant - so let's wait for the answers and clarifications..

[wli3]

1. Did I understand correctly that this problem will disappear when a .NET 6.0 preview 8 will be released? And will appear again when for example Visual Studio 2019 16.11.vnext (containing .NET 5.0.10) will be released aftewards?

Correct. Unfortunately, C++/CLI scenario does not work well when both VS and stand alone SDK (not the SDK version come along with VS). Try to avoid this scenario if you could.

2. Why Visual Studio 2019 (Vusial Studio 2022 works the same way - I've already tested) compiles my C++\CLI project that targets .NET 5.0 with .NET 6.0 SDK? I expect it to be NET 5.0 SDK..

By default VS will use the highest SDK compatible with that VS. Although SDK is backward compactable.

3. Why does this problem affects only C++\CLI project compilation? My C# projects compile with no errors..

This is caused by implementation detail. C++ and C++/CLI project system does not support nuget currently. And SDK uses nuget to download the missing Apphost and targeting pack in C# scenario. We are working on that.

4. When Visual Studio 2019 compiles my project and there is no .NET Apphost 5.0.8 present in my system - why doesn't it simply try to select a higher version (5.0.9 that is present)? I've expected it to work the same way like .NET version roll-forward..

Targeting pack and apphost does not roll forward. Each SDK has a list of hard coded version of such packages to use. You can override that with the snippet in https://aka.ms/targeting-apphost-pack-missing. Btw I just fixed the targeting pack snippet.

[bairog]

Correct. Unfortunately, C++/CLI scenario does not work well when both VS and stand alone SDK (not the SDK version come along with VS). Try to avoid this scenario if you could.

That is not my scenario. I had VS 2019 16.11.1 (comes with .NET 5.0.9) beforehand and after that I've installed VS 2022 17.0.0 Preview 3.1 (includes .NET 6 preview 7). Is this also a "bad" scenario? How to avoid it if I want to try a preview of a next gen VS?

By default VS will use the highest SDK compatible with that VS. Although SDK is backward compactable.

It there a way to change that default behaviour? I mean how to force VS 2019 to compile a project targeting .NET 5.0 with .NET 5.0 SDK (even if .NET 6.0 SDK is present and VS 2019 can use it).

This is caused by implementation detail. C++ and C++/CLI project system does not support nuget currently. And SDK uses nuget to download the missing Apphost and targeting pack in C# scenario. We are working on that.

Is there an estimated timeframe for this work? Are you planning to complete it till VS 2022 release?

Targeting pack and apphost does not roll forward. Each SDK has a list of hard coded version of such packages to use. You can override that with the snippet in https://aka.ms/targeting-apphost-pack-missing. Btw I just fixed the targeting pack snippet.

Thank you for a fix. I think on that page it should be directly mentioned that both TARGETFRAMEWORK and EXISTINGVERSION are the placeholders. Thank you in advance.

[wli3]

If you have both VS installed instead of VS and a standalone SDK, it should work. I'll look into that.

[marcpopMSFT]

Basically, this is a problem when installing previews along with the prior version. In this case, VS 2022 came with the 6.0 SDK which included an implicit reference to the 5.0.8 runtime. VS 2019 will automatically pick up that SDK and lead to you having 5.0.9 installed (which works for most scenarios as we use nuget package restore for many other scenarios but we can't for c++/CLI so it gets impacted most). Our preview SDKs are done in public so don't include the latest runtimes (which can contain security fixes so are prepared internally) for downlevel targeting.

Besides the directory.build.props option, you can also use a global.json to force it to use the 5.0 SDK. I normally don't recommend global.json (as there can be unexpected side-effects to doing so) as typically we encourage using the newest shipped SDK but in this case, it's a preview.

If you only build in VS, you can also disable the checkbox in VS 2019 to load preview SDKs (search for preview features under the tools options menu) so VS 2019 will then not load the 6.0 preview SDK. The command line will still automatically choose the most recent SDK though.

[bairog]

If you have both VS installed instead of VS and a standalone SDK, it should work. I'll look into that.

Basically, this is a problem when installing previews along with the prior version.

@wli3 @marcpopMSFT From my point of view these two phrases contradicts each other. So actually is it a supported scenario to have a stable VS 2019 along with preview VS 2022 on the same PC? If not - how does Microsoft supposes that I will test the upcoming VS 2022 AND keep my current sources (targeting .NET 5.0) buildable with VS 2019 (both from IDE and command line)?

P. S. Just updated to latest VS 2022 17.0.0 Preview 4.0 (includes .NET 6 RC1) and VS 2019 16.11.3 (comes with .NET 5.0.10) - for today my applications (that target .NET 5.0) successfuly build even without KnownAppHostPack hack. Great!

If you only build in VS, you can also disable the checkbox in VS 2019 to load preview SDKs (search for preview features under the tools options menu) so VS 2019 will then not load the 6.0 preview SDK. The command line will still automatically choose the most recent SDK though.

I build both in VS and from command line.

[bairog]

Just updated to latest VS 2022 17.0.0 Preview 5.0 (includes .NET 6 RC2) and VS 2019 16.11.5 (comes with .NET 5.0.11) - for today my applications (that target .NET 5.0) still successfuly build even without KnownAppHostPack hack.

So once again:

If you have both VS installed instead of VS and a standalone SDK, it should work. I'll look into that.

Basically, this is a problem when installing previews along with the prior version.

@wli3 @marcpopMSFT From my point of view these two phrases contradicts each other. So actually is it a supported scenario to have a stable VS 2019 along with preview VS 2022 on the same PC? If not - how does Microsoft supposes that I will test the upcoming VS 2022 AND keep my current sources (targeting .NET 5.0) buildable with VS 2019 (both from IDE and command line)?