MSDN has a set of articles regarding WCF versioning that are good to cast your eyes over.
I have been working on a winforms wizard framework for a while when I get the chance. My aim with this project is to be able to create a reusable framework for wizard style dialogs and pages for the 2.0 .Net framework.
The first RC version of my WizardUI has been released on CodePlex. I would appreciate any comments. You can find the release here.
I am really enjoying using WCF and WF in my development. While playing with the new toys can be frustrating at times, it is a whole lot of fun. There are a few gotchas though. The one I want to highlight here is the “Find All References” support in the IDE. Here is a scenario that can bite you.
Let’s say that I am using PolicyActivities to do pre and post condition validation. I may also be using them to change data in the workflow based on rules. For example, I might need to do some business to data object mapping. To neatly achieve this conversion while avoiding a CodeActivity, I can have a rule in the PolicyActivity that calls a static method on a converter class. Now that my solution is created, I want to clean up the code to make sure I don’t have redundant methods.
In order to check if a method is being used, I would normally have used the find all references feature to see if the method is being used anywhere, but here’s the kicker. This feature (from what I can guess) only looks at code that will be compiled down to IL. This will not work when the method exists in a rules file because the rules file is simply compiled as an embedded resource.
When you have WF projects included in your solution, run a text search for the method, searching all files in the solution (not just *.cs files). Oh, and always re-run your tests after you can any code.
I have been looking at WF runtime services, specifically the ManualWorkflowSchedulerService for running workflows synchronously. In my research travels this morning, I came across this article on the odetocode site. At a quick read, it seems like Scott Allen has put together a fantastic article with just the right about of information, code and detail.
Given my impending fatherhood, there have to be changes and sacrifices. I have been instructing beginners and intermediates at Taekwondo for about a year and a half. Tonight was the last night for me as an instructor so I have to give up the cool “go faster” intermediate instructor’s red dobok. Pity, I liked that one.
I have been building up a project that I need to add workflows to, only I didn’t create the project as a workflow project. This means that when I go to add a new item, I get the standard options along with WPF file types and even an option for a WCF service, but no workflow options.
After using WinMerge to compare the project file with a workflow project file, these are the actions I took:
- Add references to System.Workflow.Runtime, System.Workflow.ComponentModel and System.Workflow.Activities.
- Open the project file in notepad and make the following changes
- Add the following to the first Project/ProjectGroup element (it should contain the assembly details) :
Given the name of the ProjectTypeGuids element, I am guessing that the guids should be the same for everyone, but you might have to compare the guids found in a new workflow project to you can create.
- Add the following after the CSharp.targets Import element under the Project element:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.0\Workflow.Targets" />
Just read this great article on securing your .Net code.
This is one of those things that I have often thought about, but has never seemed important enough to read up on. I had always wondered why I often saw three slashes at the beginning of a file Uri. Now I know.
I am getting some interesting results when messages are returned from a WCF service. Small responses come through fine. When the responses start to get large, I run into the QuotaExceededException exception. This is fine because you can increase the MaxReceivedMessageSize configuration value on the client endpoint. This starts to fail when the size of the data continues to increase and eventually I get the exception WebException: The underlying connection was closed: The connection was closed unexpectedly__.
The service call is still being made (I can debug it), but it seems that the error is coming back quick enough that it is a problem with the server endpoint, rather than client endpoint or configuration on the client.
Anyone come across this before???
I have been looking at caching support and WCF recently. I have come across a few solutions. These are:
- Calling through HttpRuntime to get at the ASP.Net cache
- Using Enterprise Library Caching Block
- Rolling your own implementation, usually storing data in a Dictionary<String, Object> collection.
I have problems with 1 because that ties your WCF service down to an IIS and HTTP solution which is not good design. Option 3 is also not that great because typically this is built as a ‘quick and dirty’ solution that doesn’t support any cache dependency or cache expiration policies. I haven’t played with 2 yet, but it looks like that will be the go.
On a side note, I came across a code sample by Scott Mason (where’s the blog Scott???) that uses an IOperationBehavior implementation to hook the operation call to provide caching support outside the actual implementation of the service operation. This is a great idea. The only thing I don’t like about it is that operation behaviors can’t be set via application configuration. They can only be assigned to an operation (WCF method) via a custom attribute on the method or via the behaviors collection at runtime. Pity, it would be so nice if you could plug in different behaviors via configuration.