Convert SVG to XAML

For one of our current projects I needed to convert some hazard symbols from SVG to XAML to use them in a Silverlight GIS front-end.  After querying the web I found several tools that supposedly do so.  However none of them fitted my needs.

• A few of them where payable products; and they only offered severely crippled demo versions
• One of them was a plugin for Adobe Illustrator, and I do not have it :)
• Inkscape has an export to xaml function (Save As -> Microsoft XAML), but trying that on the hazard symbols mentioned above (you can download the SVG’s following that link) turned out to be no good.  While the xaml could be parsed correctly from a technical view point, it rendered images that where nothing like the original SVG’s

One of the search results mentioned the Microsoft XPS Document Writer printer driver.  And to my suprise, you can in fact use that one in the process of converting SVG’s to XAML :)

Here’s what I did:

This may seem a bit tedious, but in fact works quite well once you have done a few conversions :)

First, you need an SVG file.  For example: this one

Secondly, you need to open that SVG file in Inkscape (I have had no luck printing the SVG from my browser, probably because it uses some weird plugin to render the SVG).

Then print the SVG from within Inkscape to the Microsoft XPS Document Writer.  You have to specify a file name:

Then go to the location of the .xps file and rename its extension to .zip (yep, apparently it is also a zip file :))

Browse the zip file for \Documents\1\Pages\1.fpage and extract that file.

Optionally rename its .fpage extension to .xml to open it up in your favourite xml editor.  Alternatively leave the file as-is and open it in any text editor (notepad will do).

You should see something like:

<FixedPage Width="816" Height="1056" xmlns="http://schemas.microsoft.com/xps/2005/06" xml:lang="und">
	<Path Data="F0 M 4.32,528.8 L 528.8,528.8 528.8,4.32 4.32,4.32 4.32,528.8 z" Fill="#ffff7d00" />
... snip ...
</FixedPage>

If you copy-paste all the lines that are enclosed between the <FixedPage> tags inside a <Canvas> tag you have fully functional XAML ready to be used in your Silverlight or WPF application :)

Getting my hands dirty again

It’s been more than a year since I last actively participated as a developer in a development team.  Sure, I wrote some kick-ass T-SQL scripts and the occasional line of C#.  But, over the last year my tasks were more targeted to data modeling, functional design and project- and team coordination rather than to writing source code.

This was up until about 3 weeks ago, when I was given the chance to write some code again.  I wrote most of the functional design for the project and a team of 3 developers already implemented a great deal of it.

Now, during the time of my source code writing abstinence, my colleague Davy Brion had done serving his time in Enterprise Hell and was asked to strengthen our in-house software development team.  Davy introduced a lot of technologies and patterns that extended the way we previously developed our software projects.

He ditched our code generated data layer and introduced NHibernate instead.  Being a big fan of dependency injection he also threw Castle Windsor into the picture.  And to top it of, for our unit tests he showed us how to easily mock dependencies using Rhino.Mocks.

It only took me about a day or 2 to fully understand and start using the new architecture in a productive way.  So how did I manage to grasp these concepts so quickly?  Well, the answer is easy: they aren’t all that hard to understand!

NHibernate

While having had no experience in NHibernate at all, I already knew the general idea of ORM.  And as I joined the development in a stage of the project in which already alot of funtionalities were implemented, I had some real life examples of mapping files, entities and data repositories laid out in front of me.  Taking it from there was not that hard.  Although for the occasional question it is kinda handy to have an NHibernate developer in your team.

Castle Windsor

Again, I knew about dependency injection as a way to implement strategies and the likes but seeing CW in action really blew my mind.  You just register your components in code (or xml) and don’t care about them anymore.  The IoC will automatically inject the configured dependencies for you (as long as you provide the means to do so by adding the corresponding constructor parameters or public properties).

Rhino.Mocks

We already were writing unit tests for a few years (as is the core of our genesis development methodology) before Davy introduced Rhino.Mocks.  Some of the techniques a mocking framework solves were not new to me.  I already had stubbed some dependencies with manually written ‘test’ code.  Again, the simplicity of creating mocks, stubs and expectations with Rhino.Mocks really impressed me.  And the unit tests are _fast_!

So, All’s Well That Ends Well?

I did manage to screw one thing up though :)  I wrote a piece of code that created a new entity in memory and that did not initialize a non-nullable field.  Since the tests for that code, mocked the data repository that is responsible for persisting the entity, they ran just fine while in fact they covered faulty code.  Adding an extra test for every non-nullable field would solve this problem, but I don’t believe that is the best approach (a bit tedious don’t you think?).  We’re already thinking about an elegant solution for this… maybe one day you’ll read about that on Davy’s blog orso… :)

Software Factories and Frameworks. How to maintain infrastructure code?

In a reaction to Davy Brion’s post about how to deal with common infrastructure code for multiple projects I’d like to share my take on said topic.  I already placed a brief comment on Davy’s blog but maybe I need to go in a bit more detail to make my point fully clear.

Davy lists these 3 options, each with its pro’s and con’s:

1. Infrastructure code as a separate project.  Binary dependency per client project.
2. Infrastructure code as a separate project.  Copy source code into client project repository.
3. No separate infrastructure project.  Each project contains its own infrastructure code.

If you place these options into following table, you get ‘more consistency over different projects’ on the left hand side and ‘more flexibility’ on the right hand side:

Option 1	Option 2	Option 3
Highest level of consistency Requires a lot of discipline in versioning and maintaining Has to provide many extensibility points for clients to implement their custom behavior Least flexible	Inconsistencies possible between client projects Still requires a certain level of discipline for maintaining different versions Also requires extensibility points for custom implementations A bit more flexible	Inconsistencies between client projects are as good as certain No need to maintain different versions No extensibility points required Very flexible

The question is:  What option would you take?

Easy question, not so easy answer!  My take would be not to pick a single option, but depending on a specific part of the ‘framework’, categorize that part into one of the 3 options.  So, in the following part of my post I’ll address these 3 options as category 1, category 2 and category 3 respectively.

Category 1 code should be (just my first thoughts, some of these points may be hard to implement):

• Ui paradigm independent.  Code in this category should not need to know whether the client project is an asp.net-, a winforms-, a wpf- or even a silverlight application.
• I’m thinking mostly interfaces and abstract classes here… Extensibility is key.
• Very generic code.
• Probably a relatively small code base.

Category 2 code should be:

• More concrete, but still reusable over different projects.
• I’m thinking default implementations here (e.g. an ActiveDirectoryAuthentication component, an EventViewLogger, an ASP.Net BasePage, etc.)
• If proven to be very stable (both in behaviour as in requirements) can possibly be moved to category 1.
• And vice versa: if proven to be unstable (i.e. changes quite often), move to category 3.

Category 3 code should be:

• Very specific for the client project.
• Ideally some components start their life cycle in this category, but are moved/refactored to category 2 if their reuse becomes apparent by taking on specifications of new client projects.

Now, how to organize these categories in assemblies, source control, etc. is not part of this post.  I just wanted to share my theorethical view on this.  Turning this into something practical is the next step…