Deploying a non self-contained app that requires both x64 and x86 runtimes

• .NET Core Version: (e.g. 3.0 Preview1, or daily build number, use dotnet --info) 3.0 Preview 8

• Have you experienced this same bug with .NET Framework?: Yes/No No

Problem description: I’ve ported my application (https://github.com/mscrivo/ootd) to .net core 3 and have run into an interesting problem with the deployment scenario. According to what I’ve seen, the only supported deployment mechanisms for .net core 3 wpf/winforms apps are;

1. WSIX packaging
2. self-contained publish

Neither of these work for my app though, because it has to choose at runtime which platform to it needs to run. Essentially, the app places instances of the Outlook View Control on your desktop. So if you are running on Windows 64-bit, but are running 32-bit Outlook, the 32-bit version of my app needs to run in order for it to load the 32-bit COM component. So what I did in the .net framework world was have a launcher detect which version of Outlook you have installed and run the x64/x86 version of the app appropriately. Worked beautifully.

Now, with .net core 3.0, it seems I have to choose one or the other, I can’t publish a package which contains both x64/x86 runtimes, which means I can’t make my app work all scenarios:

windows x86 + office x86 windows x64 + office x86 windows x64 + office x64

The only way for me to make it work is to install both x64/x86 .net core SDKs on the users’ system, which is highly impractical.

Are there any plans to support a scenario like this? Is there some workaround I can use to make this work?

The easiest solution from my point of view, would be to include the WinForms/WPF runtime components in the .net core x64/x86 runtime installers. Then I can just install both of those on the users’ system and it would work.

Thanks!

[dagood]

Funny, I just commented on https://github.com/dotnet/core-setup/issues/7530#issuecomment-522103307 about this. It hasn’t been ported to release/3.0 yet due to that discussion. I’m skipping a decision on the branding to get something released for Preview 9. The tracking issue is https://github.com/dotnet/core-setup/issues/6384.

[nguerrera]

Seems like this can be closed against https://github.com/dotnet/core-setup/issues/6384, then.