Doctor Deploys Blog

The end of my first ever Scrum Sprint is impending. For the last three weeks (of a six week Sprint) I have been scrambling to get all the pieces of my part of the puzzle complete. Why is it a scramble instead of a nice run through the backlog? Because various pieces didn’t come together well (i.e. the way I though they would) in the beginning.

Throughout the Sprint there have been a lot of meta-scheduling questions where it feels like we often fall back into a Waterfall way of thinking. You know all of the design up front and all the test at the end. I really like the idea of Scrum and we’ll settle into it better in future Sprints.

Anyway, I’m not dead just mostly buried which is better than last week when I was completely buried and totally sleep deprived. More soon.

 

Original post by Rob Mensching

Why do I care about shared component patch uninstalls?

There has been an ask from Windows Installer customers to improve the servicing story surrounding shared components. We could summarize the asks into following points: 

1. I want Windows Installer to keep the highest version of the file across products when an update to a shared component is uninstalled.


2. I do not want to get any source resolution dialogs while installing or uninstalling updates to a shared component.

Look at the PPT attached with this blog post to get an overview of the scenario. If you think you might ever get into a scenario described in the PPT, then you should read on.

How does Windows Installer 4.5 address this?

This section providers an overivew of how Windows Installer 4.5 addresses this

1.      Components that need the robustness that this feature provides should be marked appropriately.

2.      When installing an RTM version of that component, or when a patch carries an update to the component, we store info on the highest version of the component due to this product, irrespective of whether the component is actually updated on disk.

3.      When the file on disk is to be updated, enumerate all the product clients for the component being updated.

a.       If the cache baseline opcode is being generated for the product currently being installed Then

                                                              i.      The RTM version of the component is looked up and that becomes the source of the cache operation.

Else

                                                         i.            Verify that the component at the target location is the RTM version for this product.

                                                       ii.            Cache the component from the target location into all the component’s clients’ empty RTM caches

b.      This behavior will ensure that any patches to any of the products that carried the component will not result in any source resolution dialogs. This copy-on-write behavior also provides the optimal disk usage.

4.      When a patch is being uninstalled, we do the following:

a.       Update the registration created due to this patch in step 2

b.      If the component affected by this patch uninstall has opted for the shared component robustness functionality

Then

                                                         i.            If file version on disk > file version referenced in transform of the patch being uninstalled then,

a.       Do not down-rev the component.

                                                       ii.            If file version on disk <= file version referenced in transform of the patch being uninstalled then,

a.       Enumerate the registration created in step 2 to determine the highest versioned component and the corresponding product/patches

b.      If the component version calculated in the previous step is the same as the version of the component on disk then, we have nothing else to do.

c.       Use the the component cache created in step 3 along with the patch that can take this component to the highest version to create and copy the resultant version of the component.

c.       Else behave like Windows Installer 3.1.

How do I turn it on?

If any product marks its shared component with msidbComponentAttributesShared attribute, then this component gets this behavior irrespective of whether other products have marked it that way or not. Here’s the definition of this attribute:

//msidefs.h enum msidbComponentAttributes {             … #if (_WIN32_MSI >= 450)             msidbComponentAttributesShared = 0×00000800; #endif // (_WIN32_MSI >= 450) };

The DisableSharedComponent machine policy will let administrators turn off the opt-in behavior of msidbComponentAttributes. The following table lists possible configurations:

DisableSharedComponent	Description
0	This is the default value. When this value is set, packages can opt-in to use the Windows Installer’s shared component functionality by setting their component’s attribute to msidbComponentAttributes.
1	This value will not let any package on the machine get the shared component functionality as desired by setting the msidbComponentAttributes component attribute.

Caveats

Targeting Limitation

It needs to be called out that the assumption that this feature makes is that every patch targets the RTM version of its product. This ensures that the binary delta contains the delta for the RTM product. This can be done by building a patch to shared components such that:

1.       The patch targets RTM, by listing the RTM version of the product in the TargetImages table of the PCP.

2.       If targeting RTM image is not an option, patch authors could also use ExternalFiles table of the PCP to provide the RTM version of the file. This will ensure that the delta inserted into the patch will be able to update the RTM version of the file.

New functionality is bound to Windows Installer 3.0 Baseline Caching

It needs to be noted that this feature is available only when caching is not disabled. Also, for this feature to kick in there should be at least one MSI 3.0 minor update patch or all MSI 3.0 patches (as is the requirement for baseline caching to kick in).

Component State is Agnostic to Non-File Resources

Note that this feature doesn’t restore the registry keys while it restores the right version of a file. This assumes that the registry keys are compatible across different versions of the component.

Shared Components and Languages

Two files with the same version but for different languages are regarded as same.

A Patch That Opts-in

A patch can add the msidbComponentAttributesShared attribute and start getting the benefits of this new feature. However, when the last patch that opted in for this functionality is being uninstalled, then that transaction doesn’t get this functionality because the in-memory view of the database doesn’t contain this patch and we will behave the way when dealing with any other attribute that was patched.

 

[Author: Hemchander Sannidhanam]
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 this blog post, I will provide an overview on what you can do with the new patch uninstall custom actions and how they work. The hope is that by understanding how patch uninstall custom actions work you will be able to put this new custom action type to use easily.

Why Patch Uninstall Custom Actions?

If a patch carries a custom action or carries any updates to a custom action then, that updated custom action is not run when uninstalling the patch. Also, a custom action does not get the information associated with the patch that is being uninstalled. You can look at the attached PPT to get a high level overview of the problem and the way Windows Installer has addressed it in Windows Installer 4.5

How to use this new custom action type?

         A custom action that wants to run during patch uninstall will mark itself with a new msidbCustomActionTypePatchUninstall attribute. This attribute can be specified in the ExtendedType column of the CustomAction table. This new column is of type DoubleInteger and can be added when releasing a patch. A custom action marked with this attribute will run only when a patch is being uninstalled.

a.       This attribute can be part of the original MSI. But, this attribute cannot be dropped or added by a patch to an existing custom action.

b.      A new custom action with this attribute can be added by a patch.

c.       When running a patch uninstall custom action, Windows Installer will use the custom action provided in the patch being uninstalled.

d.      Windows Installer will make the updates within the patch being uninstalled available to the patch uninstall custom action.

Walkthroughs

Walkthroughs in this section are aimed at understanding several key scenarios associated with this feature. Each walkthrough will discuss what occurs when certain events are triggered. They however, do not discuss the “how�. Walkthroughs try to provide a reason on why certain behavior is appropriate and why certain tradeoffs were made.

In Stream RTM Patch Uninstall Custom Action

1. Install Product A:




1. RTM version of the product A carries a patch uninstall custom action PatchUninstallCA1.


2. This custom action is provided in a Binary Table in the form of RTMCA1.exe.


3. Upon this install, the custom action is not run.


2. Apply Patch Q1:




1. Patch Q1 updates the custom action PatchUninstallCA1:

                                                               i.      It has a patch sequence (as authored in the MsiPatchSequence table) number of 1.0.2.0.

                                                             ii.      It replaces RTMCA1.exe in the binary table with Q1CA1.exe.

1. Upon this patch application neither custom action is run.


1. Apply Patch Q2:

1. Patch Q2 updates the custom action PatchUninstallCA1:

                                                               i.      It has a patch sequence number (as authored in the MsiPatchSequence table) of 1.0.1.0.

                                                             ii.      It replaces RTMCA1.exe in the binary table with Q2CA1.exe.

1. Upon this patch application neither custom action is run.


1. Uninstall Patches Q2 and Q3:

1. Patches Q1 and Q2 are uninstalled by setting MSIPATCHREMOVE=<Patch GUID of Q2><Patch GUID of Q1>


2. When both the patches: Q1 and Q2 are uninstalled at the same time, custom action PatchUninstallCA1 ends up running Q1CA1.exe.

This walkthrough summarizes three behaviors:

1. A custom action marked by the msidbCustomActionTypePatchUninstall attribute will be run only during a patch uninstall.


2. When two patches that modify a custom action are uninstalled in a single transaction, the patch that has the highest patch sequence number wins. Note that the reason for respecting patch sequence numbers during patch uninstall is to have the ability to resolve ties in situations where a patch might become inapplicable implicitly.

While the above walkthrough takes an EXE custom action as an example, the behavior applies to even DLL and script custom actions.

On Disk Patch-Added Patch Uninstall Custom Action

1. Install Product A:




1. RTM version of the product does not have any custom actions. It installs file FTK.exe whose file table key is FTK. Version of FTK.exe is 1.0.


2. The product is installed without running any custom actions.


3. Sequence numbers of some important actions:

Action	Sequence Number
InstallFiles	900
PatchFiles	1050

1. Apply Patch Q1:




1. Patch Q1 adds a new patch uninstall custom action Q1CA and another new deferred patch uninstall custom action Q1CADeferred. When run, this custom action executes FTK.exe.


2. Q1 carries FTK.exe 1.1.


3. Action sequence numbers:

Action	Sequence Number
Q1CA	1000
Q1CADeferred	1005

1. Upon patch install, FTK.exe will be updated to 1.1 and neither of the patch uninstall custom actions will be run.


1. Apply Patch Q2:

1. Patch Q2 adds another new patch uninstall custom action Q2CA. When run, this custom action executes FTK.exe.


2. Q2 carries FTK.exe 1.2.

Action	Sequence Number
Q2CA	850

1. Upon patch install, FTK.exe will be updated to 1.2 and Q2CA will not be run.


1. Uninstall Patches Q1 and Q2:

1. During patch uninstall the custom actions marked to run only during patch uninstall are run. The sequence in which they are run is:

                                                               i.      Q2CA. This runs FTK.exe 1.2 because the files have not been updated by the patch uninstall operation yet.

                                                             ii.      InstallFiles

                                                            iii.      PatchFiles

                                                           iv.      Q1CA. This also runs FTK.exe 1.2 because the files have not been updated by the patch uninstall operation yet.

                                                             v.      Q1CADeferred. This will queue the custom action to run during script execution.

                                                           vi.      During script execution, FTK.exe 1.0 will be run because the files have been updated by now.

This walkthrough summarizes the behavior that sequence numbers are important for patch uninstall custom actions that rely on non-“Binary Table� resources. Just like any standard custom action, based on when they are executed, they get different versions of the custom action.

Note that this behavior is applicable to DLL and script custom actions as well.

Patch Uninstall Custom Actions’ Ability to Access Install State

1. Install Product A:




1. RTM version of the product carries a patch uninstall custom action RTMCA. RTMCA is a patch uninstall DLL custom action.


2. Upon install of this product RTMCA is not run.


3. Action sequence numbers:

Action	Sequence Number
RTMCA	1000

1. Apply Patch Q:




1. Patch Q carries two patch uninstall custom action DeferredQCA and RollbackQCA.

                                                               i.      DeferredQCA is a patch uninstall deferred DLL custom action and

                                                             ii.      RollbackQCA is a patch uninstall rollback DLL custom action.

1. Patch Q updates the RTM version of product A in the following way:

                                                               i.      Adds a new component C. This results in the following changes:

·         A new component added to the Component table.

·         A new component-feature mapping in the FeatureComponents table.

·         A new registry key associated with the component results in a new entry in the Registry table.

                                                             ii.      Changes an existing file. This results in:

·         A change in file version of an existing file in the File table.

1. Action sequence numbers

Action	Sequence Number
DeferredQCA	1010
RollbackQCA	1011

1. Upon patch install none of the patch uninstall custom actions is run.


1. Uninstall Patch Q:

1. Upon uninstall of patch Q, RTMCA will be run first amongst all patch uninstall custom actions. This custom action would like to know info that is being altered due to this patch uninstall. It therefore queries MsiTransformView<Patch GUID> table (for example, MsiTransformView{EA2EEDE8-94F8-4013-A370-36435C4B1259}) to get that info. For this walkthrough, this table will have the following contents (Several entries not included for the sake of clarity):

Table	Column	Row	Data	Current
File	Version	BlueFile	1.2.0.0	1.0.0.0
Component	Condition	C_PS_QFE2	NULL	NULL
Component	Attributes	C_PS_QFE2	2	NULL
Component	ComponentId	C_PS_QFE2	{88838DDB-DA25-4C4A-B221-E2BAC0305975}	NULL
Component	Directory_	C_PS_QFE2	PATCHSEQFOLDER	NULL
Component	KeyPath	C_PS_QFE2	QFE2	NULL
Component	INSERT	C_PS_QFE2	NULL	NULL
FeatureComponents	INSERT	F_PS_StdColor,C_PS_QFE2	NULL	NULL
Registry	Name	QFE2	QFE2	NULL
Registry	Value	QFE2	QFE2-Simple1	NULL
Registry	Component_	QFE2	C_PS_QFE2	NULL
Registry	Key	QFE2	SOFTWARE\Microsoft\MsiTest\PatchSequencing	NULL
Registry	Root	QFE2	-1	NULL
Registry	INSERT	QFE2	NULL	NULL

RTMCA would query this table to identify the component that was originally added by this patch will be dropped due to this patch uninstall. Based on this information, it can make any decisions that it has to. It needs to be noted that any modifications made to this table will be ignored and not used by Windows Installer in any way. The purpose of this table is for a patch uninstall custom action to make its decisions off of the patch being uninstalled and the state of the machine.

1. DeferredQCA will be run in script and therefore will not be able to access the MsiTransformView<Patch GUID> table.

Implicit Patch Uninstalls

1. Install Product A:




1. RTM version of the product does not have any custom actions.


2. Apply Patch SP1:




1. Patch SP1 adds a new binary patch uninstall custom action UninstallCA.


3. Apply Patch Q1:




1. Q1 targets SP1 and carries an update to UninstallCA.


4. Apply Patch Q2:




1. Q2 targets SP1 and carries an update to UninstallCA.


5. Apply Patch Q3:




1. Q3 targets SP1 and carries an update to UninstallCA.


6. Notes:

The patch sequence numbers for the above three patches are:

Patch	Patch Family	Sequence Number
SP1	Fam1	1.1.0.0
SP1	Fam2	1.1.0.0
Q1	Fam1	1.1.1.0
Q2	Fam1	1.1.2.0
Q2	Fam2	1.1.1.0

1. Uninstall SP1:




1. MSIPATCHREMOVE property will be set to SP1 only. However, Q1, Q2 and Q3 will all be uninstalled because they transition from applicable to inapplicable. All patches that go out of view in this manner, get the opportunity to run their patch uninstall custom actions.


2. However, since all of them update the same custom action, the question is whose custom action will be run. The answer is: the patch whose sequence number is the highest will be used. However, when there are two patches with different patch families then the choice will be non-deterministic.

[Author: Hemchander Sannidhanam]
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

Hello everyone –

I am pleased to announce that Windows Installer 4.5 Beta 2 is now available from the Microsoft Connect site. If you have not signed up for the beta yet, please do - we are listed as “Windows Installer 4.5″ under the “Available Connections” section of the site. If you have already joined the beta, please head back to the Connect site and download the updated bits, tools and documentation.

This is our last planned beta release before we ship, so your feedback at this stage is especially important!

Thanks.

 - Tyler

PS: Due to some unfortunate timing, the Microsoft Connect team will be rolling out a new version of the Connect site on Saturday, March 22nd and the site will not be available from 10:00 AM and 2:00 PM (PDT). If you have issues accessing the beta program afterward, please leave a comment on this thread so we can follow-up on any issues.  

[Author: Tyler Robinson]
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

After having Outlook completely “forget” to update a couple of my feed subscriptions I decided it was time to go back to RSS Bandit. Once installed I found that RSS Bandit had added a few feeds that I had long discarded. Of course, Robert Scoble was one of the reentrants. On of the first blog entries I came across was titled “Obsolete skills“.

Francine Hardaway is here and we’re talking about obsolete skills. Things we used to know that no longer are very useful to us. Here’s some we came up with. How many can you come up with?

1. Dialing a rotary phone.
2. Putting a needle on a vinyl record.
3. Changing tracks on an eight-track tape.
4. Shorthand.
5. Using a slide rule.
…

That brought back a thought I had a while ago. It seem like the world of programming is moving beyond “native code” (C/C++). The thought was cemented when I was a part of interview loops where candidates that could not write C or C++ code were hired. Inside Microsoft “managed code” (VB but mostly C#) is taking over.

When I look outside I see a lot of discussion about full blown systems written in Python and/or Ruby plus JavaScript. That’s just scripting code, stuff you’d use to glue other stuff together. You’d never build a “real” program out of a scripting language.

Of course, that’s just how obsolescence works. It sneaks up on the current state of the art and ultimately overthrows those practitioners with a better, or often just easier, way of doing things.

So, how long until this ends up as number twelve on Scoble’s list?

12. Programming in C/C++.

And then…?

13. Programming in VB/C#/Java.

Eventually, I suppose we’ll end up programming by just dragging dropping big Duplo blocks on the screen. <smile/>

 

Original post by Rob Mensching

Hello everyone! First off, I wanted to let you know that I have re-joined the Windows Installer (MSI) team as a Lead PM, so you all will be hearing a lot more from me in the future <grin>

I have a few exciting announcements to make today:

1. I know you all have been wondering what has been up with Windows Installer 4.5, and I am pleased to announce that we plan to release Beta 2 within the next few weeks. If you would like to access the beta program, please read Robert’s prior posting on this topic. There will be an announcement posted to the blog when the Beta 2 is available. Your feedback on beta 2 is welcomed and also critical in this stage of our release, as this is our last scheduled beta before we RTM.


2. We have also scheduled an MSDN Technical Chat on Windows Installer 4.5 on April 3, 2008 at 10:00 AM (Pacific). If you have not participated in these chats before, they are a great forum for you to interact directly with members of the team! Click here to add the chat to your calendar so you don’t miss it!

Please stay tuned to the blog for more exciting announcements coming soon …

[Author: Tyler Robinson]
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