Hello,
we're using several DevExpress controls for our own components and compile them as usercontrol libraries. For a good look and feel of our components we're also using a theme for all and setup it in the constructor via
C#Theme theme = new Theme("MetropolisLight", "DevExpress.Xpf.Themes.MetropolisLight.v13.2.dll");
ThemeManager.SetTheme(this, theme);
This works fine. Our components are standarized ones and they are used by several container applications from several manufactors. If a container application does not use any DevExpress components itself, there are no problems to instanciate and run our components within the container.
But if a container application uses DevExpress components itself (in eg. v13.2, 2013) and it's not the same version as in our components (v13.1, 2013), we always get an exception from the container application like this one:
---> System.Windows.Markup.XamlParseException: Zeilennummer "10" und Zeilenposition "10" von "Durch den Aufruf des Konstruktors für Typ "TE_Controls.DtmControl.DtmControl", der den angegebenen Bindungseinschränkungen entspricht, wurde eine Ausnahme ausgelöst.".
---> System.Windows.Markup.XamlParseException: Zeilennummer "10" und Zeilenposition "10" von "Durch den Aufruf des Konstruktors für Typ "TE_Controls.DtmControl.DtmControl", der den angegebenen Bindungseinschränkungen entspricht, wurde eine Ausnahme ausgelöst.".
---> System.TypeInitializationException: Der Typeninitialisierer für "DevExpress.Xpf.Utils.Themes.GlobalThemeHelper" hat eine Ausnahme verursacht.
---> System.ArgumentException: "PropertyMetadata" ist bereits für Typ "Window" registriert.
So, for test purposes I upgraded our components to the DevExpress version v13.2 (2013) and tested it by the concerned container application.
Now, all works fine! It seems, there's still a problem running an application that uses DevExpress components in one specific version wich tries to instanciate (independent) components that are using another specific version of DevExpress components.
How do I sail around this problem?
Is there a standard solution?
Hi,
In general, we don't recommend using several versions of our controls in a single assembly. Please check if it so in your application. Another possible cause of the issue is that not all the required assemblies are correctly deployed with your application. You can check it with our Assembly Deployment Tool.
Let me know your results.
Hi,
we are not using any controls with different versions from DevExpress in our assemblies . In the past we also made two deployments of our components. One is using your controls in V13.1 and the other uses controls in V13.2. So I guess that this problem is related to the different versions. The container applicatios I mentioned are exclusively developed by other companies where we have no influence in whose devlopment. Do you have another idea to fix this issue?
The recommended approach in this scenario is to use the same version of our controls in all modules. In this case, the conflict will not occur. Since the container application cannot be updated, it makes sense to update/downgrade your module. Is this acceptable for you?
Another possible approach is to use different versions of our controls in different namespaces. Please try it.
>In this case, the conflict will not occur. Since the container application cannot be updated, it makes sense to >update/downgrade your module. Is this acceptable for you?
No, this isn't an option for us. We don't want to have more than one deployment package for our components.
> Another possible approach is to use different versions of our controls in different namespaces. Please try it.
I'm not sure if I've understood it exactly what do you mean. Should we make a depolyment package with all possible versions for the DevExpress components? And if so, how should we do that in detail? When our plugins are instanciated at runtime, we're not able to determine the correct version of an installed container application.
And in addition it's possible that customers install a newer version of the respective container application wich could use a newer version of DevExpress than our components. So I think that this approach will cause many problems in the future.
Is there really no practical way how to bring both versions together?
I meant that you can explicitly use one version in one namespace and another one - in another - see How to use multiple versions of assembly. The deployment package should include all versions in this case.
However, I have found that this approach will now work with out controls. The exception you mentioned occurs because we override metadata for the Window type:
// GlobalThemeHelper static void RegisterNormalHandlers() { Window.ContentProperty.OverrideMetadata(typeof(Window), new FrameworkPropertyMetadata((d, e) => { Instance.AssignApplicationThemeName(((Window)d)); })); }As a workaround, I suggest you create an additional AppDomain and show your window there. I have attached a sample demonstrating this approach. Please take a moment to review it.
The approch in your sandbox example works fine. In our scenario the container application would have references to DevExpress libraries, a set theme and several plugins wich can also have an individual DevExpress theme.
I made several tests myself now how to use the different versions of DevExpress compononents (v13.1 and v13.2).
There is currently really no alternative first to create a new appdomain and then create and run the plugin with the new UI window in the new appdomain, since the use of themes is made.
But how would you integrate the UI of the plugin into another window of the main application? Is that possible?
For example we would like to integrate the plugin window from the 2nd appdomain into da Dockpanel from the main application.
Hi Oliver,
Yes, it is possible to use multiple application domains within one window. Please check the following articles to learn more: WPF Add-Ins Overview, managed addin framework (system.addin) with wpf, WPF: Hosting WinForms Control from Another AppDomain.
Thanks,
Alex
Hi Alex,
thank you for the link. I had already thought that the approach goes in this direction as described in the article.
You are welcome, Oliver. Drop me a line if you require further assistance.
Hello Alexander Ch,
Excuse me for posting this question here in the comments but I have almost the same problem but with a Silverlight application. Since I cannot create AppDomains in SL and cannot use Add-ins as described in your solution for WPF I assume this problem just cannot be solved for SL applications… but just in case maybe you could suggest something in my case as well?
Thanks,
Vitalii
Hi Vitalii,
To be honest, I cannot say for sure if using multiple versions of the same assembly is possible in Silverlight. However, I would avoid this scenario and use only one version of an assembly if it is possible.
Thanks,
Alex
Hello Alexander,
in the next time we want to upgrade our own usercontrols to version 15.2.5, wich are using components from DevExpress.
I would like to know if the approach is still necessary to use more than one appdomain, if there are several versions of the DevExpress components in use from one application.
Best regards.