|
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.
|
|
|
|
|
I also needed to make an additional change to the batch file:
@set path=%path%;"C:\Program Files\Microsoft Platform SDK\Samples\SysMgmt\Msi\Patching"
In order to add the path to the msimsp.exe to the path variable I needed to enclose the full path in quotes (to escape the dir name spaces) and also needed to move it up to the same line as the set command (immediately following the semicolon.)
|
|
|
|
|
This is already in my original file. I suppose it could have been accidentally changed above when codeproject moved it out of the unedited groups into the main groups. I will try to update it.
|
|
|
|
|
The article is updated to include the quote marks around the path, but CodeProject staff has told me that they automatically wrap text within the code sections so that they do not scroll on an 800x600 screen.
|
|
|
|
|
I have followed the instructions to the letter and I am not able to get the patch to create. The batch file scrolls as though its echoing the lines and not executing them. Any ideas what I may be doing wrong?
Thanks,
Derk
|
|
|
|
|
I would guess that the Platform SDK. Either you installed the SDK to a different path and need to correct the path statement, or you copied the contents of the code section from CodeProject without unwrapping the path statement. CodeProject automatically wraps this line to two lines and it should only be one line.
-- modified at 13:45 Monday 19th December, 2005
CodeProject automatically wraps all code lines it deems is too long. Several lines in the batch file displayed on this article have been wrapped and you need to unwrap them.
|
|
|
|
|
I haven't tried it but I'm sure I will love it. I should have thought of doing it with a build-time script : I was doing it with my bare hands everytime !
Michael CARBENAY
Creo Ignem
|
|
|
|
|
I strongly agree!!!
From the face of it ... it looks great.
Another article (Add an uninstall start menu item to your .NET deployment project) by the same author (mjmeans) was also very good.
Thanks man.
|
|
|
|
|
I'm not that sure about the second article, not that it's bad : it's quite cool. But a uninstall start menu is not recommended if you want a design for windows xp logo...
Michael CARBENAY
Creo Ignem
|
|
|
|