Can a wpf application be deployed without compiling the xaml?
Is it possible to deploy a WPF windows application in such a way that the xaml files can be manipulated at run-time? If possible, I would imagine this would work similar to an asp.net application that can deploy the .aspx pages as content, which are then compiled just-in-time at run-time.
I'd like to allow the simple layout of a screen to be edited at run-time by editing the XAML. Does anyone know if this is possible?
Edit: When I refer to xaml files, I mean the corresponding xaml to my UIElement classes. In other words, I have defined UserControl classes using Xaml and code-behind, inheritance, event handlers, assembly references, etc. When deployment time comes, I'd like to be able to keep the code-behind functionality but still allow the xaml to be edited.
I have another suggestion for you - the real question was:
"I'd like to allow the simple layout of a screen to be edited at run-time by editing the XAML. Does anyone know if this is possible?"
The answer is definitely, "YES"! And there are many ways to achieve this, making a few assumptions of course.
If you have no need to handle events or write custom value converters (or anything else that would normally go in the code behind) in the "dynamic" part of your XAML, then you can simply use the XamlReader class to parse a XAML file or string containing XAML. Since you are merely editing the layout, I expect that these assumption holds true.
So, here is what I would do:
1) Write all your custom controls, data models, value converters, etc, and stick them in an assembly.
2) Load that assembly, either by having your app reference it or load it dynamically - both will work.
3) Create a string/file/resource (take your pick) that has your XAML that does layout, complete with the mapping of your .NET namespace to an XML namespace. Make sure you do not have an "x:Class" attribute on the root element as you have no code behind file! The string would use the standard WPF controls (like the StackPanel) to layout your custom controls. (Of course you can also write custom layout controls).
4) Allow the user to edit this string. When they have edited it, use the XamlReader to parse the file and then display the resulting UIElement in your window.
One problem - everytime the XAML is changed, the GUI is tossed and a new one created. If your GUI is sateful (even if the current caret position is important), the user will get annoyed pretty quickly. It depend on what your intend use is - this may not be an issue.
I expect that with some more work, you could write a MarkupExtension that is used to refer to the parts that you are trying to layout. This way they could be reused when the layout changes.
I hope this is clear. If not, let me know and I can expand on the concept - it'd make a nice blog entry.
Thank you unthinkableMayhem for the reference.
The problem with loose XAML is that the XamlReader, when invoked at runtime, can not hookup events to functions in your assemblies, nor is there a mechanism to dynamically load assemblies. The way handlers for routed events are specified in XAML is one of the biggest design flaws of WPF/XAML and makes loose XAML next to useless.
The work I've done in embedding Dynamic Language Runtime (DLR) scripts in XAML is useful for both loose and compiled XAML. My intention was to make loose XAML a first class citizen in WPF by allowing routed events, commands, value converters and other XAML/WPF concepts available in loose XAML. I feel that this has been achieved (though my blogs don't mention dynamically loading assemblies, but this is straight forward).
If you persist, it is possible to deploy a WPF windows application in such a way that the xaml files can be manipulated at run-time. Heck, you can dynamically generate XAML with embedded scripts - no Assembly required. Man, that's one of the funniest things I've said for a long time.
Be warned though - the "X" in XAML is only a marketing term. It is not eXtensible from an engineering point of view, so expect a world of pain when you get off the path set out by Microsoft. I'll be happy to help if you go this way - contact details on my web site (www.thinkbottomup.com.au).