Jerry Dennany's Occasional Clue

DataGrid Girl was complaining about the cost of MCSD certification testing, a common refrain amongst techies on the certification treadmill. Something that might be news to any US veterans out there is that Uncle Sam might help - the GI Bill will pay for certification testing.
I know that it's saved me a pretty penny - I'm working on an MCSA / MCDBA / MCSD combo, something I don't think that I'd really consider if this was all coming out of my pocket.
Also, try bugging your employer - There really are benefits to having at least a couple of MCPs on staff, including the Microsoft Certified Partner program.  For less than price of an MSDN license, they actually get over $10,000 worth of software licenses, including all the MSDN goodies.  Having MCSDs on staff is a good marketing gimmick, too.
I don't usually plug MS stuff, but there are pretty good arguments for your employer footing the certification bill.

I'm working on porting an old MS C++ to Managed C++, and then perhaps on to c#.  So, I open the old .dsw project in VS.NET 2003, and whammo!  Instant project conversion, right?
Well, sorta.  As soon as I set the project to compile with managed extensions (It Just Works, right?), i get the following compiler error:

Command line error D2016 : '/RTC1' and '/clr' command-line options are incompatible

It should be simple enough to go into the project settings and turn off the RTC1 option, right?

So, I do so, and everything should work great.  I hit the build button again, and no dice.  My new friend good ol' D2016 pops back up.  Didn't I turn this option off?

Fortunately, VC++ 7.1 generates a really cool BuildLog.htm, and I take a gander.  Hmm...  According to the BuildLog, the /RTC1 switch is still set on each of my .cpp files.  A quick Google Search confirms my suspicions that this is indeed an IDE Bug. So, I go into the compiler settings on every single .cpp file, and turn off the /RTC1 option.

Simple enough, really, if you know where to look.  A few log files later, and a few minutes on google solves about 80% of a developer's problems.  A shout over the cube wall solves another 10%.  A healthy dose of blood, sweat, and tears (and a curse or two) slays the remainder of the bugs.

I'd guess that every developer runs into several of these problems each day, and dispatches them rather quickly.  I'd also say that it's things like this that will prevent the 'expert systems' from putting programmers out of jobs.  There will always have to be 'experts' on the expert systems.  Someone's got to know how to run these things. 
---
Prologue:  I do have an associate, however, who absolutely refuses to read any reference books or do any google searches. Most of the time he shouts the question 'over the wall' as soon as it pops into his mind.  He's kinda like the NetBEUI of programmers.  Good for small projects, but chatters a lot.

I'm going to my first .NET users group meeting here in Atlanta Monday evening, and I look forward to meeting some like minded people.  The main presentation will be "Deploying .Net Applications Using Visual Studio" by Doug Ware.  I've never been really into this user group stuff, so wish me well...

A hearty welcome to Paul Alexander, who points out that DLL Hell hasn't gone away, no matter what Microsoft would like to claim.

I agree!

There's been a lot of talk lately of SourceGear's Vault as the savior of Source Control repositories.  Lotsa Hype (with a capital H) from  Robert Hurlbut , Matthew Reynolds, and Marc LaFleur , amongst others.  Heck, with all this buzz, my company's Super Secret Weapon (and illustrious Software Architect) Paul Wilson was sitting up and taking notice. I heard him muttering something about wanting to take a look (and possibly review) Vault.  (Are you listening, Eric? )  This is after several years of my preaching to our team about how much Source Safe sucks, and we need to lay out a few bucks to purchase a _real_ solution.
 
Why is it that all of a sudden the microsoft developer community is sitting up and taking notice how bad VSS is, after us config manager types have been preaching it for years?

Well, one of the answers was always that VSS is "free".  It was included with an MSDN subscription, and with certain versions of visual studio 6.  Really, though, if you purchase the client separately, it runs about $400 .  I know, 'cause we have to buy it for our BA's, QA, etc.  That's right, $400 per user for this piece of junk.

Does Microsoft use VSS?  Not on most product teams, from what I can gather.  In fact, Windows 2000 is rumored  to have used a modified version  of Perforce.

Ok, I'll admit it - I am very fond of Perforce - It's everything that VSS is not, and it is more mature that Vault.  It does WAN / internet depots in its sleep (I currently host a depot over my paltry ADSL link), it's multi-platform (for all you multi-OS shops), it's got atomic commits, change sets, easy branching, the list goes on.  Oh, and did I mention that it doesn't require that expensive SQL Server licence?  Also, it's absolutely FREE for open source projects.  I've obtained a free copy through the open source offer, and I strongly encourage all other open source projects to consider this as well.  This product is also head and shoulders above CVS (or Subversion, the soon to be CVS-killa.)

So, back to the issue of Vault - why so much hype over this product?  Personally, I think it's because it's a major commercial product written on the .NET platform, something that is still rare.  Most of us interested in seeing .NET succeed are very interested in promoting products that leverage this technology, even if they aren't necessarily best of breed.

I'm a little more pragmatic.  While C# has brought me a love for programming that I haven't experienced in several years, I'm hesitant to promote a .NET product just because I like the framework it's built upon.  Perhaps Eric wants to send me a copy of Vault to change my mind?

Several years ago, one of the big complaints about windows was that there was no operating system 'approved' method of installing programs.  Linux enthusiasts of the Redhat persuasion had their RPMs, the BSDs had their 'ports' collection, and all of the unix variants supported the lowest common denominator, "make && make install".  What did windows have?  Well, we had third party solutions like InstallShield and Wise Installer (the two most popular, though there were plenty of products in the tertiary market).  Application developers learned a third party 'custom' language such as InstallScript and the many idiosyncrasies that went along with them.  (InstallScript was a quaint mix between a C style syntax, Pascal syntax, and in its later iterations, a faintly VB-esque pseudo-OO programming model. Oh, and my personal favorite: sometimes a non-zero return value meant true.  Other times it meant false.  Still other times it signified an error condition.)

I keep wandering off subject, don't I?

About the same time Windows was in search of an installer solution, Office 2000 was in development.  Office has a particular niche in the configurability arena, as it supports just about every language imaginable, with various product configurations.  Just off the top of my head, I think I recall Office (Academic), Office Professional, Office Small Business Edition, Office Premium, MSDN Office Premium, and several others that I am certain that I am forgetting.  Let's not leave out the fact that there's also each product sold separately as Word, Excel, and Access.  Multiply that by a couple dozen supported languages, and you've got yourself a configuration management nightmare.

Now add the requirement that corporate administrators must be able to configure the installation package according to business requirements, automating deployment and sometimes customizing the installed application.

Enter the Microsoft Office Installer, the basis for what was to become Windows Installer. Originally designed by the MS Office team, the Office Installer enabled the office team to fulfill complex configuration issues.  Based on its own internal proprietary database, the act of making an MSI package basically means packaging a set of file, registry, and custom action objects into a database format, and generating meta data about these objects.  This meta data is also stored in the MSI.

So - You might be asking me what the big deal is- Where is this broken?

Well, unless you are actually deploying Microsoft Office, several things:

1.  We are taking a highly procedural group of actions (Collect User Information, Validate Information, perform Pre-Installation Checks, Copy (and possibly  register) Files, perform Post Installation Checks, and finally, Uninstall application).  In all but the most extreme cases, the order of these is almost always known at installation design time. 
2.  So, we take this procedural set of actions that fit into a procedural methods (think scripting languages), and we shoehorn them into what's basically a DBMS. Because the human mind has difficulty with this mapping, we must develop tools to do this mapping for us.  Our toolsets basically re-map the DBMS into a procedural model at design time.  That's just how we think.
3.  Ok, it's deployment time - what do we do again?  An extra ice cream cone goes to anyone who said that the Windows Installer once again generates a procedural script based on user input and information in the MSI database.

So we go Procedural (Design Phase) -> Procedural & MSI - DBMS iterations (Implementation Phase) -> MSI - DBMS (Final Packaging) -> Procedural (Final Deployment).  Notice that we are only using the MSI DBMS for storage?  Any time that we actually do anything useful with the MSI, it is converted to a procedural model.

Don't think that producing an MSI is that difficult?  You're probably not doing things correctly then. Hell, the windows installer has its own SDK. If you haven't spent time with the SDK and the tools, you are probably missing something that you are 'supposed' to be doing.  Either that, or XCopy would probably pretty much work for you anyways. Does it matter that you might not be doing it correctly?  Probably not, as long as your app installs and uninstalls.

Is MSI an amazing technology?  Yes - but it's really too complicated.  It was designed for the worst case scenario, MS Office.  How many of us are developing a solution that complex?

I'm getting a headache just thinking about all of this.  No wonder we all find the dream of xcopy deployment so wonderful.  (XCopy is broken, too.  Ok, maybe not broken, but it's so limited as to be virtually useless. I'll save that rant for a different day.)

Oh - as an aside, another major architectural problem with windows installer is that it has no native multi-lingual support.  All such support is currently hacked on, er tacked on 'after the fact'.  Pretty major oversight, and one I would have least expected from the MS Office team.

I'll continue with this a bit later, but first I'd like to see what a few others have to say...  Anyone?