This blog has moved to http://blogs.msdn.com/b/appfabric please update your links!
Recently I saw a message on the WF4 Forum where someone was asking for help learning how to consume a WCF service from a Workflow.
In this post I’m going to walk through how you can consume a WCF service from a Workflow where both the service and the workflow live in the same web site. This should be simple, but unfortunately it is not as simple as it should be.
A standard WCF service reference was created but the generated client class is not an activity. You could create a CodeActivity (or better yet an AsyncCodeActivity) to use the generated class but really that is not the best solution.
The problem is that there are 2 implementations of Add Service Reference. The original one (let’s call it ASR-Code) which generates the typical code based client classes and then another one we call ASR-XAML which generates a XAML based WF client proxy.
How do we know which one to invoke when you right click and say Add Service Reference? We know by looking at the project type. If you start your project as an Activity Library or a WCF Workflow Service application then you get ASR-XAML, everything else gets ASR-Code which is why we got a code based proxy when we really wanted a XAML based proxy.
The workaround is to add a new Activity Library project to your solution and then add the service reference from there. But… once again it is not as easy as it should be.
Doh! Just when we thought he had this problem solved…
In this case there is a loophole we can exploit and is has to do with the order of operations. Try this.
Now your XAML activity can be used from the web app
If you don’t want to use these workarounds there are some options
If your business logic lives in the same web app, you might be able to invoke the business logic directly without sending a message through WCF. If you can do this it will result in better performance as well as avoid the problem all together.
If you do need to send a message, you can use the WCF generated code proxy async interface (you have to generate w/async support). I highly recommend async but you can also use a CodeActivity if you don’t want to do async but this will hurt your performance.
This will keep the boundaries clear and you can invoke your services in their own application. The downside is that you now have 2 web applications to manage.
Yes, we have an open bug on this and are considering options for making this better in the future. One option might be to simply let you choose if you want the XAML reference to be generated when you create a service reference. Don’t know how long it will be before this gets better but it probably will not be fixed until the next release of Visual Studio.
Sorry to bother you. But there is another weird issue with Xaml generated code for WF4:
When adding a designed activity to a project library and compile the assembly containing the designed activity an internal class named _XamlStaticHelper is automatically generated. The generated class does not have the CompilerGeneratedAttribute. Therefore when running fxcop analysis the following violation occurs:
Warning 120 CA1031 : Microsoft.Design : Modify '_XamlStaticHelper.Load(string)' to catch a more specific exception than 'Exception' or rethrow the exception. C:\Projects\dev\source\Server\obj\x86\Debug\_Server.g.cs 112 Server
I have a connect issue here:
But so far no answer. Think this could be incorporated into SP1 of VS2010?