Not able to test, but try something like this (from the documentation):
Kind regards
Hans
>
> thanks Hans.
> Tried the third option of QTExec and it errors out.
> with the following message:
>
> CAQuietExec: Error 0x80070057: failed to get command line data
> CAQuietExec: Error 0x80070057
thanks Hans.
Tried the third option of QTExec and it errors out.
with the following message:
CAQuietExec: Error 0x80070057: failed to get command line data
CAQuietExec: Error 0x80070057: failed to get Command Line
This is from my wxs:
post wrote:
>
> Hi Vivek,
>
> You have at le
I need to have a merge module custom action happen at the end of the
InstallExecuteSequence.
Normally I sequence a "MyFinalize" custom action in a merge module as
being after InstallFinalize, but if RemoveExistingProducts follows
InstallFinalize then MyFinalize must be after RemoveExistingProduct
In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]> writes:
> Have you ever generated the WiX registry code for
> VB6 COM component? Has anyone?
Oh, I almost forgot -- yes, I have registered VB6 COM components
manually by populating the Class, etc., tables. I haven't don
In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]> writes:
> Richard
>
> >> The answer to that is pretty simple -- you ignore anything that's not
> >> related to your component.
>
> I think you are missing the point (or I am), how do I know it is not
> related?
Well,
Richard
>> The answer to that is pretty simple -- you ignore anything that's not
>> related to your component.
I think you are missing the point (or I am), how do I know it is not
related? In VB6 you don't edit the COM registration so you don't know
the details. I have a fairly simple ocx and he
No idea... thought the last one went through (but obviously didn't check).
I'll make sure it goes through correctly this week.
-Original Message-
From: Alex Ivanoff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008 12:16
To: General discussion for Windows Installer XML toolset.
My config file is simple. Just a configuration section.
I want to add a connectionStrings section inside the existing element.
However, the installer always does this
Any ideas?
Chad
---
In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]> writes:
> The key issue here is what do you need to exclude when registering a VB6
> DLL or is it possible to monitor it so we find the key information. Can
> you recommend a registry monitoring tool that works for VB6 DL
In article <[EMAIL PROTECTED]>,
Rob Mensching <[EMAIL PROTECTED]> writes:
> Note, those actions are only necessary if you are using the Advertised
> features of COM registration otherwise it's all just Registry rows.
True. So let me state it another way -- is there an ICE that fails if
you
In article <[EMAIL PROTECTED]>,
"Evans, Jim" <[EMAIL PROTECTED]> writes:
> Interestingly, ProcMon (the successor to RegMon) was no help here, as
> all of the registration calls were being sent to HKEY_CLASSES_ROOT,
> which does not differentiate between which elements are going to the
> user
I have some sql scripts that should only be run on initial install and never
again. Unfortunately, before this was released, the scripts were in such a
state such that they couldn't detect that they had already been run. So, when
the component installs during the major upgrade the scripts run ag
What happened to weekly releases?
-
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
Q: I'm also curious why you chose to use an Include instead of using a Fragment
with a ComponentGroup in it that is pulled in at link time?
A: Ignorance.
It seems like what you are suggesting is more complicated than my current
solution, but its more likely that I simply don't fully understand
Understood and I'm just trying to ensure that everyone understands that the
reasons the WiX toolset doesn't have a general purpose tool that solves this
problem because a "correct and complete" solution is very, very difficult to
implement.
I'm also curious why you chose to use an Include ins
Rob,
You are correct, it does require some diligence on the source control side.
In my case, I do dynamic file pickup on files that are not to be patched or
updated . For example, we don't patch sample files, so the dynamically
included files are locked down after we release, thereby eliminati
Neil Sleightholm wrote:
> My untested theory is that when you call DllRegisterServer on a VB6 DLL
> it either calls DllRegisterServer on MSVBVM60.dll or the code from it is
> embedded into the VB6 dll.
>
In my experience, self-reg code gets extra-aggressive in response to bug
reports to respon
1. What happens if you want to add or remove one of those sample files? You
can't technically add or remove resources from a Component so that would break
things... unless you guaranteed a major upgrade. Like I said, it gets tricky.
3. Did you actually specify any Files to be compressed? Ei
Rob,
I am using one component for a group of files, not all my files. For example,
non-versioned files like samples that are all grouped into the same directory
(and therefore the same component) should be safely grouped in one component, I
believe.
Regarding the embed cab, it does not work f
Richard
This has gone off topic a bit but yes I have done complex c/c++
registrations and have monitored what happens when com is registered and
it all made sense until I monitored a VB6 DLL.
For example, it always seems to rewrite this (among many many more):
Key:
HKCR\CLSID\{D5DE8D20-5
1. One Component with all your files in it is a can be a very dangerous
design. There are a lot of servicing scenarios where you might be very unhappy
with that decision. The difficulty of autogenerating Components that meet all
"good design guidelines" is why we don't have a good tool in WiX
Thanx -- I actually have an alternate wix installer already for our
product -- I really just need to add another component or two and some
more custom actions. For the most part the work is in rewriting the
custom actions. Other than that, I just need to reorganize it a bit and
use the old comp
I just moved a project from IS 12 to WIX, other than what has been pointed out
below, here is what I did:
1. Created my IS 12 generated msm's
2. Ripped out all the IS tables in the .msm's with ORCA
3. Ripped out all the IS custom actions, binaries, properties, etc... in
the .msm's
Glad you got this worked out. In my case, the problem was that I wasn't
specifying ALLUSERS=1, so I was inadvertently doing a per-user install
instead of a per-machine install. When the Windows service (running as
LocalSystem) tried to instantiate one of the COM objects, it couldn't
find the regist
Note, those actions are only necessary if you are using the Advertised features
of COM registration otherwise it's all just Registry rows.
Also, I personally don't recommend advertising COM goo
(http://robmensching.com/blog/archive/2007/03/12/RobMens-Recommendation-Do-not-advertise-COM-informati
In article <[EMAIL PROTECTED]>,
"Troy Howard" <[EMAIL PROTECTED]> writes:
> [...] The default sequence doesn't
> include the com registration actions that read the class table/etc.
IMO, that seems like a bug in WiX. IIRC, the recommended default
install sequence *does* include all the regi
In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]> writes:
> All regsvr32 does is call DllRegisterServer on the DLL, what happens in =
> here is voodoo! It is perfectly legal to d anything you want in this =
> call and is the reason why self registration is frowned upon.
Sorry... Should have included that to begin with - v2.0.5325.0
Thanks
Mark
-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 6:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] preprocessor and enviro
That's *one* of the reasons SelfReg is frowned upon.
The other big problem with SelfReg is that the Windows Installer doesn't
rollback SelfReg.
Another big problem with SelfReg is that they are more fragile than using the
built in functionality in MSI. MSXML3 [I think] used to have SelfReg a
Sorry, caught the end of this thread.
1. You need to maintain Component/@Guids according to the Component Rules. It
doesn't matter what tool you use to create the MSI. Once you ship, you must
maintain the GUIDs appropriately.
2. ProductCodes and UpgradeCodes need to be updated following the
Or, better, write a C++ CustomAction that writes temporary rows in to the
RemoveFile table and let the Windows Installer do the heavy lifting. I may
have to write this CustomAction for my team soon... if I do, I'll add it to
WiX, like everyone else could.
-Original Message-
From: [EM
You should *not* change the Component GUIDs. Component GUIDs must be stable
from release to release. ProductCodes need to be updated according to how you
want your package to upgrade.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008
Yeah, Windows Installer doesn't let it work. Why? Some message processing
issue inside them. I think this is documented in some small print somewhere.
PS: Please don't shoot the messenger.
-Original Message-
From: John Hall [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 200
That's supposed to be taken care of by Windows Installer itself. You can run
as many as you like in
the UI mode, but there's supopsed to be a guard so that only one instance can
perform the
server-side actions. Are you seeing something different, or do you mean you
want to only have one
ins
Hi All,
I am newbie to Wix.
I wanted to know if there is any option by which I can allow only a single
instance of MSI to run.
Right now, if I execute one instance of MSI and start the other one, then it
allows seamlessly to run both the msi installers. Ideally, only one should be
allowed.
All regsvr32 does is call DllRegisterServer on the DLL, what happens in here is
voodoo! It is perfectly legal to d anything you want in this call and is the
reason why self registration is frowned upon. I know a VB6 DLL is just doing
standard COM stuff but it is way more complicated that any COM
In my installer I have some C++ custom actions that log to the main MSI log
file using MsiProcessMessage. I'm now writing a CA that is executed on a button
press in the UI as the user leaves the feature selection dialog. However, none
of my debug output is appearing in the log.
Is there a reaso
Hi Vivek,
You have at least these options:
1)Create a DTF custom action
2)Create a VB script custom action
3)Look into Quiet Execution Custom Action (ref Wix Help file)
and then put a condition like REMOVE="ALL" so it does not get run on
installs.
If these files and folders are not installed by
38 matches
Mail list logo
