Monthly Archives: April 2008

I spend a lot of time working on builds. I’ve done it for years for many companies and in many environments. Recently I suggested in the WiX-Users list that it would be a good thing to refactor the NAnt/CVS/SourceForge system into a clean MSBuild/TFS/CodePlex system. Naturally my opinion was ripped as always by Bob Arnson who claimed that it was too distruptive and a bad ROI.

Course the interesting thing is WiX hasn’t had a weekly build in over a month now and a recent blog by Rob explains why. It seems that the Visual Studio team is providing a developer resource to do some build refactoring and that the entire code baseline is currently unstable.

Very interesting indeed…

Personally I don’t understand the concept of `holding off on builds for awhile` though. I’ve always been tought to build early and build often. As many refactorings that I’ve done over the years, I don’t believe I’ve ever brought a build down for an entire month and counting.

Back in December, I posted an article about the incredible size of the .NET 3.5 framework. In it I complained that the framework redist package has bloated at an astounding rate.

Since that time I had a couple of responses from both ends of the spectrum. Aaron Stebner defended the size claiming (without mentioning my name):

I have seen some size comparison charts that show the .NET Framework size growing from 20 megabytes in 1.0 up to 50 megabytes in 3.0 and then 200 megabytes in 3.5. It looks like this type of size chart was based on the size of this full install package for the .NET Framework 3.5. That isn’t really an accurate comparison though.

On the other hand, many agreed with me. Such was the case with Microsoft C# MSVMP Rich Strahl. He recently wrote a blog entry about the challenges of adopting the 3.5 framework.

At the time, my observations were mostly academic. We can argue back and forth over whether it’s `fair` or not to talk about the framework being a 57MB package or a 197MB `union of packages` but the reality is that it still needs to be serviced in a variety of deployment models.

Recently I delivered a project to a client that had several dependencies. The application was a tray app ( .NET 3.5 ), an optional Office 2003 add-in ( VSTO2005SE – 6MB ) and an optional Office 2007 add-in ( VSTO 3.0 – 2MB ). The application is intended for web download distribution rather then physical media distribution.

With this in mind, I decided to consume the VSTO runtimes into the installer but only consume the web download version for the framework installer. According to `those in the know` this is the way it’s intended to be since the download bootstrapper can pull only the pieces the target system needs.

Now that the installer has been kicked around a bit in the wild, I’ve only recieved one negative feedback: “It’s painful to wait 20 minutes while the framework downloads. Can you do anything about it?”

If anyone reading my blog has a suggestion, I’m listening. But from where I sit, there isn’t a whole lot I can do about it. I can’t get the developer to drop WPF. I can’t drop support for either version of Office and the customer doesn’t want to use a physical media distribution model.

I guess all I can really do is hope that people will use Windows Update and that .NET 3.5 penetration will rise. Because while it’s really easy for an ISV to develop vertical applications using .NET, deploying them painlessly is an entirely different story.

I recently needed to modify an MSI installation to detect when the target system is running a version of Windows Server 2008 installed with the Server Core installation option. Why, you ask? Because several of the UI utilities installed with the product won’t work on a system that doesn’t have the Windows Explorer user interface installed so I needed to optionally disable the features associated with those utilities when running on a Server Core instance of Windows Server 2008.

To my dismay, I discovered that MSI doesn’t natively expose the ProductType values returned by the GetProductInfo Function. [Hey MSI team, how about adding this in 4.5?]

Given this fact, the proper way to detect a Windows Server 2008 OS installed with the Server Core option would be to write a custom action that queries the aforementioned API and sets an MSI property when any of the *_CORE* values are returned by the pdwReturnedProductType parameter (such as PRODUCT_DATACENTER_SERVER_CORE or PRODUCT_ENTERPRISE_SERVER_CORE or PRODUCT_STANDARD_SERVER_CORE or PRODUCT_WEB_SERVER_CORE, etc.).

As Chris pointed out when I discussed this with him, if you’re using a vendor tool to create your MSI installation then the tool may have an alternate method of detecting Server Core (InstallShield can do this via an InstallScript CA).

However, if you’re not using a vendor tool or if creating a CA to query GetProductInfo isn’t desirable in your situation, you can detect a Windows Server 2008 installed with the Server Core option by the fact that the Windows Explorer user interface isn’t installed on Server Core.

To do this, add a search for “explorer.exe” located in the %windir% folder (see MSI example table records below). Then use the public property set by your search in combination with the VersionNT and MsiNTProductType MSI private properties to detect Server Core.

AppSearch Table Record:

OS_SUPPORTS_UI findWindowsExplorer

DrLocator Table Record:

findWindowsExplorer [WindowsFolder] 0

Signature Table Record:

findWindowsExplorer explorer.exe 5.0

Conditional Statement (true if Server Core running)

VersionNT=600 AND MsiNTProductType>1 AND NOT OS_SUPPORTS_UI

In fact, assuming MS doesn’t depricate explorer.exe in a future version [big assumption], just remove the OS version and product type values from the condition and specify ‘NOT OS_SUPPORTS_UI’ for a condition that should work on both WS2K8 Server Core as well as future versions of Windows w/o UI support).