I can’t be the only person who has been frustrated by the inflexible nature of Visual Studio solutions and projects. So when Krzysztof asked for someone to write a program to convert vanilla .NET projects to Silverlight projects, I jumped at the chance. Of course, I then proceeded to take four months to deliver what is, in all honesty, a fairly simple piece of code. Anyway, it’s finally checked into Castle Contrib at https://svn.castleproject.org/svn/castlecontrib/SolutionTransform/trunk/.
Ironically, I’ve already blogged about the basic architecture, although the code is now a bit more complex than the braindead example I was running with at the time. I make BOO do the work. Basically, the code goes through the solution and filters out projects. It then applies transforms to the projects and (optionally) the underlying code files.
You call it as follows:
SolutionTransform <<Name of Script>> <<Full Path of Solution>>
There’s only two scripts so far (in the scripts folder). One standardizes code files for the Castle Project, the other converts castle vs2008 projects to Silverlight 3.0 projects. This second has been the whole point of the project . It’s the missing piece of any plan to develop a class library for regular .NET and Silverlight simultaneously. Without something like this, it’s a complete pain to keep the versions in sync.
The Challenge
You’ll find there are exactly four tests at the moment. I know what some people are going to say about this, but the truth is the expected end result hasn’t been very well understood until quite recently. This was, in fact, the principal challenge in writing the code. Krzysztof had to throw several versions back before I checked anything in. It looked like it would work, but it didn’t. Writing extensive tests wouldn’t have helped: the tests would have been wrong too.
The nature of the project is that I’m pretty much guaranteed that there’s going to be a wall of edge cases. I’ve spent a month with something that looked stable except for one show-stopper. (I’ll blog about that soon.) Neither of these file formats is exactly documented. CSProj files are actually MSBuild files, but with conventions. The conventions aren’t exactly defined anywhere. Solution files aren’t documented anywhere at all. In future, I expect the number of tests to grow faster than the code base.
To give you an idea of how bad it is, open up a solution file in Notepad. Make a small modification like changing a project filename and save it to another file. See if you can double click it. Your chances are about 50/50. It has to be UTF-16, and sometimes there’s a mysterious mandatory blank line at the top of the file.
What’s Next?
Well, it’s pretty modest at the moment, but I’d like it to become a fairly general library for manipulating Visual Studio files. .NET has fragmented, as was inevitable. Keeping Silverlight, Mono, 4.0 and Compact Framework together is a pain at the moment. The next problem I’d like to address is swapping between reference assemblies and project files. Synchronizing assembly dependencies is a big deal as well. However, like all OSS projects, the future direction is pretty much a direct function of who’s interested.
A small note: this is very early days, and the API is likely to change quite a lot as we learn more about the problem space. If you want to use this, and really don’t want to worry about change, take a copy of the executable. As with everything Castle Project, it’s licensed under Apache 2.0. Finally, a big thanks to Krzysztof, who’s done a fair chunk of the testing and has put up with more dud versions than one man should.
Colour Coding 