Component Rules 101

RE: Component Rules 101

Robert — Wed, 05 Nov 2003 07:59:00 GMT

Many man month have been lost to the figuring out a) an app did or did not need to break the component rules and b) there is no easy way to message the consequences. Darwin's guidance in the SDK is better than it was however in the majority of cases its so easy to break the rules and ship before the rule violations are recognized. After shipping, the best you can do is yes we sure shot the user on that one, let's try not to do that again. The problem boils down to the rigidity of a darwin component is inversly proportional to the transparancy of what should be in a component. Should a component contain a single file and it's registration? that's naieve (please pardon the spelling) best case but it does not allow for the evolution of the file and it's registration. Version to version files sets morph into different file sets as the engineering evolves. As a component fragments or grows, how does one continue to share appropriately? There are other complexities to picking a component composition. For instance, what if none of the files in a component have a version and there is no registration? This is a messy one because there is no single behavior that works perfectly for all cases. Another case is the tiny files of content things like MSDN and data centers proliferate. For these scenarios, you'd really like to strip the majority of the integrity systems out of Darwin as integrity checking ends up surpassing the value it provides (in the aggrigate). Another fun case is where there are dependent references between components. (ready for a juicy new thread Rob?) one of the things Darwin failed to get was adequate representation of dependencies. Knowing ones dependencies so that ont can articulate them and validate they are fulfilled is an essential part of engineering. Darwin missed this entirely but to their defense no one else in the Darwin era really groc-ed the importance of articulating and validating dependencies either. The problems with componets are vast and deep as well as subtile and sophisticated. Rob groc this uniquely, in my experiance. It sure is fun to watch Rob come in to a room of 20 people utterly confused about the state of their world and have Rob summarize their mistakes and the available solutions in less time than it took to complete the introductions. Good thing for Microsoft that Rob is generous in spirit and committed to making all of Microsoft a better place.

RE: Component Rules 101

David — Fri, 07 Nov 2003 17:51:00 GMT

One component topic I would be interested in is validation. There is an issue in the repackaging industry at the moment with ICE 33 errors. What is your view and experience of ICE 33. Is it possible to solve all ICE 33 errors?

RE: Component Rules 101

robert — Sat, 08 Nov 2003 11:01:00 GMT

Office does not run ICE33... I'd call that a vote of no confidence... ...and generally repackagers are bad news... Repacagers can't know enough about a product to make the right componetization calls.

Inside the MSI file format, again.

when setup isn't just xcopy — Tue, 10 Feb 2004 12:01:00 GMT

Another tour of the MSI file format.

re: Windows Installer XML (WiX) toolset has released as Open Source on SourceForge.net

when setup isn't just xcopy — Wed, 07 Apr 2004 03:27:00 GMT

re: Registering an Assembly for COM Interop in a MSI file with the Windows Installer XML toolset.

when setup isn't just xcopy — Fri, 30 Apr 2004 08:29:00 GMT

re: Component Rules 101

Naren — Tue, 04 May 2004 03:37:00 GMT

Component management pitfalls pointed out here have dogged our company's installer efforts from the start. We even believe MSMs were the way to share "components" (non-msi definition).

But we have learnt our lesson, we don't let MSI manage our shared pieces. We make separate MSIs for each and we manage the dependencies ourselves. WE can now make MSIs with gleeful abandon of component rules. Mind you we don't, but if we break a component rule here or there, we don't end up in a soup.

Excellent MSI component tutorial

Aaron Stebner's WebLog — Sat, 08 May 2004 08:16:00 GMT

Welcome, Aaron!

the1's WebLog — Sat, 08 May 2004 09:03:00 GMT

O'Reilly Net on Getting Started with WiX.

when setup isn't just xcopy — Fri, 14 May 2004 09:57:00 GMT

Imagine a blog entry where I discuss a couple issues in an introduction article to the WiX toolset I found online.

re: My philsophical musings about building setup for software.

when setup isn't just xcopy — Mon, 17 May 2004 19:22:00 GMT

Excellent MSI component tutorial

Aaron Stebner's WebLog — Wed, 19 May 2004 19:13:00 GMT

re: Component Rules 101

Dan — Thu, 27 May 2004 05:36:00 GMT

Um, maybe everyobody else knows the answer, but I've got what seems to me like an obvious question:

Why doesn't Microsoft fix this design flaw?

re: Component Rules 101

Rob Mensching — Thu, 27 May 2004 13:56:00 GMT

Dan,

How do you "fix" something that is fundamental to the architecture of the system that hundreds to thousands of applications have come to depend on for their installation? You can't just completely change the rules and expect those applications to keep installing. And you certainly can't just break all those applications.

Instead, you find yourself in a very difficult situation. Trust me, if it was easy, they would have fixed this a long time ago.

Well, not 'fix', but 'extend'

Dan — Sat, 29 May 2004 07:17:00 GMT

Well, you're right--can't just go ripping the carpet out from under everybody.

However, they _could_ come up with something new, something very similar to the original (probably forked off v1) (not like win32 and .NET), but that had the correct mechanism. It uses a separate database or registry or whatever so you can use the two versions side by side (SxS!). They maintain both versions (like win32 and .NET); v1 is frozen, and left around for whoever wants/needs to use it, and everybody doing new work uses v2.

Perhaps the problem isn't causing people enough headaches for them to justify the cost (monetary and otherwise) to do this, but I think it's reasonably possible to do. (Although, why do you think people roll their own install? They must think that what's available isn't cutting it...) Just my $0.02.

What I would do if I didn't continue to

when setup isn't just xcopy — Sat, 26 Jun 2004 09:11:00 GMT

Imagine a blog entry where I ramble along after having my wisdom teeth pulled and come up with something of a vision statement.

Creating localized MSI files using WiX toolset and .wxl files.

when setup isn't just xcopy — Tue, 30 Nov 2004 11:31:00 GMT

Imagine a blog entry where I discuss the WiX toolset localization features and .wxl files in detail.

Learning WiX: Part One

Ryan Lowe's Blog — Wed, 09 Feb 2005 23:29:00 GMT

Learning WiX is not just about learning the WiX toolset. It appears that in order to use the toolset properly you need to know quite a bit of background of setup on Microsoft Windows in general including the structure of...

Learning WiX: Part Two

Ryan Lowe's Blog — Fri, 11 Feb 2005 20:33:00 GMT

After more learning I think I need to backtrack even further with the WiX toolset and Windows Installer SDK. There are some fundamental decisions my team needs to make about how the product installation will work and it's something that...

Component rules vs. file versions

Hackward and Foreword — Sat, 09 Apr 2005 22:38:28 GMT

Using MsiInv to gather information about what is installed on a computer

Aaron Stebner's WebLog — Sat, 02 Jul 2005 04:11:52 GMT

As I was reading one of the posts on Quan To's new blog, I noticed that someone posted a link to a tool...

Creating localized MSI files using WiX toolset and .wxl files.

when setup isn't just xcopy — Tue, 12 Jul 2005 20:51:50 GMT

Imagine a blog entry where I discuss the WiX toolset localization features and .wxl files in detail.

How Windows Installer handles file replacement logic for versioned and unversioned files

Aaron Stebner's WebLog — Wed, 31 Aug 2005 07:29:09 GMT

I ran into an interesting problem yesterday where a team had built an MSI-based setup package, and they...

How Windows Installer handles file replacement logic for versioned and unversioned files

Aaron Stebner's WebLog — Wed, 07 Sep 2005 08:20:14 GMT

I ran into an interesting problem yesterday where a team had built an MSI-based setup package, and they...

re: Component Rules 101

Christopher Painter — Wed, 22 Mar 2006 18:38:42 GMT

How does this effect merge module retargeting? If you have a MM that has a component which allows retargeting, aren't you effectively doing the same thing of having 2 components with different resources ( dir1\f1 and dir2\f1 ) associated to the same c1 guid?

re: Component Rules 101

Blog Police — Fri, 08 Sep 2006 22:09:19 GMT

Christopher Painter is a blog hog

Building setup packages for Visual Studio project templates and starter kits

Aaron Stebner's WebLog — Mon, 02 Oct 2006 04:00:37 GMT

This article describes&nbsp;how to create an MSI-based setup package to install project templates, item...