The Durable Task Framework, created by Abhishek Lal over at Microsoft, is fantastic. It allows you to leverage the Windows Azure Service Bus to create long running, durable workflows (orchestrations) comprised of one or more sub-tasks (activities) or even sub-workflows. If you’re not familiar with the framework, take a look at it first before continuing. The above link contains a download with some documentation and samples for using the framework.
It didn’t take long for me to get up and running with an orchestration and a few tasks, although I quickly realised that I had overlooked one key point. The input and output objects for each task are serialized and transmitted over the Azure Service Bus. Initially my inputs were complex types with a unity container reference so I could share a single instance of a unity container with all of my orchestrations and tasks. Serializing the unity container is out of the question, but it wasn’t obvious to me how I could use the framework to allow me to inject my unity container in to the orchestrations and tasks.
In this post, I present a solution to configuring your setup such that you can provide your task orchestrations and activities with whatever extra data you need.
The first solution was to add the missing MIME types to my web.config, like so:
Redeploy, refresh. Now I had a bunch of errors with other scripts that were working fine, almost every script was throwing a 500 error. More Googling and cussing and publishing and refreshing and nothing. Eventually I spotted a small note on someone’s post on StackOverflow where they mentioned changing the BuildAction for the .json files to ‘Content‘ instead of ‘None’. I’m not sure what affect this has and will look in to it another time, but for now it solves my problem and hopefully yours too!
Welcome to the fist part of my ‘.Net 4.0 Printing Made Easy’ series. In this part we’ll take a quick look at the .Net printing support, what it does do for us and just as important, what it doesn’t do for us.
In .Net 3.0 we were given a great new printing framework based around XPS documents. This immediately opened up a world of vector based printing where you can print your WPF vector controls and have them appear as sharp as ever, or if printing to an XPS or PDF document, your print out will be preserved in its full vector glory. What makes this even better is that you as a developer don’t have to worry about any of this, you just send your data off to one of the many methods provided and the rest is done for you. There are of course some instances where you can’t print raw vector data out and need to handled rasterised data. This too is very simple and there are a few tricks you can use to make it even easier.
When asked about printing, most developers will recoil in horror and rather avoid the topic. For some us though, we don’t have any choice but to tackle the problem full on. Luckily, in true .Net style, printing has become a much easier problem to take on. I recently undertook a large printing task that required designing and architecting a printing framework that could be used in a rich desktop application, allowing pretty much any control in the application (third-party or in-house), to be printable through a common print preview view complete with WYSIWYG page setup, headers / footers etc etc. Quite a task!
As usual there is a wealth of information on the web on the topic of printing, although I found most of it to be quite disparate and specialised with very few complete examples and gotchas. In this series of posts I intend to cover as many aspects of printing as possible to try and give a better understanding and concrete examples, as a kind of map through the printing underworld. To this end, this series of posts will spare the detail in favour of providing a more general end-to-end look at printing with links to greater detail for those that are interested.
In part 1 I will try to give a brief overview of printing in WPF and get you started with some code for getting hold of a list of local printers and what you can do with that information.
Well it has been a busy time for me since my last post, so this one took a little longer to get out. Fuelled by the launch of Silverlight 2.0 and my desire to give it another go (being a WPF developer I was a little put off by the bareness of 1.0) and set about finding a little project I could undertake to help me learn the ropes. I had several ideas (read, future blog posts!), but the most logical was to port the 3D ellipse control I wrote in WPF across to Silverlight 2.0. It was a fairly straightforward port and a real eye-opener to what the differences between Silverlight and WPF really mean.
The biggest challenge was the lack of the Media3D namespace. This prompted me to start building up a library of classes that aren’t included in Silverlight. So far I have created a Point3 (Point3D), Vector3 (Vector3D) and Quaternion (Quaternion). They are all basic implementations at the moment and contain just enough functionality to allow me to create the sample.
To overcome the lack of Viewport2DVisual3D, I calculate the scale for each child control based on it’s depth in the scene. This is a bit of a hack rather than a proper perspective correct transformation as I didn’t have the time to spend creating a camera implementation and setting everything up properly. Instead I make do with a camera focal length and combine that with the z value of each object to calculate how big it should appear on the screen, otherwise you wouldn’t be able to tell which controls are further away from the screen. Using a ScaleTransform ensures that the control appears correctly, but with a sense of depth.
Z-ordering is also taken care of, ensuring items deeper in to the scene appear underneath items which are closer to the screen. There are also a few little extras in there such as being able to animate the rotation of the ellipse, which when played around with can create some awesome effects.
The screenshot below shows the app running in full swing. Animation is enabled and a very small focal length is used, making the objects close to the camera appear much larger than those further back. There were around 200 buttons in the control at the time and it coped really well.
After finishing my last post, WPF Elliptical Layout Control, I sat down and wondered what to do next. It occurred to me that creating a 3D carousel in WPF is a common question and one that doesn’t have all that many examples. A 3D control is also a natural progression from the 2D control and is not all that different. All we need to do is layout the objects in 2D, then rotate those points according to the orientation of the imaginary layout ellipse, taking in to account depth.
This example creates a new control which derives from FrameworkElement and is very similar to the implementation of the Viewport3D control. The new control overrides the measure and layout methods of FrameworkElement and positions the child controls (supplied as a collection of UIElements) according to the orientation of an imaginary 2D ellipse in 3D space.
It is assumed that the reader has some knowledge of custom controls, LINQ and 3D in WPF. The code provided is by no means an ideal implementation of the theory, it should be thought of more as a quick demonstration of the concept. And remember, in WPF there is almost always more than one way of doing the same thing, mine is just my take on the problem :0)
Today I was talking to a good friend and former colleague and he asked how I would go about laying out a collection of controls as if they were equally spread out around the edge of an ellipse. I did a quick Google and didn’t find much in the way of examples, so I decided to knock one together. An hour later and we have what I present here.
This is a fully working, but a little rough, demonstration of creating your own control and performing custom layout logic.