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
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.
this list.
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 wrote:
> The right substitute for Vista/XP like Quick Launch shortcut is to make the
> link pinned to the
-
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 h
r's quick launch bar 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 i
nistrator's quick launch bar 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 shor
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 cu
In my patch application I am removing one executable file and its corresponding
config file like this:
0
0
When I remove this patch, My.exe gets restored but not My.exe
rrently
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 application I
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 pat
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 b
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 a
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 pub
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 b
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 t
During uninstall items added to the Start menu are removed.
However, recently opened programs entry is still on Start menu for a while.
I know that it will eventually become the oldest entry and will go away, but is
there any API to remove it right away during uninstall?
TradeStation Group, Inc.
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]
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 ne
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 hi
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: [WiX-users] Do UFOs visit In
xample, if you have built with VC++ 2008 SP1 the RTM VC++ 2008 redist won't
> help. They're almost sde by side, just to confuse things more. The app is
> 32-bit, I assume, but apart from that the UFOs are just hiding the gory
> details ;=)
>
> Phil Wils
dard redist.
Basically 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
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.
-Original
Here is one example where you can try insert additional targets (bases)
http://schemas.microsoft.com/wix/2006/wi";>
http://www.myco.com";
Classification="$(var.CLASSIFICATION)"
AllowRemoval="yes"
OptimizedInstallMode="yes"
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
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 versi
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 w
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, 20
Not to discourage you but in early 3.0 versions I have encountered bugs that
prevented me from creating binary delta patches with Pyro. Patching the full
file was fine. I was too busy to follow up on the bugs or check if they were
fixed in later releases so I don't know what is the state right n
Yep. Primadonnas that "just write their glorious code" and expect that somebody
else takes care of how it ends up installed on the end user system(s) are more
norm than exception. In fact, I can understand that. For example, I wouldn't
mind having a dedicated slave to press compile and fix my co
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 time&date
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 p
I am able
to extract 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
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: Genera
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 Micro
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.
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: http://bit.ly/w
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
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 mechani
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
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), 25
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 synta
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) (74:4C)
rent between
platforms.
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
"don't matter"
for it to be able to assert 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 sche
ing 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...@tradestation.com]
Sent: Tuesday,
PM
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
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 problem
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]
Sen
Having this log entry in my C++ custom action:
LPCWSTR cause = L"Something 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 compa
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 som
: [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
> or no error code (see lo
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 MSI
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 R
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 ou
custom action? Is this custom action the target of a control event?
On Mon, Dec 7, 2009 at 3:44 PM, Tony Juricic wrote:
> 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
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 [mailto:p
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, Februar
: Re: [WiX-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 f
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 lin
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 discussio
: [WiX-users] Execute action during path installation
Yes. That's a fairly common way of making sure that a file doesn't get
installed on the system without breaking the component rules during
patching. That's a transitive component.
Phil Wilson
-Original Message-----
Fro
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 origina
olset.
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-rea
equires the original base MSI
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 REINSTALLM
iring-products-after-patches-advertised-features.aspxfor
some suggestions of how to do that.
On Wed, Aug 6, 2008 at 1:33 AM, Tony Juricic wrote:
> 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
> rule
g the same problem with recent builds? A month or two ago
changes were made to fix a couple of issues with delta patching.
On Tue, Aug 19, 2008 at 5:57 AM, Tony Juricic wrote:
> Ok, that makes sense. However, I can't get it to work either way. The
> problem is not in changing just the 4th
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: TRAD)
cp 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 of
the upgraded image.
h families.
}
}
}
-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
In a C++ DLL custom action I have the following code:
::WcaLog(LOGMSG_VERBOSE, "%s", "My log text");
MSI install is started with the following log options:
msiexec /i myinstall.msi /lv*x .\install.log
However, log file doesn't contain the text as could be expected. In
contrast, LOGMSG_STANDARD
Same problem here so I second a plea for help and more info
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 12:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names
fr
u are writing a managed application, you need to make sure it
has the AssemblyTitle assembly attribute set on it. That's where the
string comes from.
Neil
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony
Juricic
Sent: Wednesday, July 16, 2008
During installation I create some per-user folders in
Users\username\AppData\Roaming. Thus I get hit by ICE30 error.
I don't really understand why would creating folders under CU profile
cause problems for component un/installation in this particular case.
Anyhow, I solved the problem with a tric
e profiles after the installation occurs (using self healing).
im not sure if this answers all your question or not, let me know if you
need more input.
Tony Juricic wrote:
>
> During installation I create some per-user folders in
> Users\username\AppData\Roaming. Thus I get hit by ICE3
I was under the impression that runtime requires this dialog to have
exactly FilesInUse name since it is invoked by installer, not by user.
IOW, its name cannot be customized.
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 5:03 PM
To: General dis
Disregard my previous comment. It is dialog ID which must remain
"FilesInUse", of course, everything else can be customized.
In my case which requires a lot of customization I have pulled in the
entire WixUI_en-us.wxl and renamed it into CustomWixUI_en-us.wxl
-Original Message-
From: Nei
1) I don't understand how do wixpdb ouputs deal with binary delta
patches? Looking at example commands it appears as if MSI (or binary
files compressed inside MSI cab) are not needed, as if all relevant info
is contained in wixpdb.
Or is it that torch, while working on the differences between 2 w
As Bob, of Joy of Setup fame, explained here once, there is no way to
change the level used by ARP and UILevel is read-only during uninstall.
However, you can add Change ARP option which would launch your authored
Change dialog from which you can proceed to a full UI uninstall (or
repair or the rea
I assumed you are talking about uninstalling via ARP. Otherwise the
batch file with the following content works just fine in my daily
testing:
msiexec /x myproduct.msi /qf /lv*x .\install.log
qf is for full UI and you can put product code instead of msi filename
since you are not supposed to know
Or am I, for the time being, still better off with the old-style
administrative installs and PatchCreation?
In my case binary delta is the requirement.
Thanks
-Original Message-
From: Tony Juricic
Sent: Monday, July 21, 2008 2:08 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX
Examples:
MyProperty=0
Not Installed
-Original Message-
From: jmcfadyen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2008 3:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setting standard action conditions
How can I set a condition on a standard action.
I have Progress with disabled Close button so it prevents me from
cancelling the installation while it is displayed.
Yet, I have done nothing (that I am aware of) to cause that. Progress
dialog is declared like this:
controls with progress bar etc.
I know that there is a MSI message
I have MSI file on my desktop that I just used to perform the install.
When I click on MSI Change welcome dialog, authored by me, is shown -
all is fine.
When I click on ARP entry and select Change menu item some Installer
message box appears and goes away so fast that I cannot read it, but I
don
This has nothing to do with WiX since I have just found out that not a
single product that offers Change option in my ARP list would work.
A brief flash of some message box is all I see.
-Original Message-
From: Tony Juricic
Sent: Thursday, July 24, 2008 3:50 PM
To: wix-users
... and the solution is ... reboot!
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to
1
.
.
.
This?
Tony Juricic wrote:
>
> I have Progress with disabled Close button so it prevents me from
> cancelling the installation while it is displayed.
>
> Yet, I have done nothing (that I am aware of) to cause that. Progress
> dialog is declared li
n
the generated wixmst file to generate the deltas.
At least that is the way it was working when I added it to WiX.
-Blair
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony
Juricic
Sent: Tuesday, July 22, 2008 2:50 PM
To: General discussion for Window
1) new patch project template
2) 2 new output types, binary and non-binary wixpdb
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win
Non-binary ones are just XML so I use XML Notepad to look at them. For
MSI's I use Orca. Is it that a tool for previewing binary WiXpdbs has
yet to be written ?
Thanks,
Tony
-
This SF.Net email is sponsored by the Moblin You
Giving command:
"%WIX%bin\torch.exe" -xi rtm\Product.wixpdb upd1\Product.wixpdb -out
Patch\Diff.Wixmst
I get the following error:
error TRCH0048 : The document element name 'wixOutput' is invalid. A WiX
pdb file must use 'wixPdb' as the document element name.
Clearly torch doesn't like somethin
With just -bf and -xo as additional linker options Votive creates this
command line:
C:\Program Files\Windows Installer XML v3\bin\Light.exe
-loc CustomWixUI_en-us.wxl
-out C:\path\Product.msi
-pdbout C:\path\Product.wixpdb -bf -xo
obj\Debug\BrowseDlg.wixobj
... dialog and other wixobjs ...
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 tool
version
number?
There is a share proderrors or something
Pete Yates
Senior Systems Developer
DDC - Distributed & Components Team
HBOS I&I IT
B/1/C/243
(7725) 34383 / (0117) 376 4383
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Beha
aller.aspx
.
On Thu, Jul 31, 2008 at 9:22 AM, Tony Juricic <[EMAIL PROTECTED]>wrote:
> Are you saying that there is some way to get better error diagnostics
> from Torch?
> I added -v option for verbosity but it has no effect.
>
> In fact, I can't even figure out how do valid
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).
Co
version
number?
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
MyProd
neral 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
>
1 - 100 of 155 matches
Mail list logo
