I used this article as a guide:  http://www.codeproject.com/KB/install/dotnetpatching.aspx

However, the Platform SDK link in the article is broken, so use this one instead:  http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en

This isn’t the most up-to-date Windows SDK, but the batch script in the CodeProject article relies on this specific versions folder structure (it has everything you need to create the MSP patch installer nicely in one folder, whereas the newest SDK does not).

I did run into a few of the same hiccups that others did (found down below in the comments of the CodeProject article).  Here are links to my posts with the solutions (you’ll have to click around each thread to see the problems posted before my posts):

• These two are in the same thread:
  • http://www.codeproject.com/KB/install/dotnetpatching.aspx?fid=209224&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2473656#xx2473656xx
  • http://www.codeproject.com/KB/install/dotnetpatching.aspx?fid=209224&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2474912#xx2474912xx
• http://www.codeproject.com/KB/install/dotnetpatching.aspx?fid=209224&select=2475101#xx2475101xx

Also, I had to modify his patch.cmd batch file slightly; a copy of it is pasted below.

This process isn’t as effective as it should be if you are trying to difference two Visual Studio created MSI installers.  The MSIMSP utility is very thorough in its comparison of file names, locations, sizes, versions, and every byte of data contained in the files.  It can create a binary difference between the two files in order to minimize as much as possible the patch installer’s size and speed.  It even compares the 8.3 short filename of every file.  Unfortunately, Visual Studio can be very inconsistent in its assignment of short filenames with the tilde-numbering system (i.e., "FILENA~3.TXT") if you add, rename, move, or delete even a couple of files from your project.  I often had to manually edit the short filenames in the second MSI using the Orca utility to make the names be consistent between the two versions of the Visual Studio created installers; otherwise, the MSIMSP utility would just blindly include the whole file for patching and inflate the overall size of the MSP patcher.

Good luck and enjoy not having to figure out what the deltas are between the versions of your products!

if "%1"=="" %0 Debug Release Done 

@SETLOCAL 
@set path=%path%;"C:\Program Files\Microsoft Platform SDK\Samples\SysMgmt\Msi\Patching"
@set PatchTmp=C:\VSTemp

:loop 
if "%1"=="Done" goto end 

if not exist %1\*.msi goto nopatch 
if not exist TargetImage\%1\*.msi goto nopatch 

:ok 
rmdir /s /q %PatchTmp% 
mkdir %PatchTmp% 
mkdir %PatchTmp%\TargetImage 
mkdir %PatchTmp%\UpgradedImage 
mkdir %PatchTmp%\Patch 

for %%a in (TargetImage\%1\*.msi) do copy %%a %PatchTmp%\setup.msi 
msiexec /qb /a %PatchTmp%\setup.msi TARGETDIR=%PatchTmp%\TargetImage /L*v %PatchTmp%\TargetImage\setup.log 
del %PatchTmp%\setup.msi 

for %%a in (%1\*.msi) do copy %%a %PatchTmp%\setup.msi 
msiexec /qb /a %PatchTmp%\setup.msi TARGETDIR=%PatchTmp%\UpgradedImage /L*v %PatchTmp%\UpgradedImage\setup.log 
del %PatchTmp%\setup.msi 

copy patch.pcp %PatchTmp% 
set PatchDir=%CD% 
chdir %PatchTmp% 
msimsp -s patch.pcp -p Patch\patch.msp -l Patch\patch.log -f %PatchTmp%\Tmp -d 

rmdir /s /q %PatchTmp%\TargetImage 
rmdir /s /q %PatchTmp%\UpgradedImage 
rmdir /s /q %PatchTmp%\Tmp 
chdir %PatchDir% 

mkdir Patch 
mkdir Patch\%1 
copy %PatchTmp%\Patch\*.* Patch\%1\*.* 
rmdir /s /q %PatchTmp% 

:nopatch 
shift 
goto loop 

:end 
pause

1. It appears that Microsoft moved the location of it’s prerequisite packages for the BootStrapper for VS 2008.  Microsoft used to keep them at C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages, but now in 2008 it looks they have moved them to a more isolated and common location.  The new location is C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages.  When I converted our setup projects to VS 2008 format, some of the prerequisites couldn’t be found because of this.  I just went to the old VS 2005 BootStrapper location and copied the folders of the packages I needed to the new VS 2008 location (for example, the MDAC package is under a folder called MDAC28, and it is not in VS 2008’s list of packages by default anymore).
2. We had a folder structure into which we were dropping the Primary Output of a web application in our setup projects.  For a web application project, the Primary Output is the DLL libraries in the bin directory of the web site.  In VS 2005, you would create a bin folder at the root level of the web site and put the Primary Output down a level in the bin folder.  Well, now in VS 2008, it appears that wherever you put the Project Output, the setup project will create a bin folder at that location and put the DLL libraries in that bin folder one level down from where you put the Project Output.  So I had to go back through our setup projects and move the location of those Primary Outputs one level up (or else it would create a bin folder inside of the bin folder).

One nice thing about the migration to VS 2008 is that it looks like Microsoft has a new version of the Visual C++ Runtime Libraries prerequisite (I don’t know if the libraries are actually any different, but at least the redistributable package and logic are improved).  We have a set of products that have this package as a prerequisite during install.  Every time you ran the installer it would reinstall the package.  It was almost as if it wasn’t doing any logic to detect if it already had the package installed.  The following link might be the explanation of why we were seeing this odd behavior (even though it references the MDAC package):  http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=339044&SiteID=1

Well, the new Visual C++ Runtime Libraries package works great and doesn’t keep reinstalling itself as a prerequisite with every install or update of one of our products that depend on it.

FOLLOWUP (06/19/08):  Actually, we ended it up having to revert back to the Visual C++ Runtime Libraries from Visual Studio 2005, as another prerequisite we were using (DTSearch) wasn’t compatible with the new C++ libraries with VS 2008.  We’ll check again next year.