Living in the Tech Avalanche Generation

Just as I was about to embark on  a new project (codenamed PONGO), the IronPython team announced a CTP 2.0 drop of the IronPython tools for Visual Studio 2010 which is exciting on a number of different levels.

If IronRuby and IronPython eventually make it all the way to Visual Studio integration in the full sense (that is packaged as part of Visual Studio itself) that would be a mark of first class citizenry.

What about Expression Blend?

Personally I work in both Blend and Visual Studio and even though the Visual Studio designer is somewhat improved and it’s intellisense is far superior than that of Expression Blend, it still does not provide me with the same fidelity or fluency in the design experience as I get from Blend. This leaves me with a problem when it comes to building applications where IronPython is the choice language.

It would have been unrealistic (at this stage) to expect Blend to open IronPython projects created in Visual Studio and sure enough that is the not case. What might be useful is Blend having a “design XAML only mode”, enabling it to open XAML files individually, taking advantage of the design experience it has to offer. Still not ready to give up on using Blend with XAML files that were part of a Visual Studio IronPython project, I set out to find a way.

Symbolic Links

The first thing I tried out was to see if Symbolic and Hard linked files would make the difference? First up I tried a symbolic link using the MKLINK utility:

MKLINK [[/D] | [/H] | [/J]] Link Target

Before doing this I created two projects, the first one an IronPython Tools project generated in Visual Studio and the second one a C# project created in Blend.

It should be obvious from the naming which project is which. In the blend project I removed the default XAML file generated by Blend.

Next came the file linking, I used only the Link and Target command line options, creating a symbolic link using the same name as the .XAML file in my IronPython project.

MKLINK pongo.xaml d:\temp\PongoBlend\pongo.xaml

Having successfully created the soft linked symbolic file I tried to add it to the Blend project only to find that it would not open – which, to blunt I wasn’t expecting to work. I was a little more hopeful however when it came to the Hard Linked file which I setup as follows:

MKLINK \H pongo.xaml d:\temp\PongoBlend\pongo.xaml

This did in fact open correctly in Blend and worked for a brief moment, when I changed something in Blend – Visual Studio would prompt me that the file had been changed outside the editor, unfortunately my celebrations were short lived when I found that the files were not updating in both locations when one or the other was subject to an edit. After some investigation and testing it appears that once opening the file in both the IDE’s the links would somehow eventually become broken and so the symbolic linking idea was now officially a lost prospect.

Duelling Projects

Finally I decided to synchronize two separate .XAML files in each of the two different projects, so the challenge was to find the most unobtrusive way of working in both IDE’s and easily syncing the the .XAML files after edits had been made. Given that one of the IDE’s was running a dynamic language with a REPL built in, I thought it shouldn’t prove too difficult.

What I did was to add two .py source files into the project, each one with some code that would sync in one direction, either from Blend to Visual Studio and vice versa. Sure its  far from a perfect solution but it just might be a price I’m willing to pay in the short term to get the benefit of using Blend. In the long term I really do hope that as the dynamic languages gain support in Visual Studio we also get some integrated ways to work in both IDE’s.

Here’s the very same Pongo.xaml file (or copy of it to be precise) in Expression Blend, but before you get too excited, the “send to interactive console” context menu option seems to suffer some kind of inconsistent behaviour (on my machine any way), causing the File copy operation in my .py files to work on only some occasions.

Undeterred I decided to fall back to an even more disintegrated experience and opt for running the synchronizing .py files in IPY.exe itself. This is easily achieved by associating .py files to the IPY.exe in Visual Studio using the context menu’s “open with” option, which is a something existing Visual Studio users will be very familiar with.

Like I said its far from a perfect solution and to be frank it’s somewhat annoying however my frustration is another thing altogether if I’m faced with doing all my layout and design in Visual Studio – so I will live with it for the moment. Hopefully the IronPython team and or the Expression Blend Team can find a solution that flows changes through more seamlessly in the short term and the perhaps in the long term allow us to open IronPython and IronRuby projects in Blend.

By the way if your wondering about the codename of the project that drove this adventure (PONGO) – the answer is yes if you guessed that it’s something that revolves around IronPython and MongoDB and I will be blogging about that more in the coming weeks.

I’m reasonably sure that my experience so far with WPF and Silverlight is not unique in this respect. Most days (right now) are filled with open IDE’s galore and luckily having lots of memory is cheap. Typically a coding session will see that I have at least one instance of both Expression Blend and Visual Studio open at the same time and usually it’s more.

Behaviours Observed

Invariably I find myself doing nearly all the layout in Expression Blend as I find it’s design time environment far more satisfying for the following reasons:

• The ease in setting properties via the Properties Window
• Setting styles etc in the Resources Window
• The availability of the interaction Window
• Designer View in Expression Blend is far superior (and works)
  • Better Viewing Experience
  • Better Element Navigation Experience
• And setting animations in the Objects and Timeline Window

I have become proficient at flipping between IDE’s in an effort to take advantage of each of their strengths. At any given moment I can be doing some layout in Expression and then quickly flip over to VS.NET to take advantage of intellisense if I want speed in writing XAML by hand. If Expression had intellisense then I must admit that I would spend very little time in VS.NET other than to work on C# code directly.

Now that’s obvious you say! How else could you possibly manage? Well, some people are working exclusively in VS.NET with WPF and I just can’t comprehend how or perhaps it would be better stated that I can feel their pain. Perhaps they are die hard Windows Forms developers who just can’t bring themselves to leaving that IDE or maybe they just don’t have access to Expression Blend? Whatever the case it would prove both slower and far more frustrating to work without Expression Blend in my view. So if your a die hard? Let the VS.NET apron strings down and give Expression Blend a fair go, it’s not a perfect world but I believe it’s the best option for the time being.

I have heard a lot of people express the opinion that both these tools should be rolled into one (namely VS.NET). No prizes for guessing that that’s an opinion expressed by developers! I cant speak for devigners / designers but I am fairly sure they wouldn’t enjoy VS.NET at this stage as it’s really still quite unwieldy for XAML based applications. Personally I am quite happy to work in both IDE’s concurrently however my main wish at the moment is to give Expression Blend intellisense, then it’s safe to say that I will pretty much avoid VS.NET for everything other than C# code files. Version 3 of Blend does offer intellisense and code file editing however the lack of debugging will see us continuing to use both tools for a while yet. You can find a list of the new features here.

I have recently updated with Silverlight 2.0 and Blend 2.0, I also had to downgrade from the Blend 2.5 preview version as it wont work with the current RTM’s. Last thing I installed was the Express Version of CodeRush (which I really love) and now VS.Net seems to be restarting itself a bit too often for my liking and I am really becoming annoyed with not being able to get the XAML view of some (not all) my Silverlight applications. Bizarro World! Apparently the XAML view problem is a VS.Net bug (something to do with styles in the app.xaml file), however it’s worth noting that I can see everything just fine in Blend. I also have Ruby In Steel installed and I did notice some wacky behaviour around that time as well. I really don’t want to do a rebuild, I will report back soon with whatever my research turns up.

Update: 13th November 2008

I removed the Ruby In Steel plugin for VS.Net and the visual XSD add-in, so far so good (for general stability in VS 2008) however I still don’t get a XAML Preview for a complex project with more than about 12 or so views (user controls).