|
|
I get the same error. Did you find solution?
|
|
|
|
|
It seems like my patch was created successfully. that what the log file says. However, when I use the "Repair" option of the msp, I get an error code 2356. Could you help with what this is ?
|
|
|
|
|
Hi, thanks for this great article
I have a rather irritating problem: all seems to go well, I have a VS-solution with an .exe, quite a few dll's and in the setup also some html, pics and word documents. The only thing I want to make the patch for is a very minor (but important) change in the .exe and two word-docs have changed.
If I run patch.cmd (with one alteration, the line: "chdir %PatchTmp%" didn't work if I didn't put a line before it with the simple command: "C:").
Then I got a patch that seems to work, the log file says that the right three files have been altered, when I apply it all seems to go well, the patch says that it has been applied succesfully (the version of the program that you can see in the control panel -> add/remove programs ->Support info has changed (this was step 15 of the article: "Edit your deployment project and change the version property").
But the error in the program still occurs and if I check the program directory, I can see that the two word-docs have changed, but the .exe not!
If I don't let the patch.cmd delete the temp-dirs I can see that in the UpgradedImage is indeed the rigt version of the .exe (and it also runs without the error).
The logfile does give a warning: "WARNING (14): File versions are equal. Upgraded: 'C:\~VSTMP\UpgradedImage\.\IFM3.exe' ver=3.8.3.17; Target: 'C:\~VSTMP\TargetImage\.\IFM3.exe' ver=3.8.3.17."
But I don't have to change the Assembly Version for a minor update?
The next line in the logfile is:
"Files differ: 'C:\~VSTMP\UpgradedImage\.\IFM3.exe',
'C:\~VSTMP\TargetImage\.\IFM3.exe'.
Patch file created: FTK=_5661D4D9EBD12A2E0A67A14FE3652DA3; temp location=fam1\00004.HDR."
What am I doing wrong?
Any ideas would be very much appreciated,
Martin
|
|
|
|
|
The patch is not including the new IFM3.exe file because the version number is the same, i.e. "3.8.3.17". The msismp program determines whether a file should be included in the patch solely by its version number. It doesn't matter at all if the files are actually otherwise different. In .NET, the file version number attribute that msimsp reads is AssemblyFileVersion() which is different from the AssemblyVersion() attribute which is used by .NET strong types. So double check the AssemblyFileVersion and assure that it is being updated to a higher number, otherwise msimsp will not include it in the patch.
|
|
|
|
|
Hello,
I seem to be having trouble with the steps outlined here. I successfully built a patch, but when I view the patch in ORCA, it only contains 2 tables: MsiPatchMetadata and MsiPatchSequence. These two tables just contain a few properties of the patch, but no other data. One of the DLLs of my project changed, so I would expect to see this file in there somewhere. The log file reports "Patch created successfully" but when I try to apply it to an existing installation, the installer displays the "Repair/Uninstall" dialog. The log file also indicates that it recognized that my DLL has changed.
So, this process doesn't seem to have worked, but it also doesn't seem to provide any information about what has gone wrong. Any ideas/suggestions?
Thanks in advance,
Jon
|
|
|
|
|
My guess is that you didn't update the assembly file version of the changed DLL. I read somewhere that when msimsp compares the two msi files to determine that a DLL has changed in order to create the patch it only looks at the file version number attributes, not the date/time or size. Make sure the AssemblyFileVersion attribute is updated for each build, or make sure it is blank (which will cause VS to inherit the AsssemblyVersion Attribute) and update the AssemblyVersion attribute with each build.
|
|
|
|
|
...but I DID change the assembly file version. Like I said in my original post, the log file indicates that it recognized that the assembly had changed, but the resulting MSP file was essentially empty.
|
|
|
|
|
The script and method I presented here just automates the process with a simple pcp that you would otherwise have to manually create and maintain had you only installed the SDK. It's hard to identify the problem in the forums. If you can email me the pcp file you used and log file that was gererated, perhaps I can identify what has happened.
|
|
|
|
|
I seem to have the same problem. In the log-file he says that some dlls and files differ and he includes the entire file. But when i run the patch nothing changed. I am working with Visual Studio 2010 and Framework 3.5.1. Thanks for helping.
|
|
|
|
|
I seemed to be running into the same problem but changing the version of the affected DLLs solved the problems.
Although the log files said that the affected files had changed the patch did nothing to them.
|
|
|
|
|
I using visual studio setup project to generate the .msi file.
First i generate the *.msi file (abc.msi)
Secondly i edit the code by changing the text from "hello world" to "hell world" and generate the *.msi file
Third, i copy abc.msi to "targetImage" folder and run patch.cmd. No problem and the patch created is small about a few kb
But if i change the step something weird happen:
First i make a copy of the whole project.
Secondly, i generate the *.msi file (abc.msi)
Thirdly i edit the code of copy folder by changing text from "hello world" to "hell world" and generate the *.msi file
Third, i copy abc.msi to "targetImage" folder and run patch.cmd.
The patch file created is about a few hundred kb. The log state that patch api could not create a small patch. This is a wrong behavior as it including the new "hello world" instead of creating a patch for it.
What step have i missed out? 
|
|
|
|
|
Firstly, thanks to the author for the helpful article.
I'm wondering if anybody could help me? After successfully performing all of the steps in this article and installing the patch created, I've noticed a problem when removing the patch installation (via Add/Remove Programs in Control Panel).
We required a patch to be created to our software because we had to make a change to a xml file (StationCodes.xml) and to the main executable of the software.
When the patch was installed onto the target environment, the 2 files (xml file & exe) were correctly updated.
The problem: After testing the removal of the patch, I noticed that the exe file and all dlls (except one) was deleted from the "Program Files" location in which it lived. I was of course expecting to see the version of the exe to go back to the original (TargetImage) version of the executable. The xml file did however revert back to the original version (from the TargetImage).
Here is the log from the step which the msp patch file was created:
***** Log starting: 2010-07-21 13:54:47 *****
Input-PCP path = 'C:\VSTMP\patch.pcp'
Patch-MSP path = 'C:\VSTMP\Patch\patch.msp'
Temp Folder = 'C:\VSTMP\Tmp\'
Patch GUID = '{8C1975CD-9EBE-42AF-89D6-BFE9DA186AC9}'
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.
WARNING (14): File versions are equal. Upgraded: 'C:\VSTMP\UpgradedImage\.\MSO9.DLL' ver=9.0.0.7616; Target: 'C:\VSTMP\TargetImage\.\MSO9.DLL' ver=9.0.0.7616.
Files differ: 'C:\VSTMP\UpgradedImage\.\MSO9.DLL',
'C:\VSTMP\TargetImage\.\MSO9.DLL'.
Patch file created: FTK=_05FAE2753E76D77D26CB735E425D9FCA; temp location=fam1\00002.HDR.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\Interop.Word.dll';
FTK=_0FFAE0B3546E59CD9C3C7B09893D3C72; temp location=fam1\00003.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\Office.dll';
FTK=_21110CDEC9273E9EAD69AB43B0232A2C; temp location=fam1\00004.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\xmldiffpatch.dll';
FTK=_2D6C6D4EBC3433F470ACF71EA8EF897F; temp location=fam1\00005.FLE.
Files differ: 'C:\VSTMP\UpgradedImage\.\schema\StationCodes.xml',
'C:\VSTMP\TargetImage\.\schema\StationCodes.xml'.
Patch file created: FTK=_2EB1DE84E6244A88B09C1A26A75682FE; temp location=fam1\00006.HDR.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\Interop.SHDocVw.dll';
FTK=_48CBA5976EE045D2211B5CEF55B3B80E; temp location=fam1\00007.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\Microsoft.Vbe.Interop.dll';
FTK=_6ADC89A061D83C8C8A314ABFCFE58CC4; temp location=fam1\00008.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\MSWORD9.OLB';
FTK=_78AF92131D26C5937ECFC09E91D3BDBE; temp location=fam1\00009.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\Interop.Office.dll';
FTK=_8388826BCC62E9981C6FA0B07EF0F029; temp location=fam1\00010.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\AxInterop.SHDocVw.dll';
FTK=_FB2EE7117003BC52BAE5E00D3446906F; temp location=fam1\00011.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\Common.dll';
FTK=_FF6E4711993394F18050542B93A0AAFB; temp location=fam1\00012.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\StationBuilder.exe.config';
FTK=_FA79743CD513D09FCA5F23EA6A49C938; temp location=fam1\00013.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\StationBuilder.exe';
FTK=_063AA0D25C74F19391961D8530418B06; temp location=fam1\00014.FLE.
Patch API could not create a small patch; using whole upgraded file.
Including entire file: 'C:\VSTMP\UpgradedImage\.\Common.dll';
FTK=_E44D6882B0D9305B046D2038CB4665A4; temp location=fam1\00015.FLE.
***** Log finishing: 2010-07-21 13:56:09 *****
I've had a good luck via Google, but have not found anything that relates to the problem that I have.
Any ideas please?
P.S. In the log above it mentions differences in the dlls that were removed, however they're identical between TargetImage and UpgradeImage. The log says for each of the files that were wrongly deleted "Patch API could not create a small patch; using whole upgraded file. Including entire file..." I don't know if this means anything?? I've also tried changing the Properties->IncludeWholeFilesOnly value in my PCP file to 1 and 0, but the same result happens for both options.
|
|
|
|
|
Hi,
When i create first patch it is updating.its amazing!.after that i created second patch i.e v1 to v2
patch was created with out any problem but new version dll's are not updating.
please reply.
it's usefull for everyone who are all facing this problem.
Thanks
|
|
|
|
|
Hi All,
I am facing problem when applying patch on patch.I have created Patch (Pacth1) between version 1.0.0 & version 1.0.1.
I have installed the application with version 1.0.0,Now patch1 applied on version 1.0.0 successfully.
Now i have created the patch (Patch2) between version 1.0.1 & version 1.0.2. When i apply the Patch2 i cannot see any errors but no changes occurred.
Thanks in Advance
Regards,
Mahesh
|
|
|
|
|
How this got resolved..any work arounds....
|
|
|
|
|
Hi, I'm facing with same trouble, first patch from 1.0.1 to 1.0.2 was created and patched successfuly, but next 1.0.3 could be patched only , if I'm aplying patch to 1.0.2 clean install, if I'm trying to patch from 1.0.1 to 1.0.2 and then to 1.0.3 - I got no error , but there is no changes. Did you found how to solve that?
P.S. I've tried to use patch from cmd :
RunProcess("msiexec.exe", string.Format("/update {0} /qn " , pathToPatch));
or using msi api :
UInt32 ret = MsiApplyPatch(pathToPatch, "", INSTALLTYPE.INSTALLTYPE_DEFAULT, "REINSTALL=ALL REINSTALLMODE=omus");
it returns 0 all time, but take no any effect, if I'm trying to update it from first version.
|
|
|
|
|
Looks like I found the solution (thanks to Globulus, which asked below how to change programmatically PatchGUID value). After I've changed that value - patches start to work fine.
P.S. Also that cmd file will work only on drive C (@set PatchTmp=C:\~VSTMP - I've changed that line to @set PatchTmp=%CD%\~VSTMP48)
|
|
|
|
|
Hi All,
I am working on installation patches for VS.NET deployment projects.
I have made some changes one file but the DLL version is same. The size of DLL has increased. I can able to generate patch sucessfully.When i am apply this patch the DLL size remains to old DLL its not updating with modified size.
Here is what i can see in the Patch.log file.
========================================================
WARNING (14): File versions are equal. Upgraded: 'F:\Work\Sample\UpgradedImage\Release\.\bin\Sample.DLL' ver=1.0.0.0; Target: 'F:\Work\Sample\TargetImage\Release\.\bin\Sample.DLL' ver=1.0.0.0.
Files differ: 'F:\Work\Sample\UpgradedImage\Release\.\bin\Sample.DLL',
'F:\Work\Sample\TargetImage\Release\.\bin\Sample.DLL'.
Patch file created: FTK=_DF3A419E93251C07F0B4CE3C607A0371; temp location=LastName\00009.HDR.
==================================================================
Thanks is Advance.
Regards,
Mahesh
|
|
|
|
|
I have a Visual Studio 2008 ASP.NET application project for which I have used a Deployment Project to create a web installer.
I wish to create a network installation of this application, but the files end up in the default directory specified in the installer rather than the TARGETDIR specified on the command line.
In other words, instead of extracting the files to c:\Output, they end up in c:\inetpub\wwwroot\TestWebSetup.
Looking at the msiexec log, I see that the TARGETDIR property is set to the value specified on the command line, but later it is modified to the value specified in the installer:
MSI (c) (04:0C) [09:46:34:546]: Command Line: TARGETDIR=c:\output ACTION=ADMIN CURRENTDIRECTORY=c:\Install CLIENTUILEVEL=0 CLIENTPROCESSID=2820
...
MSI (c) (04:0C) [09:46:34:562]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'c:\output'.
...
MSI (c) (04!4C) [09:46:35:202]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'c:\output'. Its new value: 'C:\inetpub\wwwroot\TestWebSetup\'.
Is there anything I can specify on the command line for msiexec or do I need to modify the installer?
Note that at the moment I am limited to using Visual Studio Deployment projects and the installer should still be able to run normally, i.e. one installer for doing network as well as normal installations.
|
|
|
|
|
I have never worked with web installer projects. What you will have to do is open the original msi file to understand how and when properties are modified to determine what custom modifications you will need. Perhaps someone else who has more experience with web projects can provide further insight.
|
|
|
|
|
Suppose I had created a patch from 1.0 to 1.1 and now want to create a patch from 1.1 to 1.2 (or 1.0 to 1.2). I would like to reuse the .pcp file I created with Orca, but any modifications to that file should be done through scripting (e.g. VBScript) rather than someone having to open it in Orca again. From what I understand, I have to - at the very least - change the PatchGUID value.
How do I make such a modification using scripting?
|
|
|
|
|
There is another article here called something like vista certification by exmple that has a cscript called .js file that you may be able to reference as one example of how an MSI file may be edited through scripting. But basically you will need to generate a new Guid and then execute a SQL command against the MSI file to update the Guid.
|
|
|
|
|
Nice article Thank you very much.
when I am running patch, it shows a window with Repair setup/Remove setup message. Is there any way to ignore this message?
and my new version msi size 5.4 MB if i am creating patch new msp size 3.5 MB. is it possible to
reduce the file size
|
|
|
|
|
Not that I am aware of. I never needed to make a patcher that would swork silently. And in principle a silent patcher is a security risk to the customer who should always be infomed if programs are installing or changing, even if the customer is to naive to understand any of it. The only thing I can suggest is to review the documentation for msiexec to see if there is a command line switch that will do this.
As for patch size, I usually dont worry about optimizing installer sizes unless they exceed 30 megs or so. My major projects run over 100 megs and even then I only occasionally examine the MSI contents to make sure assemblies are not getting duplicataed. The problem I have seen is that sometimes VS setup projects include the same assemblies twice. I dont know the exact cause, but I suspect it happens when a project with included dependencies also includes a merge module with the same contents; thus adding the 'copy local' dependencies as well as the merge module assemblies. In my case the double included assemlies increase the total installer MSI file size by less than 10%, so I don't worry about it.
|
|
|
|