Yaa I understand.
Could you tell me how to resolve this
Thanks
Rob Mensching-4 wrote:
>
> Your custom action failed (i.e. returned non-zero).
>
> SaiTeja wrote:
>> Hi,
>>
>> Below is my custom action
>>
>> > HideTarget="no"
>> Execute="deferred" Impersonate="yes" TerminalServerAware
I would have thought that the design bug would have been obvious based merely
on understanding of CA scheduling.Stefan has a great article on the subject
that I frequently refer InstallShield users to. I can remember a day years ago
when I read it ( and your component rules truth statemetns
The Xml custom actions are configured to run after files are installed for
exactly the case you list below.
-Original Message-
From: James Renton [mailto:[EMAIL PROTECTED]
Sent: Monday, November 05, 2007 13:14
To: Rob Mensching
Subject: RE: [WiX-users] XmlFile From Property
That's great!
Today it doesn't.
This is a bug a dev in VS (Mike) pointed out fairly recently and is
going through the exercise of investigating the options to see which is
the lesser of all evils. He also found that the extended permission
custom action didn't correctly reset ACLs on rollback and is working
Well, when a Component is uninstalled all of its contained resources are
supposed to be removed. You can prevent the Component from being removed
by marking it permanent. I have no idea why it works in one case and
not another. A verbose log file would tell you what's being removed
when and w
Your custom action failed (i.e. returned non-zero).
SaiTeja wrote:
> Hi,
>
> Below is my custom action
>
> Execute="deferred" Impersonate="yes" TerminalServerAware="no"
> ExeCommand="UninstallComService" FileKey="qmireg.exe">
>
>
>
> Installed And
> REMOVE="ALL"
>
>
>
>
> Whe
1. No. The documentation for the Group element clearly states,
"Searches for an existing group in the specified domain. Groups cannot
be created by this element."
2. Even if the directory already exists you can use CreateFolder to
ensure it exists and set permissions.
Dhaval Patel wrote:
>
Look in a verbose log file and make sure the Component that contains the
Shortcut is scheduled to be uninstalled.
SaiTeja wrote:
> Hi,
>
> I created short cuts using following code
>
> Name="Foobar10"
> LongName="Foobar 1.0" WorkingDirectory='INSTALLDIR'
>
There are topics in the WiX.chm file about the Quite Exec custom action.
diwakar09 wrote:
> Hi,
>
>
> In my installation i am using custom action for changing the file
> contents, I need to change 8-9 files. It shows many command window at
> installation, I want to hide these windows,
>
> I
Kelly is exactly correct. In this case, the first autogenerated GUID
that is getting you is the Package/@Id. The MSI SDK says that the
Package/@Id should be unique for every MSI file. Arguably you could say
the Ids should be the same in this case (and you could override the
autogenerate) but
As you've found, the design of Merge Modules prevent them from being
merged twice.
si wrote:
> Hi,
>
> Trying to get a product built for Reporting Services for a custom data
> and security extension.
>
> Reporting Services has ReportServer and ReportManager directories,
> and I need to copy files
I've had a similar problem - our Wise MSIs were previously using
regasm/regsvr32 custom actions to register DLLs. In the switch to WiX
though, I've written a CompilerExtension to get the registration info on
compile and output it into the registry table of the generated MSI. It's
fairly rough still
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50
Ben, I've created an installer for a C# COM addin using Wix, and I ran
into some of the same problems. The best way to get the necessary COM
settings for a registration seems to be to use a registry sniffer that
can compare snapshots. I took a registry snapshot, registered the
assembly, and then
Are you installing into the System folder? The 71 Dlls can be side by
side, so you can install them into your application folder. Visual
Studio 2005 support Dlls are SxS in the WinSxS folder - they're
installed differently. Was MFC71 a typo? That's the Visual Studio 2003
MFC support, but elsewher
Hi All,
I've moved on from my earlier problems with Vista to new exciting
problems! Since moving a custom action for launching IE out of the UI
sequence the installer is now not elevating privileges under Vista at
all during install (but does so during uninstall).
So I created a batch file to
Having this error message when adding the -bf switch to the lit command, no
such file name is included in my project any guess? Needless to mention that
project is succeeding to built when removing the -bf switch.
Command line is:
C:\Program Files\Windows Installer XML v3\bin\lit.exe -out
C:
I think I have found it, I'm not sure of a nice way to work around it
though. I've copied some code that launches IE after an install (this is
an IE only install, so no problem there) but it runs in the context of
the UI. I'm led to believe that this is where I'm mucking things up. You
can see
Hi,
I'm installing MFC71, CRT and STL merge modules together with my product. The
problem I'm having is Windows Installer asks me to reboot at the end of the
installation in case of a repair since some of those modules are held in use by
Windows Explorer. At the installation, I don't have this
Not really. I also agree with the notion that Per-User installs are evil.
It's just such a royal pain to manage ( See Windows Installer Tao Rule #30 ).
When I used to do SMS pushes in an enterprise environment, I'd never consider a
per-user advertisement. All of my packages were hardwired P
hmm, thats bad :(Any good or bad hacks coming to anyone's minds. Any thing
??
..ab
On Nov 27, 2007 12:06 PM, Kelly Leahy <[EMAIL PROTECTED]> wrote:
>
> Nope... As far as I know, NOTHING will work in that scenario. AFAIK,
> there's no way to handle this properly - you pretty much want to requir
You could be right. The DLL could be doing something daft. I thought I
tallowed out all the registration. I'll check again.
Rob Hamflett wrote:
> If you're doing things via normal MSI methods (which you are, assuming the
> values are correct) and
> specifying [EMAIL PROTECTED]"elevated" (are yo
If you're doing things via normal MSI methods (which you are, assuming the
values are correct) and
specifying [EMAIL PROTECTED]"elevated" (are you?), then I'm out of ideas, sorry.
Aha, hold on. When you run from the elevated command prompt, the entire
installation runs elevated.
This means
> Just as a side note, cygwin and sed (what you seem to be
> using) are both licensed under GPL license hence you are
> required to provide source code access to all customers using
> the software (installer is also software), including any
> modifications. Furthermore, the installer would need
Hi,
When I apply dark.exe for an existing MSI, am getting following error.
Can any one tell me how to resolve this
C:\Documents and Settings\sai_teja\Desktop\wix-3.0.2925.0-binarieszip>dark.e
xe "Control Client.msi" Control Client.wxs
Microsoft (R) Windows Installer Xml Decompiler Version 3.0.
The registration of the DLL is handled via RegistryValue elements
wrapped inside Component elements which are then inside three levels of
Directory elements (snippet below). So no custom actions involved for
the registry, I kind of got the impression they were not good. I do have
one however, t
That article is missing a few important bits, as far as my understanding goes.
An installer written
for Vista should be marked as needing elevation, or not needing elevation. If
it does, you get
prompted when the installer switches over to the server side, which does the
actual work. Micros
Been looking into this some more. I've asked the customer to log before
and after (nothing yet) but in the meantime they found this article on
how to elevate privileges for an MSI (
http://footheory.com/blogs/shane/archive/2007/08/03/vista-and-elevating-security-of-an-msi-to-run-as-administrator
28 matches
Mail list logo
