Doctor Deploys Blog

This is just a flippant thought so don’t read to much into it but I found it amusing enough that I thought I’d share. Last week there was much discussion about Sun buying MySQL. While everyone was discussing what this meant for Sun and MySQL and the “Open Source Business Model”, I was trying to figure out why this deal felt unusual yet familiar to me.

Then it struck me. What I found interesting was that most of these discussions were about about Sun acquiring the company MySQL. Sun was “buying the M in LAMP”. Then I remembered that Sun had done this before. Sun bought StarOffice years ago that ultimately became the foundation for OpenOffice.org.

Microsoft, on the other hand, tends to hire people with Open Source backgrounds rather than buy “OSS” companies.  I was trying to come up with a list of recent “Open Source hires” when this interview with Sam Ramji showed up that listed some of the most recent people to join the “Evil Empire” (*I* can say that, I actually dressed up like a Stormtrooper to represent the company in public <smile/>). I’d also might add Phil Haack, Scott Hanselman and Rob Conery to the list.

Google, like Microsoft, seems to hire Open Source people more than buy entire companies. I’m thinking of people like Chris DiBona, Sean Egan and Guido van Rossum. But it isn’t like I really track Google’s or Sun’s or Microsoft’s, for that matter, hiring and acquisition practices closely. So maybe I’m just making this all up.

Note, I’m not suggesting that “buying in bulk” is better or worse than “hand picking individuals” to build up a company’s Open Source collection. However, I do wonder how those different approaches might affect a company’s culture. I know that inside Microsoft it feels like Open Source acceptance is growing like slow winter thaw.

 

Original post by Rob Mensching

A few days ago I tried to post my second blog entry of the month. Windows Live Writer returned a very helpful error message from my server that told me I was out of disk space on the SQL Server. That was troubling because I don’t have that many blog entries. It was late though and I didn’t feel like debugging the server software so I called it a night.

I finally got around to digging into the SQL database this morning and discovered the problem. Subtext (my blogging server software here) stores referrals in a database table. Well, that table had finally gotten big. Too big. So I jumped on the SQL administration console and truncated the subtext_Log, subtext_Referrals, subtext_EntryViewCount, and subtext_URLs tables. The fact that you’re reading this blog entry means that I finally fixed it.

Naturally the next thing I need to do in my “copious free time” is to figure out how to avoid this problem in the future. I know the best answer is to work with the Subtext community and upgrade to the latest build then add a feature to clean up these logging type entries from the database on demand (at least) or “automagically” (if possible). The problem is that I’m not sure I want to stay on Subtext.

The main concern I have with Subtext is that it is just big. There are about 45,000 lines of C# code (20,000 lines of comments). I expect all that code has its uses since Subtext has support for hosting multiple blogs and image galleries and such. However, I’m not terribly interested in all that stuff.

BlogEngine.NET is a new kid on the block and interesting because it’s about 16,000 lines of code (5,000 lines of comments). It does seem to be targeted at an individual blogger and is up with the latest blogging technology. However, on my first high level pass through the BlogEngine.NET code I found the formatting of the code style to be pretty inconsistent which is an indication (in my mind) of how much the code is cared for.

Finally, Fredrik Grohn created his own blog engine with something like 300 lines of C# code. However it doesn’t do comments, trackbacks or any other blogging functionality above and beyond RSS syndication. That makes it really bare bones but maybe a reasonable place to start from scratch… if I wanted to do that.

Ultimately, I’m probably going to stay with Subtext (and write a little utility to regularly truncate the logs) because I don’t really have the cycles to spend getting into a new codebase and community. While I’m sure I could learn some cool new tricks playing with blogging server software I expect it would just be a distraction from the much larger projects that I’m working on in my free time. However, I have to admit that writing unit tests for BlogEngine.NET as a way to learn the codebase and help improve/maintain quality of the codebase has quite a bit of appeal to me.

Anyway, I’m back. More blogging to follow.

 

Original post by Rob Mensching

In recent multi-blog conversations between Windows Installer experts Aaron Stebner, Christopher Painter, and Stefan Krueger, it was noted that my statement that ‘Windows Server 2008 logo would require Windows Installer’ in the Channel 9 video Application Compatibility - MSI Installer Issues was out of sync with the published requirements.

Sure enough, the Windows Server 2008 Logo team demoted this from a requirement to a recommendation.  Unfortunately the Windows Server 2008 Logo didn’t let me know they had decided to do this.  Still, the mistake is mine and I humbly apologize for this unfortunate misinformation.  I do sincerely appreciate the community Windows Installer experts efforts in catching and correcting my mistake. ;^)

Back Story
For the back story, I’ll start by observing the underlying conflict here is in picking the right point in the ubiquity/quality spectrum

• Weaken the quality requirements so that any ISV that is willing to pay the fee can get the brand on their box (optimize for the ubiquity of the logo)


• Strengthen the quality requirements so that any software consumer can use the presence of the brand as synonymous with excellence (optimize for the quality of the logo)

I’ll further observe that the Logo program a marketing program and not a standards program.  This means that the engineering experts are simply consultants to their requirements and test cases.  As a marketing program to ISVs, there is significant feedback to push toward the “make it easy” end of the spectrum.

As was pointed out in the insightful conversation among the Windows Installer experts, there is ubiquitous presence of Windows Installer in corporate environments and particular those that need leverage client software distribution tools.  Putting aside the recent virtualization trends for a bit, any corporate customer research will find very quickly that Windows Installer is the de facto standard for desktop application packaging.  For servers, the Microsoft presence and costs of management is still evolving thus a de facto standard is not yet present.

Ultimately, Windows Server 2008 Logo is marketing’s program so they get to make the final decision.  If this choice bothers you as a software consumer, please let your software provider know.

[Author: Robert Flaming]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

In recent multi-blog conversations between Windows Installer experts Aaron Stebner, Christopher Painter, and Stefan Krueger, it was noted that my statement that ‘Windows Server 2008 logo would require Windows Installer’ in the Channel 9 video Application Compatibility - MSI Installer Issues was out of sync with the published requirements.

Sure enough, the Windows Server 2008 Logo team demoted this from a requirement to a recommendation.  Unfortunately the Windows Server 2008 Logo didn’t let me know they had decided to do this.  Still, the mistake is mine and I humbly apologize for this unfortunate misinformation.  I do sincerely appreciate the community Windows Installer experts efforts in catching and correcting my mistake. ;^)

Back Story
For the back story, I’ll start by observing the underlying conflict here is in picking the right point in the ubiquity/quality spectrum

• Weaken the quality requirements so that any ISV that is willing to pay the fee can get the brand on their box (optimize for the ubiquity of the logo)


• Strengthen the quality requirements so that any software consumer can use the presence of the brand as synonymous with excellence (optimize for the quality of the logo)

I’ll further observe that the Logo program a marketing program and not a standards program.  This means that the engineering experts are simply consultants to their requirements and test cases.  As a marketing program to ISVs, there is significant feedback to push toward the “make it easy” end of the spectrum.

As was pointed out in the insightful conversation among the Windows Installer experts, there is ubiquitous presence of Windows Installer in corporate environments and particular those that need leverage client software distribution tools.  Putting aside the recent virtualization trends for a bit, any corporate customer research will find very quickly that Windows Installer is the de facto standard for desktop application packaging.  For servers, the Microsoft presence and costs of management is still evolving thus a de facto standard is not yet present.

Ultimately, Windows Server 2008 Logo is marketing’s program so they get to make the final decision.  If this choice bothers you as a software consumer, please let your software provider know.

[Author: Robert Flaming]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Windows Installer expert Dennis Bareis responded to a previous post, Request for suggestions for updating the 1603 KB article.  As I worked through his points, the problem of “Growing Windows Installer Experts through Troubleshooting” came into focus.

Growing Windows Installer Experts through Troubleshooting
One of the challenges faced by the Windows Installer community is that there are not enough experts with the capacity to go all the way through the stack to the underlying Win32 behavior.

As with most “grow expertise” problems, there are a few high traffic areas in which one has the chance offer a novice the opportunity to build their expertise.

Once one identifies the high traffic areas, one should go to where the traffic is.

Top Three High Traffic Areas for Novices
The top three in my mind are: tools environment, troubleshooting, and design (in order of priority).

The primary instance to grow expertise is where a user of a packaging tool has reached the limit of the tools design and yet still needs to do more.  This opportunity to evolve expertise is generally lost to the Windows Installer because our various tools vendor partners each own their Integrated Development Environment (as they should ;^).

The secondary instance to grow expertise is when there are errors in the underlying experience and one needs to work backward from the low level data into the friendlier higher level constructs.

The tertiary instance to grow expertise is when novices show interest in design.

When I was little…
My goal in updating the KB would be to provide a bit more guidance to the novice that needs (or perhaps even wants) to grow in the direction of becoming an expert.

One of the challenges after reaching the expert level is trying to remember the road traveled so that one might draw a map for those who come after.

It’s been so long since I was a novice, I thought it wise to ask for suggestions on how others guide folks on building their Windows Installer expertise through troubleshooting.

Thanks again for the valuable feedback.

[Author: Robert Flaming]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Feedback on our existing Knowledge Base article for the error 1603 is that ‘it is not very useful.’

My first thought to update the KB would be to go over the troubleshooting techniques such as verbose logging and then how to find and read the errors in the log.

Before proceeding to writing, I thought I’d check-in with the Windows Installer community via this blog.

Are there things besides troubleshooting info you would recommend get covered in the 1603 KB?

Thanks for your consideration.

[Author: Robert Flaming]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

If you watch the front page of the WiX toolset’s web site and get notifications for changes to the Windows Installer XML News on SourceForge and subscribe to this blog then this is the third time you’ve seen this content. I apologize for the message in triplicate but there seem to be a surprising number of people that seem to believe that the WiX toolset has been abandoned because there has not been an update to the WiX SourceForge page in a while.

To combat that belief I am posting this notice widely:

There has been some suggestion that the WiX toolset is a dead project because we have not released a drop to the SourceForge release point in a long while. Those fears are unfounded for three reasons. First, WiX v2 is stable so we are not expecting another build of that version unless a showstopper bug shows up. Second, weekly drops show up at the Weekly Releases release point regularly. Finally, pushing to the SourceForge release point is a manual process for us and thus a lower priority. In any case, development is still very much active and the wix-users mailing list is still the best place to get your questions answered.

At the same time, I’m going to re-evaluate whether ignoring the content on the (IMHO) “fugly” SourceForge pages is a good idea. The freshness of the data presented there makes a larger first impression than I anticipated.

 

Original post by Rob Mensching

Customers have mentioned having trouble finding Windows Installer support when they try to navigate the maze of Microsoft support offerings.

If you too need to find Windows Installer specific product support, the support staff dedicated to Windows Installer can be reached by

1. For non-Premier Service accounts, see the Professional Support site




1. Choose an option from the “Developer” row


2. Mention key words “Windows Installer”, “MSI”, and “Development”


2. For Premier Service accounts, contact your Technical Account Manager

Windows Installer product support services are provided by a dedicated team of specialists inside the larger Microsoft support organization.

If you stump these specialists with a difficult or rare issue, they have an escalation path into the Windows product group.

[Author: Robert Flaming]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team