For public consumption, we still require the files during bind because we only diff the files (including Binary and Icon objects) then after filtering. For large products this saves a huge amount of time. The file info in the transforms may not always be correct, especially when wixmsts are created from msis (since support was added to diff admin layout msis).
On Mon, May 4, 2009 at 7:17 PM, Blair Murri <bmu...@microsoft.com> wrote: > Found a workaround (and I came up with some sort of explanation for it). > > Rule: If you use WIXPDB files when you call TORCH, you should always pass > "-sf" to PYRO. > > Reason: > In order to generate the .wixpdb files you will pass to torch you must run > the binder in light.exe. The binder at that point populates all of the > file-related information into the various file-related tables (File, > MsiAssemblyName, etc.), unless you suppressed that using the -sa, -sf, or > -sh arguments. That data is thus present in the .wixpdb files you pass to > torch (to generate your .wixmst file) and doesn't need to be recalculated by > the binder when pyro.exe calls it. > > If you don't pass -sf to pyro.exe, it will recalculate that data, and in > the case of the MsiAssemblyName table, will attempt to insert the "version" > row (which will fail, producing the PYRO0130 error, since that row is > already present). > > The transforms in the resulting patch still contain the correct file > information (since they were already present in the "upgrade" MSI/wixpdb > file), and the patch works. > > From: Blair Murri > Sent: Monday, May 04, 2009 4:46 PM > To: wix-users@lists.sourceforge.net > Subject: Pyro and .Net assemblies > > I'm getting an error PYRO0130 in the table MsiAssemblyName which makes no > sense to me, especially since the wixmst file entry for that doesn't seem to > match the error message (at least to my mind). Why would modifying a field > on a row (when the field is not part of the primary key) generate this > error, especially since there are no rows being added? > > Here is the error message: error PYRO0130 : The primary key > 'PlatformApi_Interop_Comp/version' is duplicated in table 'MsiAssemblyName'. > Please remove one of the entries or rename a part of the primary key to > avoid the collision. > > And here is the portion from the wixmst for the entire table: > <table name="MsiAssemblyName" xmlns=" > http://schemas.microsoft.com/wix/2006/objects";> > - <row sectionId="/wix.section.2" > sourceLineNumber="e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276"> > <field>PlatformApi_Interop_Comp</field> > <field>culture</field> > <field>neutral</field> > </row> > - <row sectionId="/wix.section.2" > sourceLineNumber="e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276"> > <field>PlatformApi_Interop_Comp</field> > <field>name</field> > <field>LivePlatform.Interop</field> > </row> > - <row sectionId="/wix.section.2" > sourceLineNumber="e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276"> > <field>PlatformApi_Interop_Comp</field> > <field>processorArchitecture</field> > <field>MSIL</field> > </row> > - <row sectionId="/wix.section.2" > sourceLineNumber="e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276"> > <field>PlatformApi_Interop_Comp</field> > <field>publicKeyToken</field> > <field>8416CC26C44011B1</field> > </row> > - <row op="modify" sectionId="/wix.section.2" > sourceLineNumber="e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276"> > <field>PlatformApi_Interop_Comp</field> > <field>version</field> > <field modified="yes">15.0.2300.501</field> > </row> > </table> > > As you can see, the only operation on that table is to modify just one row, > the one that "now has a duplicate". However, neither the target wixpdb (or > msi) nor the upgrade wixpdb (or msi) contain any other rows (each contains > just those five rows). Any ideas? > > > A search of the wix-users mail-list showed just one other possible hit for > this issue, an unresolved (on the list) mail from INRO(Robert Inzinger) < > robert.inzin...@skidata.com> from Wed, 29 Oct 2008 14:52:48 +0100 titled > "[WiX-users] Pyro and .Net Assemblies" (which looks to me to probably be the > same issue). > > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
