Recently I was working on a technical question and proof of concept about being able to reuse the BizTalk mapping designer functionality. The goal was to be able to reuse the functionality within a business user application to enable an information worker to create a map. One of my personal goals was to try to do this in an environment that did not incorporate Visual Studio. This is challenging because until recently with BizTalk 2010 there was not really any way (that I know of) to export or hijack the BizTalk extensions from Visual Studio and reuse them in a separate non development environment.
With the BizTalk 2010 beta it has been possible to develop message transforms within the VS 2010 workflow projects once you install the WCF LOB SDK beta. A Windows workflow (WF) activity known as the BizTalk mapper activity shows up in the VS toolbox. A few other articles exist on using this activity, see the following for a good summary: http://seroter.wordpress.com/2010/05/24/using-the-new-biztalk-mapper-shape-in-a-windows-workflow-service/.
I decided that it would be interesting to know whether or not you could work with this activity within a WF rehosted environment because this would provide the ability to reuse the mapper functionality in a partial trust, non VS environment. A WF rehosted environment provides a lighter-weight visual editing environment for a workflow that is either stopped or running.
This post shows what I encountered when trying to rehost and manipulate a workflow that use the BizTalk mapper. Unfortunately I found that in the current beta it is not possible to easily manipulate the BizTalk mapper activity in a rehosted workflow. Upon further investigation, the API for the mapper depends on the presence of Visual Studio and simply compiling a project that references the mapper toolbox activity requires extensive Visual studio references. Hopefully this post will save you some time from trying to do this yourself.
To start out with a good basis for the test, I found a blog post which provided a good WF 4 rehost sample. I chose the one at http://msmvps.com/blogs/theproblemsolver/archive/2009/12/23/rehosting-the-workflow-designer-in-wf4.aspx. Thanks to Maurice for this great WF 4 post. Basically this enables you to open an Activity.xaml file for a coded workflow and then view it in the rehost environment with the toolbars at the left like in VS. To add the BizTalk mapper activity I did the following steps:
1. Directly referenced the assemblies relating to the BizTalk Mapper activity. Below I give a little more detail on these:
- Microsoft.ServiceModel.Channels.MapGenerator – Creates the cs or vb code for the code behind of the map.
- Microsoft.ServiceModel.Channels.MapperActivity – WF 4 activity classes, and also includes the type selector form pop up form that generates the BizTalk schemas and default maps.
- Microsoft.ServiceModel.Channels.MapperToolboxItem – additional packaging that basically wraps the MapperActivity but relies extensively on the VS packaging assemblies.
2. Then I started trying to build the project for the new references because I want to try to manipulate a workflow with the mapper activity already added in and/or add it to a new workflow. To help with this I opened the three assemblies above in Reflector to look at the references. Quickly we see that the MapperActivity assembly does itself rely on Microsoft.VisualStudio.Shell.Interop (v. 7.1 so this is VS 2003) as well as the BizTalk mapper compiler.
If you keep all three of the assemblies from #1 referenced then you have to also reference a couple of other VS assemblies commonly used with VS extensions (obviously the MapperActivity was not meant for use outside of VS):
- Microsoft.VisualStudio.Shell.Interop (v. 7.1)
- System.Drawing (for basic ComponentModel extensibility)
Basically to illustrate some of these dependencies, here are the first and third assemblies in reflector with references shown:
Then here is the second one for the MapperActivity:
You can also see that the MapperActivity relies on EnvDTE (related to VS) and also ole32.dll (unmanaged code).
3. Also add reference to Microsoft.XLANGs.BaseTypes.dll for handling the BizTalk type system and some other essentials.
4. Add code for adding the Mapper activity to the constructed toolbox:
// Add the BizTalk mapper var bizTalkcat = new ToolboxCategory(“BizTalk Activity”); var assembliesBTS = new List(); assembliesBTS.Add(typeof(Microsoft.ServiceModel.Channels.MapperActivity.MapActivityDesigner).Assembly); var queryMapper = from asm in assembliesBTS from type in asm.GetTypes() where type.IsPublic && !type.IsNested && !type.IsAbstract && type.ContainsGenericParameters // Only matches the Mapper activity select new ToolboxItemWrapper(type.FullName, type.Assembly.FullName, null, “MapperActivity”); queryMapper.ToList().ForEach(ti => bizTalkcat.Add(ti)); toolbox.Categories.Add(bizTalkcat);
This is because the Mapper activity relies on the EnvDTE project that does not exist outside of VS. I will attempt to do some other workarounds for managing the mapper activity outside of VS but for now it looks like the mapper is restricted to use within VS. I welcome all comments on other approaches to making this work. Also, the code for my attempts so far may be found here: Ben’s SkyDrive public folder
One quick errata, it relies on the EnvDTE assembly (not "project").
Update if you figure out the work around, that was a good read.
I updated the download link for these files. Something changed with the Live Spaces move and the link got broken. Sorry to those who were trying to access the files. Thanks.
Have you tried with the VS shell only?
Zack, no I have not tried this. How does this work?
I have not tried this, but if that is the only dependency, you could try to use the VS 2010 SDK to create a VS isolated shell application and then try to host the WF 4 designer and the mapper in that? Not sure how that would play with the rest of your app though.
Sadly you get the same message if you try to host the BizTalk Mapper in a Visual Studio 2012 workflow project. It really makes you think twice about using the BizTalk mapper in workflows as this means you have to wait for a BizTalk upgrade to use it and you might not upgrade BizTalk versions as fast as you move along in the Visual Studio versions and workflow foundation editions