1

I am developing a WPF application and have a need for an icon in the System Tray. WinForms has the built in NotifyIcon class.

I see some developers going all out not to combine assemblies in an application. While others seems oblivious or blind to combining them.

Is it a bad idea to mix assemblies from both WinForms and WPF? What are the issues aside from obvious things like WPF being DPI independent.

Thanks, Michael

  • 3
    Given that Microsoft developed specific mechanisms to allow [Hosting a Windows Form Control in WPF](https://msdn.microsoft.com/en-us/library/ms751761(v=vs.110).aspx) (and [vice versa](https://msdn.microsoft.com/en-us/library/ms742215(v=vs.110).aspx)), I'd say it's okay. – Damien_The_Unbeliever Mar 30 '17 at 11:44

1 Answers1

2

The only real issue caused by mixing WinForms and WPF is maintainability.

When trying to add WPF functionality to none-WPF applications, you will need to import several WinForms assemblies, which will in many cases have very similar names to their WPF counterparts.

As a rule, it's a good idea to explicitly call any WinForms classes by their fully qualified name, rather than including a broad using statement.

The post here (C# trayicon using wpf) is a perfectly acceptable way to achieve what you're aiming to do, and will be the quickest option to get your project finished.

If you wish to work with just WPF, there is a nitify icon component which replicates the functionality of the WinForms notify icon - http://www.hardcodet.net/wpf-notifyicon

It's not best practice to mix approaches in this way, however in the real world when you need to get the job done, it's sometimes the most effective solution.

Community
  • 1
  • 1
Alex
  • 1,643
  • 1
  • 14
  • 32