Hello Don,
It's too late to change feature list at that time (GUI part of
install). Asign Level attribute for your LoggingFeature and in
publish events set INSTALLLEVEL property to value above or below the
Level attribute of your feature to control whether it should be
installed or not. Somethin
As an addition/follow-up question... "LoggingFeature" is a sub-feature
of a feature called "Shared"
Is there a certain syntax for declaring a sub-feature when using Publish
Event?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasant
David,
If the file lived in SourceDir (which is set to TARGETDIR), you would want
to use
not
in your fragment.
Julie Campbell
[EMAIL PROTECTED]
-Original Message-
Message: 1
Date: Fri, 25 May 2007 11:56:54 -0700 (PDT)
From: Didactylos <[EMAIL PROTECTED]>
Subject: [WiX-users] Source
Mike Dimmick-2 wrote:
>
> You're using SourceDir but it sounds like you should be using FileSource.
>
> FileSource is used by WiX to locate the files to be installed. Light lays
> out the uncompressed files as specified in the SourceDir attributes.
>
> At runtime, Windows Installer locates the
I have the following 2 commands inside a "next" button control:
PROPERTY1="1" OR
PROPERTY2="1"
PROPERTY1="0"
AND PROPERTY2="0"
But instead of adding and removing the feature "LoggingFeature" I end up
with 2 properties REMOVE and ADDLOCAL
REMOVE ends up equaling "Loggin
You're using SourceDir but it sounds like you should be using FileSource.
FileSource is used by WiX to locate the files to be installed. Light lays
out the uncompressed files as specified in the SourceDir attributes.
At runtime, Windows Installer locates the files using SourceDir and copies
them
ERROR_SERVICE_REQUEST_TIMEOUT = 1053.
One of the gotchas with that AppId registry entry is that services
running with localsystem don't have the same view of the registry as an
interactive user because HKCR is a mapping. Adding that AppID data to
HKLM\Software\Classes\Appid fixed the problem for
I had a directory structure like this (I've simplified a bit):
It correctly found file.exe at .\SourceDir\file.exe I then refactored my
components into fragments. In one file:
And in a
> 2. The cabinet is only opened once. That's why the files have to be
sequenced perfectly because the
> Windows Installer will only read through the File table sequentially and
> any files out of order will get
> skipped. Cabinet files are optimized for front to back reading not
> random ac
Thanks for the reply Stefan. Yes that entry in registry was not made by
installer, so I added AppId element in my component and now registry entry is
appearing correctly.But problem still persist, it gives me same error 1053 when
I install service using MSI.
Pankaj
> Date: Fri, 25 May 2007
So to achieve the desired behaviour, setting the RegistryValue to Type
string but passing in a #-prefixed value will work with no side-affects,
correct? I mean, besides being conceptually wonky, of course.
That is,
Will write a DWORD on install, and also a DWORD on reinstall/up
2. Candle is working fast enough. It's light which is slow.
I switched off ICE validations (-sval). It helped a bit, but not
drammatically.
Linking 3-4 GB install takes 15 min if I don't compress data, and about
30-40 if I do compress data.
About 70% percent of the time I see tha
One of the things that ATL servers/services do when they start is to
look for an HKCR\Appid entry that says whether they are a server or a
service. If it doesn't find that localservice item there it won't know
it's supposed to call the service APIs. If you know it's a service and
never a server, d
1. Agreed. I'm working on a more advanced chainer for the WiX toolset to
hopefully ease a lot of this pain. Just doesn't exist today.
2. What was taking the majority of the build time? Were you batching up your
compiles (passing multiple .wxs files to candle.exe)? Do you have shared
cabin
1. Anti-virus software can cripple both the install time *and* the build time.
For build machines, you can usually tell the software to ignore the build
directories and the temp directory. For end user machines...
2. The cabinet is only opened once. That's why the files have to be sequence
System restore is a huge cost for installs through Windows Installer. I turn
off System Restore on all my machines because things install faster and I just
don't trust it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schrieken, Rene
Sent: Friday, M
Unfortunately, by design. That's the Windows Installer behavior for RegSearch.
The MSI SDK will have more details if you desire.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BES Installer
Sent: Friday, May 25, 2007 7:43 AM
To: Bob Arnson
Cc: Bei Liu (Volt); wix-users@lists.sou
1. You do not have to provide CustomActions as both 64-bit and 32-bit. For
example, all of the WiX CustomActions are 32-bit only and work fine on 64-bit
machines.
2. If you want to switch between 64-bit and 32-bit (you can't have a package
that installs both today) then you need to have some
This should be fixed in the build released today.
From: Mike Dimmick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 22, 2007 4:14 PM
To: 'Mike Dimmick'; Rob Mensching; 'Aaron Shurts'; 'Bob Arnson'
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Problem with SQL custom actions.
Actually
I'm seeing the same behaviour.
In my component I have the following lines:
In the resulting package, the relevant line in the Property table is:
Property = PORTVALUE, Value="1234"
In the Registry table, Value = #[PORTVALUE].
When I run this on a fresh install, it correctly wr
Can it be that creating the system restore point takes (extra) time?
At least that is what I see if I run filemon during an install...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: vrijdag 25 mei 2007 14:12
To: wix-users@lists.sou
It may be a stupid question, but do you have any anti-virus software
running? If so, that can completely cripple performance of an
installation, and since you indicate that it is the "File copying" phase
I would be interested to see what the difference is versus installing on
a non-protected system
Hello,
Sorry for the double post. I saw that my previous post is not readable
on Sourceforge
mail list web interface. I re-send it using the plain text.
I am using WiX 3. I am trying to develop a WiX extension for my custom
actions.
I follow the WiX Extension model.
So far I did not found a go
Hello,
I am using WiX 3. I am trying to develop a WiX extension for my custom
actions.
I follow the WiX
Extension model.
So far I did not found a good way to accomplish following: I would like
to have the same
WiX Extension use able on both 32 bit products and 64 bit products.
As I understan
Hi ...
I had similar problem two years ago.
I had no problem to install the service using 'Service.exe -service'
command.
I found out that during call to 'Service.exe -service' some registry
keys are written into HKCR.
If you have source code of your service check for the
YourService.rgs file an
I can't say with certainty, but I'd take a wild stab at FatalErrorDlg.
Rob
Sankaranarayanan wrote:
> Hi,
>
> We have LaunchConditons defined in node under node suh
> as
>
>
> (VersionNT>=501)
>
>
> When the User tries to install the MSI in any OS released prior to Windows XP
> - t
First there seem to be quite a few exceptions thrown.
I get both
A first chance exception of type
'Microsoft.Tools.WindowsInstallerXml.DuplicateSymbolsException' occurred in
wix.dll
and
A first chance exception of type 'System.InvalidCastException' occurred in
wix.dll
> wix.dll!Microsoft.Tools.W
27 matches
Mail list logo
