Thus far in this series of blog posts I have started demonstrating how we can start implementing a “write once, use everywhere” or “develop once, distribute everywhere” methodology when it comes to developing Dynamics components. There are no true applications of this paradigm in the real world, as there is simply no platform commonality between all of available client-devices… but as Dynamics developers we only really care about Microsoft technologies and devices anyway!
My previous blog post articles focused on how we could write a simple WPF data entry form and encapsulate it as a UserControl and then deploy it to the “Dynamics-windows-rich-client” and then onto “Microsoft-Office-Excel”. This was a powerful concept and it meant that we could enforce the same UI and business logic for two different applications within one codeset. The next logical progression of this is to see if we can take this onto the web and into the cloud (woah there, one step at a time!)
I hear a question: Sharepoint runs on .net…? So, theoretically, we should be able to port our WPF UserControl into Sharepoint, right?
The answer to this question is “correct”, however, as with most things it comes with a number of caveats and compromises. “Out-of-the-box” Sharepoint won’t host or serve the types of files that are required to present WPF UserControls. Silverlight was designed to handle this type of functionality, but as mentioned previously, there are numerous restrictions in place when it comes to using the Silveright framework, most importantly being that you don’t get access to all the functionality! This is a huge problem if you want to write applications that leverage some of the latest features (like voice recognition).
Coming to the rescue is one of the more recent project types offered within Visual Studio: “WPF Browser Application”. Just as the description implies, this project type will allow you to re-host your WPF UserControl within a browser (specifically IE but other Active Directory capable browsers like Chrome will work). Your Xaml based WPF UserControl is compiled into a “web-hostable” package called an XBAP (Xaml Browser Application). This file comes with an executable and assembly manifest. All of these files need to be “signed-and-deployed” to an IIS webserver and run under a website with elevated priveleges (Sharepoint is capable of co-hosting this). Once deployed, a browser will present the WPF UserControl exactly the same as it is presented in Dynamics, windows-forms or wherever else you’ve used it. The last step of the process is to integrate the browser application into a Sharepoint webpart (using a configurable URL link) to make it seamlessly appear as though its being hosted within Enterprise Portal (I'll do a video demo of all of this).
“This is a lot of work”… I hear you all say… “and is the end result worth it?”
Well the answer is “yes”, if you truly want to implement the “write once, use everywhere” methodology… or you simply do not have the capacity to employ a large Sharepoint team. This doesn’t mean we do “do-away” with our Sharepoint specialists, because this functionality is only designed to work “within-your-organisation”. When you navigate to the XBAP deployment package for the first time, it downloads and installs itself locally so that subsequent invocations are fast. The machine on which it installs itself must have the .Net framework installed and access to all the referenced assemblies within your UserControl. For all of this to work seamlessly, a “trust” needs to be setup between the client machines and the server hosting the XBAP’s and this is done via certificates (and group policies).
· 3rd parties accessing your Dynamics instance (externally) via Sharepoint will not be machines that you can control and therefore all the pre-requisites will (potentially) fail. Silverlight must be used to provide rich-feature functionality in this case.
As you can see there are many pros and cons with this approach and there are a lot of setup components required to get this working, however, after successfully getting this working myself I’m beginning to see the real benefit in “single-click” deployment to multiple targeted platforms.
Over the next couple of weeks, I should have some quiet-time and I’ll be going through “step-by-step” on how to implement this successfully. Some of the initial articles may seem cumbersome and irrelevant (e.g. “certificate deployment”) but they are essential for understanding the concepts around “trust”... and “trust” is a big thing in the world of web-deployment.
I will be following up with some more articles over the festive season…
Happy Xmas All
Image may be NSFW.
Clik here to view.
