search

dotnet / winforms

Windows Forms is a .NET UI framework for building Windows desktop applications.
MIT License
4.42k stars 985 forks source link

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

Closed mscrivo closed 5 years ago

mscrivo commented 5 years ago

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!

weltkante commented 5 years ago

Interesting, we have a similar scenario and so far I was assuming I could just publish the application as a AnyCPU library ("portable") so it can be loadable both into 32 bit and 64 bit processes, with a framework dependent 32bit/64bit loader process - did you try that approach? The framework dependent profiles don't seem to deploy WinForms/WPF so I was assuming its already part of the downloadable runtime, having to install the SDK on end user machines would be silly.

mscrivo commented 5 years ago

AnyCPU doesn't work for this scenario. To use the outlook view control, you need to explicitly compile against x86/x64. The launcher is AnyCPU and then launches the appropriate x64/x86 binary which hosts the control.

weltkante commented 5 years ago

I meant putting the main part of the application in AnyCPU (so it can be shared and doesn't need to be deployed twice) and then having a minimal stub as 32/64 bit. The AnyCPU application can then be loaded by the stub in the correct bitness.

My primary point is not AnyCPU though, it is the "framework dependent profiles", which don't seem to need to deploy WinForms/WPF. Did you try those? I would expect them to work without having the SDK installed.

zsd4yr commented 5 years ago

@weltkante that sounds viable to me.

@nguerrera Do you have any thoughts here? Am I correct in thinking that your team owns the different build options.

nguerrera commented 5 years ago

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.

My primary point is not AnyCPU though, it is the "framework dependent profiles", which don't seem to need to deploy WinForms/WPF. Did you try those? I would expect them to work without having the SDK installed.

@dagood Are there still no runtime installer bundles for WindowsDesktop? Framework dependent deployment of WPF or Winforms apps is basically broken without this.

dagood commented 5 years ago

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 commented 5 years ago

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