Vihang,
I have reviewed your article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/WFDsgnRehst.asp
and was wondering if xoml only workflows with namespace references can be used with it?
BTW: Have you considered a web based version of this product?
I look forward to hearing from you soon.
Sincerely,
John Portnov
Jon has built a sample web based designer and you can see the "teaser avi" at http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,0a90c407-1173-4758-a199-d852c34cbbf6.aspx.
For the sample to use XOML only workflow, you will have to disable the checks for namespace whenever the workflow is loaded and you should be able to load the XOML only workflow. If you hace custom activities from referenced assemblies, make sure you add the assembly reference to the type provider when you load the workflow.
Hope this helps.
Vihang,
Can you please provide a code example? Where would this go in your example?
Sincerely,
John Portnov
Vihang,
I have tried to modify your example to deal with XOML only workflows, with some success, and these are the changes I made:
stopped emiting of code beside stuff
removed IMembercreationService and IEventBindingService from the loader and added references to my custom activity assemblies to the loader's TypeProvider. Both code compile units still in place.
The example expects the workflow XOML to have the x:Class attribute present, so I just made sure that there was a default available if there was none in the XOML.
I found that the WorkflowMarkupSerializer couldn't deserialize the XOML, (which have custom root activities), and I fixed this by passing in the host SerializationManager, (e.g. in PerformLoad), creating one when I needed to e.g.
WorkflowMarkupSerializer xomlSerializer = new WorkflowMarkupSerializer();
DesignerSerializationManager designerSerializationManager = new DesignerSerializationManager(serviceProvider);
using (designerSerializationManager.CreateSession())
{
rootActivity = xomlSerializer.Deserialize(designerSerializationManager, reader) as Activity;
}
all seemed fine until I attempted to create RuleConditions!
I have found that the RuleCondition dialog is only aware of my activities if my XOML has an x:Class attribute! It doesn't matter what it is, it just has to be present.
(NB The use of GetActivityByName and the necessary casting in my Rules is not going to be acceptable to customers).
Can you provide some insight here? What is the extra step I need to make to get this working?
incidentally, I found a small bug in ToolboxService ComponentClass property (breaking out of the foreach instead of returning the componentClass).
The final steps would be to somehow prevent the code generating options of the various dialogs from appearing.
The x:Class attribute tells the WF Designer about the DesignTime type systems defined in the WF and hence is absolutely necessary. Basically the WF type system looks for the DesignTime types defined in the type provided by the x:Class.
Hope this helps!
Thanks,
Kushal.
