I'm attempting to ILMerge a couple of the control DLLs into another DLL and am having problems where the controls are not able to be loaded at run time. My assumption is that I would need to implement something like what is suggested here for the WinForms controls, but can not find any pre-existing forum discussions or articles on the subject.
Am I missing something, any thoughts/suggestions?
Thanks!
8 Answers, 1 is accepted
Unfortunately the WPF assemblies are not specifically designed to support such a merge. And as we haven't received any requests or queries regarding the ILMerge tool, I'm not sure if there is a workaround for your case.
Regards,
Tina Stancheva
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
We also require to use the ILMerge to merge our exe/dlls into one single application exe. If its not possible to use ILMerge is there another way this can be done?
thanks
The way I ended up resolving this issue was to include the ProvideBindingPath attribute on my VSPackage class file (in my context I was working on a Visual Studio Extension). What this does is it adds the directory where your extensions assemblies reside (after installing the extension) to the list of directories to be probed for assemblies that otherwise can't be found (because they don't exist in the default probing path).
In Visual Studio 2010, you can find the attribute class file here, included in the VS SDK:
%VSSDKInstallDir%\VisualStudioIntegration\Common\Source\CSharp\RegistrationAttributes\ProvideBindingPathAttribute.cs
In Visual Studio 2012, the class is included in the VS Visualization and Modeling SDK:
http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.modeling.shell.providebindingpathattribute.aspx
You add the attribute like this:
[ProvideBindingPath]
public
class
YourPackageName : Package { ... }
Unfortunately the IlMerge tool can't work with WPF assemblies properly as noted in the product page of the tool - http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx:
"Merging WPF assemblies
ILMerge is not able to merge WPF assemblies. They contain resources with encoded assembly identities. ILMerge is unable to deserialize the resources, modify the assembly identities, and then re-serialize them. Sorry! "
However, as Telerik now provides no-xaml assemblies, you can use the IlMerge tool to merge multiple Telerik WPF no-xaml assemblies into one and then reference the merged assembly in your solution. With this approach, you'll have to keep in mind that the assemblies don't specify any style resources so you'll have to use an implicit styles approach similarly to the ones described in this tutorial. Also, please make sure to update the alias of the Telerik namespaces in the style files/ResourceDictionaries as by default they come from the Telerik assemblies and as soon as you merge the assemblies toghether, you'll have to change namespace definitions accordingly.
Still, using IlMerge to merge our assemblies along with a WPF project exe file doesn't work. And the reason is in the IlMerge implementation as described in the tool product information. And if this is your goal, you'll have to use another tool or follow the workarounds suggested by the IlMerge authors:
I hope this information helps.
All the best,
Tina Stancheva
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
I've just posted a blog related to this. You can check it here:
http://blogs.telerik.com/vladimirenchev/posts/13-01-15/how-to-merge-assemblies-into-wpf-application
Vlad
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
As you are the only post in the entire WPF forum to mention VSPackage, I was wondering if you could comment on using the Telerik WPF controls within a Visual Studio Extension project. I like what I have seen so far and I am considering purchasing a full license but I would like to know if they work within a VSPackage, from this post it sounds like you had some issues with deployment. Any comments you have on your experience would be greatly appreciated.
Thanks,
Frank
Our internal VS extensions are still using the methodology I outlined above. It has been working completely fine for us and we have not encountered any issues over the last couple of years with this implementation. Please let me know if there's anything else I can help with, and if your question is not directly related to this forum post, you can reach out to me using the contact information on my website: http://www.gotdibbs.net/
Cheers,
Will