Hi,
I have three VB6 components in a VB6 project I want to install and register.
Two are ocx's and one is a dll. I see in the SDK Docs there is a -svb6 option
for Harvest which I think I need to use. Is this right?
I am actually using MSBUILD and the Harvestfile element. There doesn't seem to
This makes me both happy and sad. I rebooted the server and it installed
successfully. Wonderful, it installed. So, do I just document the scenario
and move on? Pbbt. BTW, I answered my own question below. Yes, 'SYSTEM' is
the same as 'LocalSystem'.
Thanks for your concern, especially Car
Thanks for the reply. Is 'SYSTEM' the same as 'LocalSystem'? If so, it is
already there.
The list is Administrator, ASPNET, NETWORK SERVICE and SYSTEM along with a
couple GUIDs and SqlServer agents.
Joel D. Palmer | Data Integration Engineer
T +1 952-975-1544 | M +1 612-396-3087
-Origin
Try This: (I know it's not VmWare)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023265
Quoting "Palmer, Joel" :
> * I use WiX 3.8 to create an installer for my Windows
> Service. When it is run on my Server 2003 test box, I get this ve
* I use WiX 3.8 to create an installer for my Windows Service. When it
is run on my Server 2003 test box, I get this very unhelpful and generic
message:
"Verify that you have sufficient privileges to install system services."
I am logged in to an Admin account when I run the installer.
Preferred solution is to harvest the registration info from the DLL's using
heat.exe (see 'file' harvest type) at installer build time.
Tony Jose Mampilly wrote
> Hi,
>
> For one of our application after installation, 4 dlls are needed to be
> registered using REGASM.exe. Earlier when we were bu
Also look into Package/InstallScope, which might be more appropriate.
Gerry Reno wrote
> It looks like adding this to Package may do the trick:
>
> |InstallPrivileges="elevated"|
>
> I'll try it and see.
>
>
> On 01/21/2014 08:21 PM, Gerry Reno wrote:
>> I have a WIX installer built that inst
Classification: Public
Sigh... thanks Carter!
Just learning on how to read properly!!
Steve
-Original Message-
From: Carter Young [mailto:ecyo...@grandecom.net]
Sent: January-22-14 5:59 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Confused... when installing a 32/64 bi
Read my First Reply:
$(sys.BUILDARCH) should be used when determining Build time Components
on the DEVELOPER MACHINE
$(var.Platform) should be used to determine the TARGET MACHINE'S
bitness. Your having a tough time here because $(sys.BUILDARCH) is
always equal to $(var.Platform) on the DE
Classification: Public
Yes it was a pain in the a$$ to maintain two product.wxs files for the same
project. Blending them to one file has made work so much easier.
I have the configuration set in the wix project file to handle whether it is an
x86 debug/release or x64 debug/release build.
The is
The link provided by eyoung100 was helpful to me in packaging some printer
drivers, using a single MSI project with different build configurations to
produce x86 and x64 packages. The bundle then includes both packages and
installs the one which is appropriate for the architecture of the target
sy
See Here:
http://stackoverflow.com/questions/18628790/build-wix-3-6-project-targeting-x64
Regarding Files below: Build Arch is used in the Development
environment to override the Build Setting in VS. Platform is the one
you'd use when creating the install condition, as that is the platform
Hello,
I use 1 product.wxs file at build time, the project file has different
configurations for X86 and X64 which allows me build 2 MSI's one for 32 bit
and one for 64 bit.
I have used these conditions but which one is correct?
OR
Is there a way using 'MajorUpgrade' to prompt the user with a message
(either in the installer window or via a pop-up window) that running this
installer will remove previous versions of this product and let the user
select to either cancel or continue?
Brian
If you can't explain it simply, you
I am still learning this stuff myself, so I may misunderstand the problem,
but in your MBA, typically in PlanComplete you would have code which calls
this.root.PreApplyState = this.root.State;
this.root.State = InstallationState.Applying;
myMmbaClass.Model.Engine.Ap
15 matches
Mail list logo