Jerry Dennany's Occasional Clue

As I've posted before, MSBuild support is noticeably absent in the next version of Visual C++.  With all of Microsoft's hype over MSBuild, this is a glaring omission.  As a new blogger, and member of the Visual C++ IDE's project/build system team, perhaps Josh can help explain this?

I've read quite a few articles and books that proclaim the benefits of multi-threading, and many people admire the beauty of a nicely threaded program.  I agree fully - a well-implemented threading server certainly can reap great performance benefits.  SQL Server is a wonderful example of this.  So much thought was put into threading in SQL Server that they implemented their own thread scheduler, pre-empting the OS threading model through some quite clever trickery.

1. If Windows Installer is Microsoft's “official” installation technology, then why the heck don't they use it and support it better?  It would make our lives a lot easier if Microsoft released a merge module for the .NET Framework, for example.  It's the perfect example of where a merge module is needed.  Instead, we get silent install kludges.

As my friend Paul Wilson points out, sometimes technical answers are really hard to find.  As I browse the ASP.NET and C# newsgroups, weblogs, and Forums, answers abound on how to bind a dataset to a control.  I can find numerous explanations of how .NET garbage collection works, best practices utilizing the dispose pattern, and many other helpful hints.

So, I've been 'under the Radar' recently, as I've just started a new job with Eclipsys Corporation.  I work on our interface engine, eLink.  You could think of it as a very specialized BizTalk server.

Kirk Allen Evans has an excellent post on Change Control.  He points out that many software developers view change control as synonymous with Visual Source Safe, and leave things at that.  He's correct in that there's much more to Change Control than source code control, and that Rational's solutions are only useful for those few cash-rich shops that can afford it.

I often talk to people in small software shops who are violating some of the fundamental tenants of modern software development.  Today I'd like to visit a topic that everyone knows about, but few people practice properly.  And no, I'm not talking about flossing.

I was a bit surprised reading Robert McLaw's recent complaints about his problems building deployment solutions for his software products.  As a tool vendor himself, he should realize that Visual Studio is not meant to be the be-all end-all in tools.  Sure, it offers an extremely rudimentary means of creating installer projects, but it isn't suitable for anything but the most basic of installations.  If you want a robust installer, purchase a robust tool for creating them.  (I see now that he's taking a look at a few solutions).