Publishing standalone app (C#) fails with C++/CLI dependency

[chrisbardon]

I'm trying to port a WPF app (C#) to core 3.1, but it has a dependency on a C++/CLI managed wrapper on an unmanaged DLL. The dependency works, and I can build/run and publish as Framework Dependent, but I get a failure when I try to publish self contained. The error that I get in VS 16.5.4 is:

Publish has encountered an error. Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.

And the .tmp file it generates tells me:

4/21/2020 8:58:07 PM System.AggregateException: One or more errors occurred. ---> System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. --- End of inner exception stack trace --- ---> (Inner Exception #0) System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---

System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.

Which is not helpful... The publish output however, had this buried in it:

3>Task "NETSdkError" skipped, due to false condition; ('$(Language)' == 'C++' and $(EnableComHosting) == 'true') was evaluated as ('C++' == 'C++' and == 'true'). 3>Using "NETSdkError" task from assembly "C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets..\tools\net472/Microsoft.NET.Build.Tasks.dll". 3>C++/CLI projects targeting .NET Core cannot use SelfContained=true. 3>Building with tools version "Current".

That implies that there's no way to build this as a self contained application, which was part of the motivation for going to .net core with this app in the first place (zero dependency deployment). Is there a way to get this to work, or is it a bug?

[ghost]

Tagging subscribers to this area: @ViktorHofer Notify danmosemsft if you want to be subscribed.

[ghost]

Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar Notify danmosemsft if you want to be subscribed.

[vitek-karas]

I think this is because we don't allow loading "components" as self-contained. Is that right @jkoritzinsky ?

[jkoritzinsky]

Building a self-contained C++/CLI application is not supported, but I remember some discussions with the SDK team about if C++/CLI dependencies of a self-contained C# app should be supported. @wli3 do you remember where we landed on that?

[wli3]

C++/CLI dependencies of a self-contained C# app should be supported.

That is true. From the error code message $(Language) is evaluated to C++. It might be caused by running /t:publish in the folder. So all projects get published. Maybe try only publish the WPF project.

[CrapuleJack]

Just for the record, I too am having the same problem. I hope this is a feature .net 5 will bring.

For now I rely on the fact that my app directs the user to download and install the CLR at first run, wich is not ideal. A self-contained publish would be.

[FunksMaName]

I am experiencing this issue as well, and it would be great if Microsoft can just provide an official stance on the state of affairs, by clearly stating this limitation on their documentation, here are a few places to start:

Your official documentation page on publishing self contained apps for various runtimes https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli

Blog entry touting the new C++/CLI project prowess which does not state this very important limitation https://devblogs.microsoft.com/cppblog/porting-a-c-cli-project-to-net-core/

It's a very clumsy experience for our end user when we now have to make them download the Runtime prior to our app installation.

[FunksMaName]

@wli3 Just to remove any ambiguity, attempting to self contained publish just the project which takes a dependency on the C++/CLI project as you appear to suggest does not work either. This is what I get

C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(181,5): error NETSDK1121: C++/CLI projects targeting .NET Core cannot use SelfContained=true. [C:\Dev\yyy\src\yyy\yyy.Driver.Bridge.vcxproj]

[CrapuleJack]

An other option would be to provide a .netcore runtime merge module I could include in my setups .msi, but I cant find those if they exists, anyone knows about that?

This would be an alternative but the ideal would still be self contained deploy.

[FunksMaName]

@CrapuleJack my work around was to a WIX Bundle project to install the dependency, if you are using wix then here is a reference

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" 
     xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
	<Bundle 
    Name="YYYY Driver Installer (Bundle)" 
    Version="1.0.0.0" 
    Manufacturer="YYYY" 
    UpgradeCode="F6396F05-BEDF-4B14-AD41-57C91CBC8772"
    IconSourceFile="app.ico">
    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
      <bal:WixStandardBootstrapperApplication
        LicenseFile="License.rtf"
        LogoFile="Logo.png" />
    </BootstrapperApplicationRef>
    <Chain>
	  <!-- Dot Net Hosting Runtime exe
	  (the command -q seems to make it install silently but not documented anywhere)  -->
      <ExePackage SourceFile="dotnet-hosting-3.1.5-win.exe"
                  InstallCommand="-q"
                  UninstallCommand="-q">
        <ExitCode Value="0" Behavior="success" />
      </ExePackage>
      <RollbackBoundary />
      <!-- Your Product MSI -->
      <MsiPackage 
        SourceFile="YourInstallationMSI.msi"
        DisplayInternalUI="no" /> 
    </Chain>
	</Bundle>
</Wix>

Some resources around WIX Boostrapping https://stackoverflow.com/questions/47399366/wix-how-do-i-launch-another-msi-or-exe-inside-my-installer-c https://www.firegiant.com/wix/tutorial/net-and-net/bootstrapping/

[CrapuleJack]

@FunksMaName Thanks a lot for that, I will take a look at that for sure. Yes I am using wix, it is awesome.

[vitek-karas]

I moved this to dotnet/sdk as the issues seems to be around failures during publish.

[l0hn]

Will this be supported in .net 5? We have spent quite a long time porting a project over and have just hit this issue.

[Proudloaf]

Also had this problem attempting to create an MSIX install from Visual Studio. Previously our .Net framework WPF + CLI install worked fine, now we have upgraded to .net core 3.1 WPF +CLI and everything works fine apart from publishing to MSIX where we get: "C++/CLI projects targeting .NET Core cannot use SelfContained=true." Even if we accept that we can't use SelfContained I can't seem to get the MSIX to do a Framework-dependent publish either. I really don't want to go back to .Net framework but I'm running out of options. Anyone got any advise?

[ZenoArrow]

Is fixing the standalone/self-contained C++/CLI issue on the roadmap for .NET 5? This is blocking our preferred update strategy.

[zhuman]

I think it's quite puzzling that this wasn't considered a ship-blocker for .NET Core 3.1 and .NET 5.0. There is no technical blocker to publishing a self-contained deployment that happens to include a C++/CLI dependency. Nuget packages that contain C++/CLI assemblies do not suffer from this SDK error message (since they are just seen as managed dependencies). This is in fact a workaround for this problem; people have to package up their component as a Nuget package and reference it from the other managed assemblies, which is a silly amount of work.

It was mentioned above that this error exists to discourage people from trying to ship self-contained "components" where a native host loads a C++/CLI assembly as a native component. However, this is likely a very edge-case scenario, whereas shipping a fully managed EXE as self-contained that happens to also have a C++/CLI project in its dependency graph is an extremely common scenario, especially for people porting .NET framework apps to .NET core. This should be a well-tested scenario by the donet/SDK teams, but clearly it's not as it's blocked by this SDK error. All that really needs to be done here to fix the SDK is to prevent the error from being issued if the user has somehow declared they are not shipping a standalone "native component" DLL.

For anyone that comes here looking for answers, a quick workaround is that you can add the following lines to your .vcxproj files after Microsoft.Cpp.targets file is imported.

<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />

<!-- Disable the .NET SDK error that prevents using SelfContained=true -->
<Target Name="_CheckForLanguageAndFeatureCombinationSupport"></Target>

[scnanney]

Please fix this.

[AndreyMikhailov]

Just faced this problem. Thought this would be fixed in .net 5.0. But sadly no.

Also zhuman's advice helped. Thank you.

[daerlnaxe]

Same problem

[mjfusa]

Same problem as @Proudloaf with Windows App SDK app with C++ CLI dependency. App builds and run fine, but get errors when attempting to create app packages. Unfortunately @zhuman suggestion didn't work for me. However the error is now different: Severity Code Description Project File Line Suppression State Error Assets file 'C:\p\Test1\Test1\Test1\obj\wappublish\win10-x86\project.assets.json' doesn't have a target for 'net5.0-windows10.0.19041.0/win10-x86'. Ensure that restore has run and that you have included 'net5.0-windows10.0.19041.0' in the TargetFrameworks for your project. You may also need to include 'win10-x86' in your project's RuntimeIdentifiers. Test1 (Package) C:\Program Files\dotnet\sdk\5.0.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets 242

[damien78]

@mjfusa When the C# project has a target framework with Windows build specifiied (e.g. <TargetFramework>net5.0-windows10.0.17763.0</TargetFramework>), and not just <TargetFramework>net5.0-windows</TargetFramework>, you need to also specify in the same property group, the RuntimeIdentifiers, like <RuntimeIdentifiers>win-x64</RuntimeIdentifiers> Example of such property group in the WPF .csproj file:

<PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows10.0.17763.0</TargetFramework>
    <UseWPF>true</UseWPF>
    <Platforms>AnyCPU;x64</Platforms>
    <RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
  </PropertyGroup>

This update then enables to build the app packaged, and run the packaged app from Visual Studio. But now I'm stuck with the next roadblock when trying to create the .appx for publishing (Using the WAP project Publish > Create App Packages...) command, with a NuGet restore error: 1>The runtime pack for Microsoft.NETCore.App.Runtime.win-x64 was not downloaded. Try running a NuGet restore with the RuntimeIdentifier 'win-x64'.

This error happens with either Visual Studio 16.11.1 and .NET5.0, or 17.0.0 Preview 3.1 and .NET6.0 preview

[dsplaisted]

@damien78 Could you try setting the RuntimeIdentifier property instead of RuntimeIdentifiers? Just a guess, but that might fix the issue.

[damien78]

@dsplaisted Thanks, but no luck with this. Build successful, but same error when creating the packages

[pantonis]

Come on guys. Provide a fix on that. Its been 2 years

[ZenoArrow]

Any updates on when this is likely to be fixed? I can see it's been added to the 6.0.3xx milestone, what's the expected best and worst case scenario in terms of when this can be done in this milestone?

[pantonis]

Please provide an update. This is a very important feature for anyone.

[Proudloaf]

Agreed, this is crazy - it seem to be a simple fix, please if it is more complicated let us know and we can make alternative plans.

[pantonis]

@marcpopMSFT so this is moved to .NET7? In 6+ months? Very very sad

[jeffward01]

@marcpopMSFT so this is moved to .NET7? In 6+ months? Very very sad

This ticket has been an active and open ticket for 2 years already. It seems that this should take priority as it is an internal function of .NET Framework versus 'new features' in net7.0

[ZenoArrow]

@marcpopMSFT so this is moved to .NET7? In 6+ months? Very very sad

It's not even clear that this will be released with .NET 7. I haven't seen evidence that it's included in the .NET 7 alpha releases. Just seems like another delaying tactic. I honestly don't know why this isn't being treated as a higher priority issue, would be good to understand the complexity in making a fix.