Living in the Tech Avalanche Generation

I have the overwhelming feeling that Microsoft will be putting more and more effort into REST, ATOM and a variety of other technologies that do not tow the SOAP / WSDL / Web Service & WS* party lines. This is extremely good for those who felt that all the technology on that stack was becoming overly complex and burdensome and to boot was not adopted by the larger internet players from whom all of us corporate behind the firewall types can learn a lot. Growing up over the past 3 or 4 years it has become more and more pronounced to me that there were these two competing worlds of technology, the one for the internet scale thinkers and doer’s and the other corporate small scale network folks, the later becoming ever so more curious about the black magic being practiced by the likes of Google and Amazon and want to come to terms with why it seemed so different and also saw benefit in borrowing their ideas and applying them to the problems in their environments.

We should take into account that Microsoft provide some highly usable and reliable tools for the corporate world, for example programming against an object (albeit a proxy) generated off a WSDL document, provided the kind of familiar comfort we feel with an old pair of socks.

Enter REST, ATOM and some of their friends and I cant help but notice the change in pitch of the new breed of Microsoft technology development teams. A lot of excitement seems to be being generated around REST and remarks like “keep using SOAP and WSDL if it works for you and your comfortable with it”, only seem to support that notion that the focus is shifting. Throw in the fact that the recruiting at Redmond also seems to be somewhat focused on a blend of great academic minds and community thinkers and celebrities, the noticeable change in culture at Microsoft is palpable. This all very good, very good indeed.

I recently compiled all the libraries from my most recent post on LINQ To SQL, into a Multifile Assembly so people could play with the bits without having to load up the projects that make up the POCO Framework which contains the Repository / Specification and Fetching Strategy libraries in it’s VS.Net solution.

The trick in creating a custom multifile assembly is to take all the files from the libraries that you wish to blend into one assembly, compile them into netmodules and then combine them all with the Assembly Linker otherwise know as al.exe. In my case the modules were as below:

and the last command I had to execute on the command line was:

al <module name> <module name> … /main:<method name> /out:<file name> /target:<assembly file type>

where the module names were from my list above.

One thing to watch out for if your a ReSharper user: the multifile assembly (your DLL compiled from the netmodules) may not be recognised correctly by intellisense in VS.Net 2008 and may report that it cannot resolve symbols. I didn’t dig into the cause of this problem however turning ReSharper off will stop the warning and code window highlighting but the problem does not stop VS.Net successfully building and executing your code nonetheless.

As you can see, the ‘Repository’ type is not having intellisense resolve it correctly and it is showing up in RED! But let me re-iterate that this will not preclude your code from building and running in VS.Net 2008 and turning off ReSharper will remove the intellisense problem altogether.

The multifile assembly for my previous posts code can be found here and if you browse it in Reflector you can see that it incorporates all the namespaces and code from the multiple projects in the LINQ To SQL going POCO solution.

Well I can scarcely believe it myself. If you had asked me a few years ago if I could imagine using FireFox as my preferred debugging environment in .NET then I would have laughed hard, but yes folks it’s true. IE 7.0 is driving me insane with how slow it is whilst debugging. Let me take you through a course of events that led me to writing this post.

It all began with me developing a company intranet application using WPF XBAP technology and several views (I am using MVC) into it I decided to update my source control to tortoise 1.5.0 and grab the newest version of Ankh as it was meant to work nicely in Vista. So, no problems with the installs and just as I open up VS.NET 2008 I discover that the Ankh install has caused VS to loose its project history and my profile settings as well and it begins to set up as though for the first time.

Now I am a patient guy, so I just quickly get things back to the way they were and fire up my XBAP ready to start work again. I create another view port for my application and decide that I would like to run the application to see this new view…..oh oh, default settings have gone back to IE 7.0 and it’s a tad slower than FireFox in loading the application and just as slow in releasing the IE  process and stopping the debugger too. I wondered if the trick to getting the XBAP back to loading by default in FireFox was the same as it is for ASP.Net? A quick look for the context menu option on the XAML files does not show up with a ‘browse with’ so I decided to open an ASP.Net application and reset the default browser from there, then switch back to the XBAP and hey presto - the problem is solved. See below for the visuals:

Go to an ASPX page and right click to get the context menu and select ‘Browse With’, then select FireFox as the default browser….reopen my WPF application and my XBAP now loads in FireFox by default and I’m all done!