Yey!!!
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Monday, January 31, 2011 10:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX v3.5 released!
WiX v3.5 Released! Tell your friends. Read more here:
For a while patching errors like:
MSI (s) (28:48) [13:52:25:298]: Product: MyProduct -- Error 1328. Error
applying patch to file C:\Config.Msi\PTCCC8.tmp. It has probably been updated
by other means, and can no longer be modified by this patch. For more
information contact your patch vendor.
Just found out that Microsoft is retiring current installer and this quote:
InstallShield 2011 should be an installation development environment of choice
for Visual Studio users, ensuring that Visual Studio applications of any kind
can be professionally installed and work with the latest
Yeah, I feel bad too. I mailed some initial trials errors to Peter Marcu and
never found the time to investigate in more details and file an official bug
report.
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Thursday, September 23, 2010 5:31 AM
To:
the .msp file immediately after creation and confirm that files
are not included that I wish to include. Applying the patch in Orca shows
the same issues. It looks like this is occurring at the patch assembly
level.
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com
MSI calculates the hash of data files and, if hash is different, patch will
update the older file.
However, that is only in the case that file creation and modification timedate
are identical.
When time date are not identical, MSI assumes that file was touched by the
user and won't patch it.
These are not WiX rules but MSI rules and are documented on MSDN site,
somewhere in install patching section.
-Original Message-
From: Travis Gaff [mailto:tra...@pc-doctor.com]
Sent: Thursday, September 16, 2010 12:48 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How does
Good ole' MessageBox is the most reliable way to debug C/C++ CAs that I found.
You may be able to set the breakpoint after the MessageBox and then attach to
the running msiexec process.
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Tuesday, August 24,
Often this happens when versions of the files are not correctly set. That is,
your patch contains one file that has changed (i.e. binary comparison will show
differences) but version number of dll or exe was not changed.
However, if you read install documentation (and some blogs) in depth, you
As a long-time temporary setup guy I do help 'my' developers by loading exes
and dlls in VS2008 and opening their manifests. I check module dependencies and
tell devs if something is wrong. For example, normally (unless mandated by a
binary third-party component) we don't want both 8 and 9
Thanks Sascha!
So far we had 40 users with vcredist_x86.exe install problem. All Windows 7 but
not only 64 bit. It is interesting, but not yet enlightening to me, how some
issues got solved. Quite a few users run vcredist_x86.exe manually, with full
UI. Normally it is run silently by our setup
I always use just one base but multiple bases (i.e. targets) are possible from
what I understand from the documentation. I avoid them because that increases
the size of the patch (differences from both bases must be stored in a patch)
but it should work if you declare two targets.
Here is one example where you can try insert additional targets (bases)
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
?include VersionDefinitions.wxi ?
?include PatchCreationDefinitions.wxi ?
!-- patch id needs to be updated --
PatchCreation
to confuse things more. The app is
32-bit, I assume, but apart from that the UFOs are just hiding the gory
details ;=)
Phil Wilson
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Monday, May 24, 2010 7:39 AM
To: wix-users@lists.sourceforge.net
Subject
it doesn't matter what MFC/CRT files are on the system when there are
policy files redirecting you. You'd have to look at your manifest, then see
what MFC policy files are there that might redirect you, and the same for the
CRT.
Phil Wilson
-Original Message-
From: Tony Juricic
The title reflects the strangeness of the problem that I am trying to solve. It
is not WiX specific but in the broader install community there is higher chance
that somebody may have had similar experience.
It starts with user installing vcredist_x86.exe on his Windows 7 64-bit. He is
sharing
from that the UFOs are just hiding the gory details
;=)
Phil Wilson
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Monday, May 24, 2010 7:39 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Do UFOs visit Install land?
The title reflects
If it were using WPF, I would seriously consider it.
-Original Message-
From: Michael Clark [mailto:mcl...@fullarmor.com]
Sent: Thursday, May 13, 2010 5:02 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Finally a GUI solution with WiX
I was just getting ready to start a
One way of avoiding overwrite by the default value during Change is to store
INSTALLDIR value in the Registry as the part of custom action that is
conditionally executed only on fresh install (i.e. Installed property)
-Original Message-
From: Sachin Dubey [mailto:sachin.du...@live.com]
My understanding is that QFE2 is created as the difference between the RTM and
your current code base. Applying QFE2 will use RTM as the base whether you
installed QFE1 or no. There should be no need to uninstall QFE1 short of
wanting to prevent user from ever running that code (which would be
Since my external UI is WPF I am really bothered, both by having to
disambiguate several classes and by having to reference forms Dll just for a
few enums, when calling Installer.SetExternalUI. Hopefully these enums will
become UI-system-agnostic in the future.
TradeStation Group, Inc. is a
I believe so.
Custom action are in MSI database which is transformed before the
install/uninstall (really repair in the case of the patch) starts running
custom actions. So during patch install you get patched actions executing.
During uninstall you get unpatched action or no action executing
I run into this problem when creating the patch:
ERROR: Internal PatchWiz Error occurred.
ERROR:The Last Error Received is: 1627
ERROR:The Last Error Received is: 1: 2210 2:
which is caused by Patch table having default Sequence field of type I2
I used Orca to create default Patch table
That's right. I my experience it doesn't really matter if component remains
transitive (my case) or loses transitive state when removing the patch. The
question to ask is: if patch application removed file(s), when patch itself is
removed how will those files come back? And the answer seems to
I think that now I understand what happened.
My expectation about patching system behavior when component is transitive was
wrong.
During patch application, transitive component condition gets evaluated and, if
it has changed from true to false, component gets deleted. However, to
facilitate
if a component is currently
marked transitive.
Phil Wilson
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Thursday, January 21, 2010 8:19 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Does patch removal restore removed data files?
In my patch
At which point in the patching process are custom actions that are executing
the updated ones?
I have custom actions that execute before and after PatchFiles action.
Custom action executing before PatchFiles finds MSI DB already transformed.
Based on that I would expect that table containing
and hence is invisible for the normal user(s)?
Tom
On 17.12.2009 21:53, Tony Juricic wrote:
The right substitute for Vista/XP like Quick Launch shortcut is to make the
link pinned to the taskbar (IMO).
It appears as simple as putting the shortcut in User Pinned\TaskBar subfolder
of Quick
(s)?
Tom
On 17.12.2009 21:53, Tony Juricic wrote:
The right substitute for Vista/XP like Quick Launch shortcut is to make the
link pinned to the taskbar (IMO).
It appears as simple as putting the shortcut in User Pinned\TaskBar subfolder
of Quick Launch folder in Windows 7
-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Tuesday, December 22, 2009 11:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Quick Launch shortcut in Vista and Windows 7
Tony Juricic wrote:
Hmm... I guess I would have a hard time to pass a concept here
The right substitute for Vista/XP like Quick Launch shortcut is to make the
link pinned to the taskbar (IMO).
It appears as simple as putting the shortcut in User Pinned\TaskBar subfolder
of Quick Launch folder in Windows 7.
!-- Quick Launch per-user folder --
Directory Id=QL1
.
And anyway auto-pinning your application to the Windows 7 taskbar will
an excellent way to quickly lose customers :)
Sascha
On Fri, Dec 18, 2009 at 7:53 AM, Tony Juricic tjuri...@tradestation.com wrote:
The right substitute for Vista/XP like Quick Launch shortcut is to make the
link pinned
Unless there is a much more elegant method, you may try a good ole' Win32
method:
- use Spy++ to find the dialog ID of the control (s):
- use Setup Window title to find the dialog HWND (you may be doing this already
to parent your message window)
- get HWND of the control using GetDlgItem
- call
At one point I was thinking that I have too many C++ Custom Action Dlls and
started using existing Dlls. That is, I added a new entry point for a new CA in
a Dll that already hosted code for existing CA. That appears to work just fine
except for one issue: WcaLog() doesn't work - nothing gets
I have verbose log and this is all the extra info that I find about the cause
of the reboot:
MSI (s) (4C:E8) [18:33:27:219]: RESTART MANAGER: Did detect that the client
process of this installation holds file[s] in use, so a reboot will be
necessary.
Is there any way to find out which files
Post log excerpts. I have an opposite issue. I have to force REINSTALLMODE=o
to *AVOID* Registry from being updated with original values. However, for me
Change leads to either Repair or Uninstall. I don't really know what just
Change by itself means or does.
Repair should definitely restore
While there are quite a few samples of appropriate Custom Action (including
some posted here) none of them work for me. I either get an error code 1631 or
no error code (see log example below where it appears that app was launched ok)
but I see no application UI (it is a WPF app).
Is there
Installer XML toolset.
Subject: Re: [WiX-users] So how does one run installed executable after the
install finishes?
Tony Juricic wrote:
While there are quite a few samples of appropriate Custom Action (including
some posted here) none of them work for me. I either get an error code 1631
Having this log entry in my C++ custom action:
LPCWSTR cause = LSomething is [funky] here;
::WcaLog(LOGMSG_STANDARD, [MYLOG] program failed because %S, cause);
This is the log that I get:
program failed because Something is here
TradeStation Group, Inc. is a publicly-traded holding company
Try verbose log to see which file has a problem. Use command line like:
msiexec /update mypatch path\MyPatch.msp /lv*x .\Patch.log
Then in the log you will find the entry saying that local source for some file
can't be resolved and that it is trying to find the original MSI.
In my case problems
Also check that component rules are not broken (it can take time understanding
them well):
http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101
http://msdn.microsoft.com/en-us/library/aa372795(VS.85).aspx
-Original Message-
From: Oivind [mailto:oivind.fla...@visma.com]
that the file is the same before applying the
patch it). If you are using Pyro instead of PatchWiz, the IgnoreRange
element goes under the File element in building your Updated image (it
seems to be missing from the schema/help doc).
-Original Message-
From: Tony Juricic [mailto:tjuri
, the IgnoreRange
element goes under the File element in building your Updated image (it
seems to be missing from the schema/help doc).
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Tuesday, September 01, 2009 6:08 PM
To: General discussion for Windows Installer XML
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Patch failure on XP that doesn't happen on Vista
Alternately try building with version 5.1 of MSPATCHC.DLL (by building on an
XP box?).
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com
This is probably not DTF specific issue. I have code to add a table to MSP file:
using (Database db = new Database(file, DatabaseOpenMode.Transact))
{
ColumnInfo[] arrc = new ColumnInfo[2]
{
new ColumnInfo(Key, typeof(string), 32, true),
new ColumnInfo(Value, typeof(string), 256,
It was the length of the string in second 'Value' column - it must be at most
255 characters.
-Original Message-
From: Tony Juricic
Sent: Tuesday, September 01, 2009 2:09 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Creating database table via DTF - SQL syntax
Applying the patch on one XP system produces the following error log for one
file (edited here to shorten the path to MYFILE.EXE):
MSI (s) (74:4C) [17:23:03:041]: Executing op:
CacheBaselineFile(Baseline=0,FileKey=MYFILE.EXE,FilePath=C:\Program Files\..\
MYFILE.EXE,,Existing=0)
MSI (s)
.
For a workaround we had to mark that one file as whole file instead of
delta. It didn't happen every build, but it did happen for about two months
around one of our major releases.
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Tuesday, September 01, 2009 2:56 PM
I have an interop assembly that breaks my patching.
When patch is installed verbose log shows this:
MSI (s) (78:E8) [16:12:06:987]: Baseline: INTEROP.SERVICELIB.DLL not touched in
this transaction, verification required.
MSI (s) (78:E8) [16:12:06:989]: Baseline: Existing INTEROP.SERVICELIB.DLL
One thing that you may try is the following:
1) put all the files that may get deleted inside their own component
2) Do not set any Guid for that component
Windows Installer will ignore these files when it comes to patching so you will
never be able to upgrade/downgrade them via patching
In this particular case I am not interested in setting Company Name and version
number for my interop assemblies (that is, files generated using tlbimp) just
so that the name is not an empty string and that the version is not 1.0.0.0.
In order to have un-installable patches I need assembly file
.
}
}
}
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Monday, June 15, 2009 12:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How much of patch pcp database makes it into
msp?
Thanks Bob but this, unfortunately, does not seem
: [WiX-users] How much of patch pcp database makes it into
msp?
Tony Juricic wrote:
In particular, can I somehow get MediaSrcPropName value, from *.pcp
ImageFamilies table, using DTF on my patch *.msp file?
The doc says:
The value entered into the Source field of the new Media table entry
In particular, can I somehow get MediaSrcPropName value, from *.pcp
ImageFamilies table, using DTF on my patch *.msp file?
I suspect that answer is, most probably and unfortunately, no, but just
in case... thanks!
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS:
-advertised-features.aspxfor
some suggestions of how to do that.
On Wed, Aug 6, 2008 at 1:33 AM, Tony Juricic tjuri...@tradestation.comwrote:
It just goes to show how easy it is to commit gross component rules
violations even after months of reading articles and blogs on component
rules!
However
andIdon't know why
Tony Juricic wrote:
DLL is supposed to always increase in version so it can be patched up
but it should never revert to previous version during patch uninstall.
Whether that's true depends on your original product's REINSTALLMODE
property.
I
assume that just marking
.
Subject: Re: [WiX-users] Patch uninstall requires the original base MSI
andI don't know why
Tony Juricic wrote:
The uninstallable patch is looking for the original MSI that was
extracted from Setup.exe chainer into temporary folder and is since
long
gone.
I re-read the docs but I am still
The uninstallable patch is looking for the original MSI that was
extracted from Setup.exe chainer into temporary folder and is since long
gone.
I re-read the docs but I am still clueless as to what caused it.
Naturally, I want to uninstall the patch without requiring the access to
the
breaking the component rules during
patching. That's a transitive component.
Phil Wilson
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Tuesday, February 10, 2009 5:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users
It is possible to put a file into a Component containing only that file,
make it volatile and change the condition for installing the component
from 1 to 0.
-Original Message-
From: Brian Rogers [mailto:rogers.br...@gmail.com]
Sent: Tuesday, February 10, 2009 6:43 PM
To: General
Would this really work? I ask because I have never managed to get
conditions to work for Registry components. In my experience Registry is
handled in bulk. All the components (i.e. Registry keys and values)
either get created/written or no.
-Original Message-
From: p...@hoaske.dk
Say you are upgrading existing installation and you want to leave the
value as it is. Like, user selected yes for some option. Otherwise it is
a fresh install and you want default initial value of 'no'.
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Monday,
-users] Registry Manipulation
If you condition out a Component then nothing in that Component should
be installed/uninstalled/repaired.
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Monday, February 09, 2009 08:36
To: General discussion for Windows
I know that Jason sometimes reads this forum but otherwise I am not sure
this is the right place to report the following:
I was using version 3.0 of Microsoft.Deployment.Compression.Zip in an
attempt to extract MSI from self-extracting executable.
In particular I used the class ZipInfo, IsValid
Is there anybody who had a chance to try the above, as per link:
http://msdn.microsoft.com/en-us/library/aa367575(VS.85).aspx
I was just unpleasantly surprised that it appears not to work for my
MSIs.
For example, I had version 5.0.0.12 of one DLL installed. After issuing
command line as per
, 2008 10:57 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stack available for Custom Actions
What are you doing to run out of stack space? When I get a stack
overflow it has always been a bug in my code.
-Original Message-
From: Tony Juricic [mailto
it is using.
Maybe pick a different 3rd party vendor?
-Original Message-
From: Tony Juricic [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2008 05:50
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stack available for Custom Actions
I invoke 3rd-party
I am getting a stack overflow exception when executing deferred custom
action in C++, but I am consuming only a quarter of 1 MB which, I
believe, is the max stack space allowed per process.
Did anybody here have similar things happen to him/her?
I'm wondering if msiexec indeed gives much reduced
Answering my own post - the problem was that Product element must have
compressed=no attribute set when building MSI with no CAB.
I had this attribute set to yes.
-
This SF.Net email is sponsored by the Moblin Your Move
I am trying to build MSI with no cab and all files uncompressed. I have
the following Media element declaration:
Media Id=1 Layout=InstallTree VolumeLabel=DISK1 /
Myproject.wxs(1266): error LGHT0135: The file '_SOMEDATAFILE.TXT' should
be compressed but is not part of a compressed media.
Some patches are un-installable:
http://msdn.microsoft.com/en-us/library/aa372102(VS.85).aspx
I'm offering to pay and ship few cases of beer and hamburger patties so
that you guys at Microsoft can meet somewhere at campus, relax, hammer
this out and explain all of it (I mean patching business)
I often encounter problems debugging deferred C++ DLL CAs. Most of the
time DebugBreak() works. Now and then it won't and then I use __asm {
int 3 } which, for some reason, tends to work more often than
DebugBreak.
Then I encounter situations when even int 3 won't work in the sense that
Vista
You just invoke custom action before files are removed. I don't backup
files but do some COM unregister before files are removed and there are
no problems doing that.
-Original Message-
From: xiaoli [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2008 1:46 AM
To:
There is also PatchIgnore attribute that can be set on individual file
element. It's a pity that we can't do it for Registry keys and values
too.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
I had the same problem and switched to self-registering servers, i.e.
setting SelfRegCost attribute on corresponding file elements.
I know this approach is not officially recommended but it is hard to see
what some third-party COM servers do with the Registry.
-Original Message-
From:
a1) In theory, using new WiX patching you can simply exclude components
containing binaries that you don't want to patch from the list of
components to patch. This list is child of PatchFamily WiX element. If
using 'old' patchwiz.dll-based patching (i.e. WiX PatchCreation element)
you can use
Regarding programming the Progress Bar
http://msdn.microsoft.com/en-us/library/aa367525(VS.85).aspx
and especially
http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourcefo
rge/m/ms/msiprogramming/BillboardsAndProgressBars.pdf
is probably the best documentation that you can find
Oops, this was really intended for miscrosoft.public.platformsdk.msi.
I did a test with XP with Framework 2 already installed and then run
Client Profile install. What you get is pretty much the same as if you
had downloaded 3.5 installer from MS site manually and then run it. IOW,
your user will
Good to know! Hopefully WiX compiler can catch these errors in the
future.
What you described looked very similar to my past experience but,
checking the old forum posts I see that it caused a different error:
1328.
Basically I had a case like:
RTM.msi Update1.msi Update2.msi ... etc.
My
Ok, that makes sense. However, I can't get it to work either way. The
problem is not in changing just the 4th version number either. I created
a simple C# console executable that has one line of code:
Console.Writeln(This is version 1.0.0.0);
and assembly info AssemblyVersion(1.0.0.0)] and
I use PATCH property as a condition to change text from 'Repair' to
'Update'. There is nothing wrong - patch is a sort of repair.
-Original Message-
From: postingbox [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 7:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users]
Don't patch the patch!
Always target:
a) only RTM
b) RTM + another (non-patched) full install built after RTM
c) same as b plus you can add all full install MSI targets built after
RTM and preceding your patch build)
I don't know why 'they' (i.e. secretive installer people who reveal
pieces of
I've got one working version and it turned out to be very quick and
easy. I tested it on one pristine XP SP2 installed in Virtual PC and it
works like a charm. Quite a relief after waiting one hour for SP1
install to tell me that I need to close WiX.chm HTML Help file.
The procedure is the
Even if I add comments attribute to PatchInformation element, the
resulting MSP Patch Summary Information Comments editbox is empty when
viewed in Orca. It is also unclear if and how can one set up Title,
Author and Subject parts of Summary Information via WiX.
Have you had any success in somehow using that bootstrapper with WiX
generated MSI?
Can you share some insights/experiences?
For me installing SP1 turned out into a progress bar sits there not
moving anywhere for hours experience so the whole idea of a smaller
Client Profile footprint turned
It is a good advice, thanks!
Since I can have patching options configurable via REINSTALLMODE, I see
no good reason to hard-code PATCH property conditioning inside wxs, as
I did for registry writing action.
However, just as I accepted thinking in terms of resources inside
components,
I use one of my main installed folders and go back one level to get the
root. All installed folders become public properties (property name the
same as folder Id) available also during the uninstall if not in
deferred CA.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
I use one of my main installed folders and go back one level to get the
root. All installed folders become public properties (property name the
same as folder Id) available also during the uninstall if not in
deferred CA.
-Original Message-
From: Dmitry Berkovich [mailto:[EMAIL
I am using condition NOT PATCH to change the text in UI to say Patch
instead of Repair when patch is applied. That works just fine.
Now I want to avoid installing one Registry component during patch
application but not during the repair. I used the same condition (i.e.
NOT PATCH rather than NOT
I tried adding Transitive attribute to the registry component and that
deleted the component when patch was applied. Thus 'NOT PATCH' is a
correct condition since transitive components are removed when condition
changes from true to false.
However, for some reason that I would really love
You can always use custom action to write that part of the Registry.
However that would not be politically correct. I mean, using CA when MSI
database solution is available. Unfortunately sometimes it appears as if MSI
people do everything they can to force us to use CAs even in cases which
-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2008 12:04 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] New wix binary delta patching doesn't work
Tony Juricic wrote:
I have 2 MSIs and 2 corresponding binary wixout files. Using new
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version
number?
Tony Juricic wrote:
but reading the install.log I cannot find anything a bit more explicit
about this violation. It is certainly not saying something like you
changed the name of your
Just to make my life easier, now that I corrected the mistake and
double-checked that I haven't committed component violation again, I am
back to having exactly the same problem.
Pyro doesn't find anything to put in a patch cab and running verbose log
doesn't reveal anything.
Even a nice tool
I can confirm this now that I produced two MSIs that don't have any
component rules problems. Some history of this problem can be found in
posts titled 'Does Pyro (or Torch) ignore 4-th version number?'.
I have 2 MSIs and 2 corresponding binary wixout files. Using new
patching with wixout input
?
Tony Juricic wrote:
If Pyro is not ignoring 4th version number then it must be that I am
breaking some component rules?!
I haven't added or removed or renamed any component file or guid but I
have changed the target install directory name from MyProduct to
MyProductV1 (to be created under Program
Ok, so renaming my wixpdb files, produced as described above, to wixout
extension solved the problem for torch input and it produced wixmst
output file. Thus, apparently, wixpdb can exist only in XML format,
while wixout is binary.
Based on Peter Marcu's blog I understood that wixpdb substitutes
I have 120 MB large Wixmst created by Torch and when I pass it to Pyro
it comes back with the message PYRO1079 saying that patch cabinet
contains no files.
My DLLs in RTM and Update respectively differ in the last, 4-th version
number, plus the binaries themselves are different. Using SDK
?
There is a share proderrors or something
Pete Yates
Senior Systems Developer
DDC - Distributed Components Team
HBOS II IT
B/1/C/243
(7725) 34383 / (0117) 376 4383
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony
Juricic
Sent
If Pyro is not ignoring 4th version number then it must be that I am breaking
some component rules?!
I haven't added or removed or renamed any component file or guid but I have
changed the target install directory name from MyProduct to MyProductV1 (to be
created under Program Files folder).
1 - 100 of 144 matches
Mail list logo
