My BizUnit Extensions project is finally live on CodePlex . Check it out
here . Okay, so there are no releases yet, but this is a start and coupled with my context tutorial on codeproject means i have finally started giving back to the Biztalk community. The first release should be ready very soon and if you are interested, post comments there or email me and join up and lets see how far we can take this tool.
So after several cribs and rants about BizUnit, a while ago i decided to take matters into my own hands and went through the code base with a fine tooth comb and worked out what exactly it does and doesnt do. I then wrote up a tutorial on the context object and have been intending to post it here for a long time. Finally i got round to it this evening as i was prodded by an email from someone who wants to check it out. So i have put up an article on this site and its available at this link
From the introduction :
BizUnit is a very extensible testing framework. One of the core elements of BizUnit is the Context object. Unfortunately the documentation does not explain how users can take advantage of it and it is left to developers to try and understand it from NDoc samples scattered around in the documentation.
This tutorial introduces the Context object and how it can be used in BizUnit based testing. It uses examples from the official documentation wherever applicable and supplements it where the information in the documentation is not very clear. It will not replicate the list of methods and properties etc, so for an exhaustive reference, please refer back to the documentation. This is the first in a series of articles on BizUnit.
Disclaimers & Misc stuff
The word template i used was really cool but the formatting available on this site is very limited so it looks rather poor and there is no provision for attaching entire documents, so please excuse the appearance of the article. I have applied for a CodePlex project where I intend to put the articles and other tutorials as well as the code for the new steps we have written. As soon as that is available i will let you folks know.
I welcome any comments on this article and suggestions for improvement.
(Btw, I wonder if its my browser, but something appears to have happened to the rendering on this main page. All the posts are skewed in format)
UPDATE: The article is now live on CodeProject (while i wait for a space on CodePlex) . Check it out and rate it / send me some feedback.
After a few months of being NAnt infected, I'm at another crossroads. Now that we are starting up on the .NET 2.0 world and are seriously considering the whole VSTS package, MSBuild is a big contender for the building and CI backbone. We didn’t actually get round to using CC.NET in the first phase of our integration project as the team was new to unit testing and automated builds etc, but we've made some good progress and have more or less sorted out an automated build and CI is the next step so Team Build may have its uses there.
We took inspiration from Scott Colestock's deployment framework and built a decent build and deploy engine and are now refactoring it to be more generic. In the beginning, since Nant was quite new to us, I didn’t make complete use of Scott’s tool as-is, because it would have been a big learning curve and with multiple solutions I didn’t like to have to put the deployment framework folder in every single solution. I guess I could have modified it to take stuff from a central location, but hey, those were early days and I was moving away from a batch file centric BTS deployment that I had used till then. Ironically, while generalising the engine now, we are finding that it looks very much like Scott’s, so maybe we’ll move back to Scott’s tool and he has upgraded it to work with v2006 as well.
But that brings us to the crossroads now. Do we throw away our investment in Nant and move off wholesale to MSBuild? What does MSBuild have that could make it worthwhile?
On the surface, it seems like there isn’t very much going for MSBuild. The Nant community is very strong and there are heaps of tasks for various things. Added to that, I think the script is quite expressive and although I haven’t written custom tasks yet, I gather that they are quite easy to write. However, the UK SDC of Microsoft has been going hammer and tongs on this aspect and the Enterprise Solution Build Framework is quite impressive. Guy Smith-Ferrier showed some of the tasks in the SBF at the recent VBUG conference and I was surprised to see how big the task library has grown. The MSBuild script is very similar to Nant too, so if we needed to convert, we could write XSLT and convert most of it.
From the Biztalk aspect, there are a ton of tasks that are coming out from MSBuild. Stephen Thomas deals with some of them in his article here. Since our architecture revolves around Biztalk, this will be a key factor. Right now its all command line based and having to explicitly start, stop and remove ports associated with orchestrations is mind numbingly painful and very difficult to keep in sync. We were planning to take some of the examples shown in the MS Applied Integration Baseline (which contains a C# deployment engine for BTS) and write more custom tasks to slim down the Nant files and make them more reliable, but the MSBuild library is very tempting indeed. Hmm… how about a Nant container for MSBuild tasks? (!!)
One of the irritating things about Biztalk is that you cannot build it without Visual Studio, so there’s no option but to call DEVENV from the command line and that slows down compilation of large solutions. The problem still exists with MSBuild, and that’s a real minus, in my book, for the BTS and VS teams. They should have done better. Well, there’s still time. MSBuild is only v1.0 and maybe the BTS team will get this sorted. (Another annoyance is that if you want to change the assembly version or file version, you have to crack open the btproj file cos theres no AssemblyInfo.cs file for BTS. We are going to use the Nant xmlpoke task to do this).
There are some irritants though, with MSBuild. Steve St.Jean has written about its failure to work properly with secondary references. Actually if you haven’t seen that article, check it out. Apparently MS recognises the limitation, but, get this, instead of enhancing MSbuild, they want to dumb down VS so that VS stops recognising secondary references. Doh!!! Homer Simpson moment for MS !!
Theres an interesting discussion on Nant vs MSbuild at the MSDN Forums. In particular, Faisal Mohamood’s post there is a nice explanation of the positioning of MSBuild. But the forum posts also reveal problems such as the limitations with solution file structure and so on.
So, its rather tricky right now. If VSTS plays nicely with Nant (and I don’t see why it shouldn’t, but you can never tell) I might just stick with Nant for the next few months and undertake to write more custom tasks for biztalk or convert the MSBuild tasks to work with Nant (hope that isn’t unethical?) and eventually when MSBuild matures and there are tools which can help us with the migration, I may switch over to MSBuild.
Do feel free to comment if you want to share your thoughts on the subject.
Just came across a very interesting article on MSDN titled "The EFx Architectural-Guidance Software Factory".
According to the introductory paragraph " The Enterprise Framework Factory (the EFx Factory) is an architectural-guidance software factory. It provides Microsoft partners with a software-factory implementation of the Microsoft Distributed Architecture for .NET Applications for building applications and services on the .NET platform. The software factory is founded upon an application framework (Enterprise Framework) that combines Enterprise Library, a number of the Microsoft Application Blocks, and best practices in .NET solution development, and supplements those with specialized class libraries for creating service-oriented, enterprise-level applications."
Its a nicely written article showcasing the power of EFx. Many of the ideas implemented there resonated with my thoughts on implementing something similar for my development team. Wonder if MS will make it available for download or if its a MCS only internal product. I tried contacting the author, Jezz, but the contact form on his blog doesnt work. I'll keep trying. Its good to see MS aligning all their guidance and standards into automated tools. Makes it so much easier than having to point people to massive PDFs online.