MSBuild vs. NAnt

Correct me if I'm wrong but isn't MSBuild a knock off of NAnt or any other derivative of Ant?

Is the only reason MS created such a build tool is so that internal MS employees could use it? Do their employee contracts prohibit them from using Open Source tools? That's my speculation. Please correct me if I'm wrong.

It's not a problem if I'm right - but why not just use it internally at MS? Why make it public for everybody's use. We already have a decent tool and we get the source code to boot - not to mention community support.

I didn't get a chance to go to the MS Build presentation (TLS347) so I apologize in advance if I'm just not getting it. I have looked at the slides but there isn't much there - nothing that I don't see in NAnt.

I'm really looking for the killer reason not to use NAnt and switch to MSBuild. Maybe the answer is this..

MSBuild will be the core build engine underneath Visual Studio and share project file formats with VS.NET. Certainly this has caused me some grief with NAnt in the past, mostly with VB.NET since slingshot (the last time I looked) only converted csproj files to build files and not vbproj. So I think the most important thing about MSBuild is not MSBuild itself but that the C# and VB.NET teams will have to (or already have) collaborated on a unified .proj file format. Hopefully the NAnt contributors will write an XslTransform. As an aside I hear that this level of integration won't be available for C++ developers. Now getting three teams to talk to each other - that's just impossible. I bet that the .proj file format changes again when the C++ team gets around to supporting MSBuild.

In addition to the VS.NET integration, there seems to be only 1 other significant difference between NAnt and MSBuild. MSBuild includes some kind of “full inner-task dependency“ that is supposed to allow for incremental builds. While I might care about this for an IDE experience (slightly) it's less important from a nightly build scenario - IMHO.

Where is the holistic vision?

Microsoft is needs a holistic view of their platforms and development tools. I didn't see that this week, I doubt any of us will.

What I did see was 7 data access techniques in various stages of ready now, coming soon, and coming much later:

• Use a DataAdapter to issue SQL  or stored procedures. Useful for working with a DataSet and doing optimistic updates.
• Use a DataReader to issue a SELECT or stored procedure to walk through rows 1 at a time. Used for fast streaming of read only data.
• SqlDataSources. From what I can tell, this is a terrible thing. I've seen this in two places so I'm not sure they are the same. The first demo I saw of this it was just called a “Data Source“ It was in a windows forms application and it looks  like a typed dataset (and in fact is/uses them) but it also embeds SQL queries (and updates, inserts and deletes) into the actual typed dataset. But I use datasets through the various tiers of my application from UI to data access and I don't want this marshaled throughout the application. I talked to Paul Yuknewicz from the VB team about this. I told him it would be okay in the design time to do this - but you have to split these out into two classes. He said I could, but he couldn't show me. He said the typed data set and the data access classes could be in separate namespaces. When I told him I needed them in separately assemblies because my datasets go down to the win forms client, but the data access sits in my middle tier and hits the database. He took this as a good feature request, but he didn't give me a good feeling about it. I mentioned this to another guy on the Data team and he said that these Data Sources would not be for me. I suppose if you're building a dog house, it doesn't have to be well architected like a sky scraper. Unfortunately I've had to do many renovations of dog houses in the past.
• You can now embed some of the logic you'd do post retrieval to massage some data into the database. Yes, create a C# stored proc and return the data that way. You probably want to do this if the processing reduces the amount of ASCII (or the visibility - plain text - no encryption) to be sent along the wire.
• SQLXML - not new but improved and gaining momentum. Can you say new language to learn? XQuery, XPath. This is nice if the data you deal with outside of the database is in XML. Also good for doing master/detail updates in 1 round trip. I like this.
• ObjectSpaces. I saw a preview of this at PDC 2 years ago. I'm going to another session to learn more details in an hour. It's changed since then but the message is the same. It's an Object to Relational mapping scheme. You define how your tables relate to your objects - and then you merrily use your objects and ObjectSpaces figures out the SQL to send to the database. Why would you do this? Well if your app embeds a lot of business logic in your objects - which it should damn it. This technique lacks SQL fidelity and you have little direct control over the SQL emitted. Hmm. If I don't know what SQL will be issued how will I determine the best indices? How does the SQL Server team feel about this? I've already heard from Michael Pizzo that you can't expect the same performance as native SQL.
• WinFS. Longhorn includes a new file system. My interpretation is that it's less of a file system and more of an intermediate object model that sits over top of NTFS and the next version of SQL. WinFS let's you view your SQL data as files. A record is a file. Not all files become records though. (I can hear DBAs everywhere sighing). The idea here is to “give users excellent windows experiences“ by getting data out of the silos of applications and bringing it to the shell to be integrated between applications the way users want it. I like the idea in theory but the security aspects scare me a bit. The nice thing is that this is coming in Longhorn - a long time from now so we have time to think about this more...and for MS to try and get it right. You can bind controls in your forms to properties on files (which are records - so those are just columns). Where is the business logic in that tier? Welcome back client server. Not sure how this all works on a LAN.

I was also saw at least 3 user interface models:

• Traditional Smart Client Window Forms. These don't' change much in Whidbey.
• ASP.NET Web Forms. Changing a bit. Still HTML coded into an aspx file.
• Avalon XAML Forms. See my previous post about this. The key point is that it attempts to bring the benefits of Web Forms to Windows Forms and vice versa.

Let's not get into Pocket PC, Smart Phones, WML, Tablet Ink or Media Center. That would make this blog more ridiculous than it already is. Suffice it say that each of these 3 user interfaces all have their own databinding techniques and they are all different. I saw some of the ASP.NET Whidbey two-way databinding today and its nothing like WinForms binding. It's like that team never talks to the windows team. Sigh.

What I didn't see was anything about COM+, Enterprise Services. Where the hell was COM+. Does that all disappear with Indigo? Indigo is only supposed to be a communication platform right?

I guess it's my job as an architectural consultant to value each of these technologies, how they fit together ultimately - and a road map for doing something useful today - that will be useful tomorrow. Nobody at Microsoft has done this yet.

The scary thing is that it seems like all these teams are working in silos and not talking to each other enough. Seems to be a theme. Don't get me wrong, the are doing fabulous stuff but everybody has a different way of doing things. It seems like they spend lots of time developing their technology but not enough time building real applications that sit on top of them.

The good news is that its early for a lot of this stuff and lots of time to fix it and get it right. A lot of Microsoft guys were seeing some of this stuff for the first time themselves.

I suspect that the MSDN Prescriptive Architecture Group has some work cut out for them.

Whidbey is looking good

Yet another long day, I feel like I have been at this conference for a week already, I'm exhausted.

At this moment I am installing Longhorn on one of the extra laptops we brought for just such an occasion. I hope they don't monitor hydro usage per room because between the wireless router, 2 phones, 3 IPAQ's, and 4 laptops plugged in we must be over our quota.

After I install Longhorn, I'll be installing Whidbey. For those who don't know, Whidbey is the code name for the next release of Visual Studio. I'm a software developer and have been for 20 years. So when presenters are on stage using old editors and compiling on the command line. I'm with them and sometimes feel a little nostalgic. As much as I once loved K-edit I wouldn't trade Visual Studio .net for it now. Like any software VS.net has it's problems. But the development teams at Microsoft have done a wonderful job addressing a lot of the issues. Assuming they deliver what I saw today.

So what did I see today?

• I saw tools to make interactive development easier. Like smart tags. You can drop a control on a form then right click and make it something else. Maybe it was a textbox at first but them you decide to make it a date time picker. Just right click select DateTimePicker and you’re done.
• Ever want to try something by coding it? As a result you end up with WindowsApplication1, WindowsApplication2, WindowsApplication3 ... on your machine. Whidbey works like word, your project is not saved until you save it. So you could create a project write some code compile it and run. Then exit without saving and discard the whole thing. (Honest that's what he said.)
• I saw Paul Yuknewicz create an employee.user.vb. What's that you say? Well it's what Microsoft refers to as a partial class. You can have a class split across multiple files and they will be compiled into one. So the file employee.user.vb goes with employee.vb which goes with employee.xsd. You guessed it. It's an extension of a Typed DataSet. :)
• The new snap lines for aligning controls are wonderful. If you are adding multiple labels and controls just drag one near another and it shows you lines to tell when it's lined up with the other controls and the labels. It's hard to explain how nice it looks. I'll be happy to demo it when I get back.
• There is this thing called a DataSource Picker. To bind a control you can simply drag from you DataSource to the control and it binds it.
• There is this new control called a DataContainer, all I can say is PowerSoft DataWindow. (I'll save the comparison for another Blog)
• There are some enhancements to the XML editor. Nothing else to see here move along.
• Actually one really note worthy XML addition. You can set breakpoints in an XSLT file and debug it.
• Oh yeah I remember this is nice. When you add a datasource to DataBinding in the property window. You can grab the editor and stretch it out to see everything. It's really nice

Enough about Whidbey for now.

The exhibition hall was cooking tonight, must have been the free drinks. We stopped into a few booths, chatted with some folks, did a little shopping in the Microsoft Store. Can't tell you what I bought. My Daughters have been reading along, and it's for them.

It's time to unwind and relax, another long day tomorrow at PDC.

Visual Studio .NET Tips and Tricks @ PDC

I'm hosting a birds of a feather Sunday night from 8-9pm at the Microsoft PDC. The topic is Visual Studio .NET Tips and Tricks. Hope to see you there - and grab a beer or three afterwards.

Code: BoF29
Room: Room 402AB

MS Professional Developers Conference...

...here we come.

Myself and fellow ObjectSharpies DennisLee and DaveLloyd are heading out Saturday morning for the PDC in L.A. Stay tuned for our perspectives on Whidbey (essentially .NET 2.0), Yukon (SQL Server 2004?), and Longhorn (Windows 2005?). Key pieces of technology I'll be researching are Indigo (new web services framework) and Avalon (new windows forms framework).

I'm also looking forward to seeing MSBuild and trying to understand how it will compare, compete or compliment NAnt. I still don't see anything about the next version of Visual Source Safe - what's up with that?

If you are in town, look me up and I'll buy you a beer.