|
mjmeans,
First of all thank you very much for providing such an excellent artical to create a patch. I did every thing perfectly as per this artical and in One place I got stuck. While running the patch.cmd file at below command-line I am getting error.
msimsp -s patch.pcp -p Patch\patch.msp -l Patch\patch.log -f C:\~VSTMP\Tmp -d
The error is "Failed to create patch. Error code: 0xC00E5114".
I followed all the changes which you mentioned in this mail and still I am receiving the same error.
Please help me out to resolve this error and let me know, if I need to do anything extra for this.
Thank you,
Narayana
|
|
|
|
|
I had the same upgradedImage problem...
I found that it was a mistake in patch.cmd i.e chdir was not working on my PC
so jst try cd command or use C: and cd %patchtmp% instead of chdir %patchtmp%
Dont make any changes as u did it in patch.pcp files earlier(changing the Msi path etc).
See it works.
|
|
|
|
|
Hello,
I have the same problem and I succeed to solve it.
The problem come from when you use differents hard drive letters between temp folder and installer folder.
For that, you need to modify patch.cmd.
Change the "chdir" command to force change hard drive letter and not just folder.
You need to add "/D" to the command and it is working.
chdir /D %PatchDir%
|
|
|
|
|
Please Hellp me to create the patch file for my VS.net 2003
I am using XP Prof version
I copied the CMD script and done nesessary changes like unwrap the code etc.
i followed the steps as it is.
the result is
=================
***** Log starting: 2006-04-19 12:07:20 *****
Input-PCP path = 'patch.pcp'
Patch-MSP path = 'Patch\patch.msp'
Temp Folder = 'C:\~VSTMP\Tmp\'
Patch GUID = '{64EE4D8C-577E-4432-B1E4-941C309480F1}'
ListOfPatchGUIDsToReplace = '<none>'
ListOfTargetProductCodes = '*'
PatchSourceList = 'PatchSourceList'
AllowProductCodeMismatches = '1'
AllowProductVersionMajorMismatches = '1'
OptimizePatchSizeForLargeFiles = '<blank>'
ApiPatchingSymbolFlags = '0x00000000'
MsiFileToUseToCreatePatchTables = '<blank>'
SqlCmdToCreatePatchTable = '<blank>'
SqlCmdToCreatePatchPackageTable = '<blank>'
SqlCmdToCreateMsiPatchHeadersTable = '<blank>'
DontRemoveTempFolderWhenFinished = '1'
IncludeWholeFilesOnly = '0'
MinimumRequiredMsiVersion = '200'
SEQUENCE_DATA_GENERATION_DISABLED = '<blank>'
AllowRemoval = '<blank>'
Using internal SQL cmd to create 'Patch' table.
Using internal SQL cmd to create 'PatchPackage' table.
Using internal SQL cmd to create 'MsiPatchHeaders' table.
ERROR: UpgradedImages.MsiPath 'C:\~VSTMP\UpgradedImage\setup.msi' does not exist.
***** Log finishing: 2006-04-19 12:07:20 *****
======================================================================
The Script is like this (same code) :
---------------------------------------
if "%1"=="" %0 Debug Release Done
@SETLOCAL
@set path=%path%;"C:\Program Files\Microsoft Platform SDK\Samples\SysMgmt\Msi\Patching"
@set PatchTmp=C:\~VSTMP
: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
-------------------------------------
Bhaskar Prasad Thamma
Sr.Software Engineer,
Vertical Marketing India
B-3,B.R.Princeton Aprts,
VIP Road
Visakhapatnam -530 003
ph 5564793 ,2597175
|
|
|
|
|
First double check you script to make sure the "for" lines and the "msiexec" line are on separate lines. It looks like you have appended the "msiexec" line to the end of the second "for" line and it should not be so.
Second, double check that you have created both ./TargetImage/Debug and ./TargetImage/Release; and that the VS Setup Projects directory also has a ./Debug and ./Release folder; and that there are setup.msi files in each of these folders. If you do not build Debug or Release versions you can leave these folders out if you remove the Debug or Release keyword from line 1 of the script.
If you still have problems, then let me know; but it is likely one of the above cuases.
|
|
|
|
|
Yes,I you are right,i appended teh msiexec.I brought down the msiexec and saved it run the patch.cmd.but same result.
Is setup.msi is the manditory name or can i change it to my setup name like "Websetup.msi"?
i ran with and without changing the setup.msi to websetup.msi,but result is same.please help where i am doing wrong?
i have created "TargetImage\Debug" and "TargetImage\Release" folders.
========
***** Log starting: 2006-04-20 19:21:59 *****
Input-PCP path = 'patch.pcp'
Patch-MSP path = 'Patch\patch.msp'
Temp Folder = 'C:\~VSTMP\Tmp\'
Patch GUID = '{64EE4D8C-577E-4432-B1E4-941C309480F1}'
ListOfPatchGUIDsToReplace = '<none>'
ListOfTargetProductCodes = '*'
PatchSourceList = 'PatchSourceList'
AllowProductCodeMismatches = '1'
AllowProductVersionMajorMismatches = '1'
OptimizePatchSizeForLargeFiles = '<blank>'
ApiPatchingSymbolFlags = '0x00000000'
MsiFileToUseToCreatePatchTables = '<blank>'
SqlCmdToCreatePatchTable = '<blank>'
SqlCmdToCreatePatchPackageTable = '<blank>'
SqlCmdToCreateMsiPatchHeadersTable = '<blank>'
DontRemoveTempFolderWhenFinished = '1'
IncludeWholeFilesOnly = '0'
MinimumRequiredMsiVersion = '200'
SEQUENCE_DATA_GENERATION_DISABLED = '<blank>'
AllowRemoval = '<blank>'
Using internal SQL cmd to create 'Patch' table.
Using internal SQL cmd to create 'PatchPackage' table.
Using internal SQL cmd to create 'MsiPatchHeaders' table.
ERROR: UpgradedImages.MsiPath 'C:\~VSTMP\UpgradedImage\Websetup.msi' does not exist.
***** Log finishing: 2006-04-20 19:21:59 *****
===========
Bhaskar Prasad Thamma
Sr.Software Engineer,
Vertical Marketing India
B-3,B.R.Princeton Aprts,
VIP Road
Visakhapatnam -530 003
ph 5564793 ,2597175
|
|
|
|
|
It looks like you changed setup.msi to websetup.msi on step 10 or 11. Double check them and change them back.
The batch command will copy your existing *.msi file(s) into the temporary locations needed by the patch command and at the same time rename them to setup.msi so that they match the entries in patch.pcp. The patch.pcp file must point to the renamed files used to create the patch.
|
|
|
|
|
even I had the same problem
But I could overcome it.
Chdir in the patch.cmd was not working so I had that error.
I tried it with c: cd %patchtemp% and d: cd %patchdir%(refer to two chdir commands in the patch.cmd )
And Bingo! it worked.
|
|
|
|
|
Hi,
Your article is really informative in terms of creating the patch. It would be really helpful, if you could provide us with this patch creation process aiming to make the patch uninstallable and the product will be in the previous state.. as with patch not installed.
Regards,
Parag.
|
|
|
|
|
Can you describe the "project deployment folder" that I need to place the patch.cmd, patch.pcp, and my targetimage folder? I am having trouble knowing for sure where that is..
thanks!
Robin
|
|
|
|
|
When you create a deployment project in your VS.NET solution, VS.NET creates a folder for the deployment project. When you build the deployment project as debug or release, VS.NET will create a debug or release folder. So in its simplest form, you have a solution (i.e. Solution1), inside it you have two projectgs (i.e. Project1, and DeploymentProject1). In this example, the folders I am would be in Solution1\DeploymentProject1, Solution1\DeploymentProject1\Release and Solution1\DeploymentProject1\Debug. When you build your deployment project the MSI files will be created in the Release and Degbue folders. The patch.cmd goes in the Solution1\DeploymentProject1
Also, you must have folders called Solution1\DeploymentProject1\TargetImage, Solution1\DeploymentProject1\TargetImage\Release and Solution1\DeploymentProject1\TargetImage\Debug folders which have the old version of your MSIs in them.
Hopefully this clarifies your confusion.
|
|
|
|
|
Hi,
I have tried this patch and it works great!
However it fails to update assembles installed in GAC. If I put assembly ver 1.0.0.0 in GAC and try to patch it with the same assembly ver 1.0.1.0 the patch don't work.
What have to be done in order to update assemblies installed in GAC?
Thanks
|
|
|
|
|
Sorry. I have never worked with installing assemblies to GAC. Hopefully, another reader will have some ideas about this.
|
|
|
|
|
I can't find how to get past this error (TargetImages.Target = 'target': PackageCode {95342D1A-EBCC-44FF-8120-9D8F862F29E1} is not unique.). Could anyone please tell me what I need to do and where/how I need to do it?
***** Log starting: 2006-01-26 09:42:36 *****
Input-PCP path = 'patch.pcp'
Patch-MSP path = 'Patch\patch.msp'
Temp Folder = 'C:\~VSTMP\Tmp\'
Patch GUID = '{F61DD2BE-9D1E-49BC-B4C1-E5C5F0FD0209}'
ListOfPatchGUIDsToReplace = '<none>'
ListOfTargetProductCodes = '*'
PatchSourceList = 'PatchSourceList'
AllowProductCodeMismatches = '1'
AllowProductVersionMajorMismatches = '1'
OptimizePatchSizeForLargeFiles = '<blank>'
ApiPatchingSymbolFlags = '0x00000000'
MsiFileToUseToCreatePatchTables = '<blank>'
SqlCmdToCreatePatchTable = '<blank>'
SqlCmdToCreatePatchPackageTable = '<blank>'
SqlCmdToCreateMsiPatchHeadersTable = '<blank>'
DontRemoveTempFolderWhenFinished = '1'
IncludeWholeFilesOnly = '0'
MinimumRequiredMsiVersion = '200'
SEQUENCE_DATA_GENERATION_DISABLED = '<blank>'
AllowRemoval = '<blank>'
Using internal SQL cmd to create 'Patch' table.
Using internal SQL cmd to create 'PatchPackage' table.
Using internal SQL cmd to create 'MsiPatchHeaders' table.
ERROR: TargetImages.Target = 'target': PackageCode {95342D1A-EBCC-44FF-8120-9D8F862F29E1} is not unique.
***** Log finishing: 2006-01-26 09:42:36 *****
I have tried changing the ProductCode GUID in the setup properties. Adding a number to the build in the setup properties for the patch. Even changing the Upgrade GUID in the setup properties.
I can't find the GUID {95342D1A-EBCC-44FF-8120-9D8F862F29E1} in the setup.msi on the original, new build of the setup.msi, in the registry, or in the Admin Install setup.msi???
TargetImage:
ProductCode = {C473FCA3-4F32-4182-9750-BDBD18CB7A16}
UpgradeCode = {47AD66D4-B29A-4C95-95D9-BD68697FFE76}
Patch setup.msi :
ProductCode = {95342D1A-EBCC-44FF-8120-9D8F862F29E1}
UpgradeCode = {47AD66D4-B29A-4C95-95D9-BD68697FFE76
|
|
|
|
|
I found what I was doing and it is just me not following the directions. The GUID I couldn't find is located by viewing the .exe file after the admin install (msiexec /qb /a) in orca. Select view -> summary information and the PackageCode is the ProductID listed in there. The reason I got the "PackageCode {95342D1A-EBCC-44FF-8120-9D8F862F29E1} is not unique." error is because I didn't have the new .msi in the UpgradeImage folder. It was the same old .msi.
The second issue was was hitting was the error (WARNING (14): File versions are equal. Upgraded: 'C:\~VSTMP\UpgradedImage\.\CodeProject.exe' ver=1.0.0.0; Target: 'C:\~VSTMP\TargetImage\.\CodeProject.exe' ver=1.0.0.0.) This because the <assembly: assemblyversion("7.32.2")=""> was not changing. I was using a "*" to try to get the version to change instead of hard coding the version (still working on that). I committed the line '<assembly: assemblyfileversion("7.32.0.*")=""> so the same number is used from the AssemblyVersion. This created the msp and works great.
I'm using VB.NET 8.0
Thank you for posting this cool information because it will come in very handy for me and my co-workers.
-- modified at 15:10 Thursday 26th January, 2006
|
|
|
|
|
Hello,
My patch is done for a Windows Forms Application and a Windows Service Application that are under the same namespace. The WFA is the configurator for the WSA.
I used to get rid of the error in my previous article, but however i post there so that other users can also get rid of that.
The explanation of previous error message is that my new version of Application Setup Project has a version which is smaller than the old version of Application Setup project.
The patch.MSP contains 2 exe files that have been changed:
anApp.exe
aService.exe
I launch the msp on the target machine, it comes with Repair option in the Dialog, and when i click Repair (wherever in the docs it is said to apply the patch) it installs something, but when he is about to finish, he gives the "Error 1001 . Specified service already exists" in the msi log.
My service has a installer which is added as Custom Action to MSI in all 4 phases, and these are implemented well as long as with the MSI it is working(Installing the service, commiting , rollback and uninstalling).
I don't know why the MSP doesn't do itself the reinstallation of the service as long as he can see that my app is a Windows Service, neither i found something on the internet regarding my problem. I am browsing google since 4 days now in order to find a solution for that, but still found none.
Thank you for the answers,
|
|
|
|
|
I dont believe that MSI or MSP allows version numbers of upgrade installs or patch installs to be smaller than the original version number. Also, I have never tried this with a service. Since you have a custom action in your msi that handles the service installation phases, I recommend making a small change to the custom action so that the patch creator will include it in the MSP. The patch creator examines all files in each install MSI file, and if they are different, includes them in the patch. It is possible that the patch is trying to call the custom action DLL from the original MSI file and is having problems. Lastly, if that doesn't work, you can try modifying your custom action so that upon install, it first removes any previous versions of the service.
|
|
|
|
|
Hallo corsairX,
i read your message about your windows service patching problem with the MSP. I'm also trying to patch a windows service which was installed with an custome action and I get the same error message "Specified service already exists".
Did you solve the problem? If so, please can you explain how?
Thanks for your answer,
yours sincerely
Pieringer Johannes
|
|
|
|
|
Hi,
Did you found a solution on this? If yes, kindly share it with us. Im stuck also on this.
|
|
|
|
|
I think this happens alot with windows installer. Now that I think of it, I recall seeing lots of isntallers that launch a command prompt to do their windows service installation. The error you are having may be the reason. I would try adding a custom action that would launch a command prompt and batch file that calls the regsvr command to create the service. I'm sorry I dont have any anuthoritative answer because I have never developed a service app.
|
|
|
|
|
Slightly off topic question but I have a problem with my clients being unable to patch the program because their accounts have restricted privilege.
How could the patch be done such that even the least priviliged user accounts in Windows XP can run it? I've been searching all over the net, but I couldnt' find any solution to this problem.
Ivan
|
|
|
|
|
There is another pair of articles on CodeProject dealing with user privaleges and the mismatching of installing per user or per machine which discusses these issues and possible solutions in detail. Try searching CodeProject.
|
|
|
|
|
Hello, i used this tutorial for creating a msp patch file.
I followed up all the steps, and i successfully built the msp file on my developper machine. When i want to install it on my target machine, i have the following error:
The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch
Has anybody encountered it please?
|
|
|
|
|
My guess is that step 15 was not followed. Somewhere along the line, you must have selected YES when VS asked to automatically update the productcode. The best this, if you can, is restore the old values from a backup of the VS .proj file of your installer project. Alternately, although I have not tried this myself, you should be able to use ORCA to look inside the msi of your old version installer to get the numbers, then edit the VS .proj file and copy in all the various product, package, upgrade, etc codes from the old MSI file. Then follow step 15 again, so VS will do the changes it needs to do, but not update the two codes it asks you about.
Also, I have read that, for VS to do its calculations correctly, you should have the old version of your MSI actually installed on your VS machine. When VS does its msi project build it reportedly looks at your own machines registry for some information from the original msi which it apprently does no save in its project file. I have also not confirmed this. I have built patches that worked apparently correctly without having to have the old version installed.
|
|
|
|
|
Thanks for this article, I've successfully built a patch.
Three additional things that needed doing
1. If you copy/paste the batch file out of IE remember to remove the spaces on the end of the lines.
2. If you are working on multiple disks then chdir needs the /D option.
3. I needed to add a row to the properties table "MinimumRequiredMsiVersion" = "200" to get it to work.
I also got a little confused with the directory naming (target is old not new... - but maybe that's just the way my brain thinks!)
Thanks,
Dr Michael Dye.
|
|
|
|