[WiX-users] SelectionTree and Features: how to hide menu item InstallAll?

2007-03-30 Thread Igor Lemsky

We have SelectionTree in Windows installer and list of all not-hidden
features there.
To add feature to install I must Click on icon left to feature name and
choose from drop-down menu Install Local (Will be installed on local drive)
option.
To remove it from installation I must choose option Entire feature will be
unavailable. But we have one more menu item - Entire feature will be
installed on local drive, which mark all sub features to Install.
But I haven't sub features and is there way to hide this menu item? I dont
want to confuse user, I already make AllowAdvertise = no and disallow
network installation.
May be there are ways to hide first menu item and leave Entire feature...
alone with ... unavailable?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] determine installation directory based on a condition

2007-03-30 Thread Patrick Schmid
Is it possible to determine the installation directory based on a condition?
For example, if the OS is XP, install in Program Files. If the OS is Vista,
install somewhere else?

Thanks,

Patrick Schmid


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Conditional Install of the Office 2003 PIAs

2007-03-30 Thread Chris Bardon
I might just try that, but there could be a problem with that.  First,
what would the consequence be of installing the PIAs on a system without
Office 2003 on it?  Would it just add extra files to the GAC and be done
with it?  Also, what about admin rights?  If my installer doesn't
require administrative rights, but the PIA one does, I don't think I'd
even be able to offer the option of a non-administrative install for the
non-office components.  Finaly, it looks like I'll have to support 2007
as well, which means installing both the 2003 and 2007 PIAs, which seems
to be kind of a waste.  
 
I'm not saying that including the MSI in the bootstrapper is impossible,
just that it seems like there'd be a more elegant solution to the
problem.  



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wilson,
Phil
Sent: Thursday, March 29, 2007 2:15 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Conditional Install of the Office 2003 PIAs


I don't think it's worth the added complication. Just install the PIAs
in the bootstrapper. 

Phil Wilson 

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Bardon
Sent: Thursday, March 29, 2007 10:48 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditional Install of the Office 2003 PIAs


I have an installer for a product with an optional Office 2003 Addin
that requires the Office 2003 PIAs, and I'm trying to figure out how I
can install the assemblies only if the component is selected in the
feature tree.  A bootstrapper will launch the PIA MSI beforehand,
wouldn't it?  
 
I'm currently taking a look at the CC addin that Rob blogged about here
http://blogs.msdn.com/robmen/archive/2006/06/20/641202.aspx , but I have
a feeling that this is going to install the PIAs, then run the addin
setup.  
 
Is there an MSM for the PIAs that I could use instead?  That way, the
module could be a component of the optional feature.  As an alternative,
I'm thinking about checking the registry to see which Office
applications are installed.  Another possibility would be to run a
custom action to actually shell out and run msiexec on the included
package, but that seems a little messy for the end user (although I
suppose it could run silently).  
 
Any suggestions on how to do this?  
 
Thanks,
 
Chris
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] upgrade nightmare

2007-03-30 Thread Chris Bardon
I'm guessing you want to avoid passing the REINSTALLMODE to the
bootstrapper, correct?  My solution to the same problem (thanks to the
help of others on this list) was to use * as the product code, and
define every upgrade to be a major one.  There is a way to distribute a
bootstrapper with automated command line, but the problem with setting
the REINSTALL flag all the time on an existing install is that on a
clean install, nothing will happen.  If you want to go that route
though, check out 7zip, and create an SFX with the optional installer
components.  This will make a self-extracting zip file that auto
extracts, runs an exe with your parameters, and then deletes the temp
files.  

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adriaan
Sent: Friday, March 30, 2007 2:52 AM
To: Some user; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] upgrade nightmare

You should change the ProductCode as well. 

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Some 
 user
 Sent: 30 March 2007 07:40 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] upgrade nightmare
 
 
 the problem is that requiring commandline parameters or bootstrapper 
 is unacceptable for us, we have seen that our users are too stupid to 
 type a commandline (!?)
 
 so I have been told toto make a thing that can do installs and updates

 on the same package without requiring any commandline parameters or 
 bootstrapper.the only way I have worked out so far is to have a fixed 
 package ID.  The problem is that whenever I update installer nothing 
 will be updated, as it will run the MSI from the cached version!
 --
 View this message in context: 
 http://www.nabble.com/upgrade-nightmare-tf2271831.html#a9747562
 Sent from the wix-users mailing list archive at Nabble.com.
 
 
 --
 ---
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the 
 chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforge
CID=DEVDEV
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] install uninstall run conditions

2007-03-30 Thread Chris Bardon
Try setting the condition to NOT INSTALLED 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Some user
Sent: Friday, March 30, 2007 12:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] install uninstall run conditions


I have an MSI where I need to run some programs after the installation.
I have put in some custom actions to run the items and they seem to work
fine.
however I don't want to run these files when it is uninstalled, because
obviously the files won't be there anymore and it will give an error
message.

so I put a condition InstallMode  Remove into the action. to
remove button in the uninstall dialogue has a published event which sets
the InstallMode to Remove. however I am finding that the actions are
still executing causing a fatal error in the uninstaller
--
View this message in context:
http://www.nabble.com/install-uninstall-run-conditions-tf3490210.html#a9
747189
Sent from the wix-users mailing list archive at Nabble.com.



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Conditional RemoveFiles on Uninstall

2007-03-30 Thread Chris.Rowland
I'm trying to do the same thing, but when check the checkbox to remove
the Installation directory, it's not deleting the directory, or the 2
files that are left behind.

I cant imagine you have to explicitly remove files before removing the
directory, do you?


I have a hidden feature to enable my removal component as follows:


Component Id=Comp_RemoveAllFiles Guid=
ConditionRemoveAllFiles/Condition
RemoveFolder Id=RemoveRootFolder On=uninstall
Property=[INSTALLDIR]/
/Component

FeatureId=Feat_RemoveAllFiles Display='hidden' Level=1
ComponentRef Id=Comp_RemoveAllFiles/
/Feature



In the log I see
Property(C): RemoveAllFiles = TRUE

I also see this, but im not sure if its of any use...

UnpublishFeatures: Feature: Feat_RemoveAllFiles



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gareth at
Serif
Sent: Thursday, March 29, 2007 1:09 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Conditional RemoveFiles on Uninstall


You can probably declare your 'RemoveFile' ines in a component that has
a
component condition triggered by a property that your user can configure
via
a checkbox in your UI.  I believe that 'RemoveFile' lines work on
install
and all files will be removed on uninstall so probably won't be the
solution
for your described needs.

Best of luck.
-- 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] COM Registration of .Net assembly in v2

2007-03-30 Thread Timothy Meese
Hello, 

 

We tried v3, but ran into trouble with some 3rd party merge modules that are 
needed for our application. 

 

What I am running up against now is that the actions (or registry entries) 
produced by tallow -c on a .NET assembly don't exactly equal the same thing as 
regasm'ing the assembly. I've tried self-registration, but that doesn't work, 
and isn't recommended anyhow. Running regasm from the installer seems like a 
bad idea as well. What is the official method of COM registering a .NET 
assembly in WiX v2 or v3? 

 

Thanks,

Tim

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Conditional Install of the Office 2003 PIAs

2007-03-30 Thread Wilson, Phil
Having a bootstrapper run by an administrator before installing the MSI
is a normal way to separate required privilege so that your MSI can
potentially not require administrator privilege although prerequisites
typically do. Embedding the install of the PIAs as part of a feature
makes this impossible. There's also the Modify situation, the notion
that you'll add (and remove?) prerequisites on the fly depending on
feature state isn't really elegant. Also, I don't think the PIAs will
install without Office already being installed  - I'd test that scenario
- there's a launch condition in the embedded MSI. Also they may be there
already (there's an Office 2003 installation choice that will install
them) but I'd just trust the redist to do the right thing.You might
also be interested in this as a prerequisite also: 
 
http://support.microsoft.com/kb/908002 

Phil Wilson 

 



From: Chris Bardon [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 30, 2007 5:37 AM
To: Wilson, Phil; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Conditional Install of the Office 2003 PIAs


I might just try that, but there could be a problem with that.  First,
what would the consequence be of installing the PIAs on a system without
Office 2003 on it?  Would it just add extra files to the GAC and be done
with it?  Also, what about admin rights?  If my installer doesn't
require administrative rights, but the PIA one does, I don't think I'd
even be able to offer the option of a non-administrative install for the
non-office components.  Finaly, it looks like I'll have to support 2007
as well, which means installing both the 2003 and 2007 PIAs, which seems
to be kind of a waste.  
 
I'm not saying that including the MSI in the bootstrapper is impossible,
just that it seems like there'd be a more elegant solution to the
problem.  



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wilson,
Phil
Sent: Thursday, March 29, 2007 2:15 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Conditional Install of the Office 2003 PIAs


I don't think it's worth the added complication. Just install the PIAs
in the bootstrapper. 

Phil Wilson 

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Bardon
Sent: Thursday, March 29, 2007 10:48 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditional Install of the Office 2003 PIAs


I have an installer for a product with an optional Office 2003 Addin
that requires the Office 2003 PIAs, and I'm trying to figure out how I
can install the assemblies only if the component is selected in the
feature tree.  A bootstrapper will launch the PIA MSI beforehand,
wouldn't it?  
 
I'm currently taking a look at the CC addin that Rob blogged about here
http://blogs.msdn.com/robmen/archive/2006/06/20/641202.aspx , but I have
a feeling that this is going to install the PIAs, then run the addin
setup.  
 
Is there an MSM for the PIAs that I could use instead?  That way, the
module could be a component of the optional feature.  As an alternative,
I'm thinking about checking the registry to see which Office
applications are installed.  Another possibility would be to run a
custom action to actually shell out and run msiexec on the included
package, but that seems a little messy for the end user (although I
suppose it could run silently).  
 
Any suggestions on how to do this?  
 
Thanks,
 
Chris
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] problem when run custom action before costinitialize

2007-03-30 Thread Wilson, Phil
...and the point of that Wait=Yes is that it translates to Wait=1 in
the ServiceControl table so that it does really wait for the Service to
finish, not just for the SCM to respond.  
 

Phil Wilson 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Vottero
Sent: Thursday, March 29, 2007 7:32 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] problem when run custom action before
costinitialize



You could have a race condition (we did).  I don't know if it's Windows
Installer or a WiX Custom Action that stops services but, it appears
that it continues when the service controller reports that the service
is stopped.  The service controller reports a service as stopped when
the service successfully responds to a stop request (i.e. a ServiceBase
based class' OnStop method completes successfully). But, the files are
in-use until the process exits.  If your OnStop method just starts the
shutdown and then returns, you have a problem.  Your OnStop method
should start the shutdown of the service threads and then wait for them
to complete before it exits. 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bei Liu
(Volt)
Sent: Thursday, March 29, 2007 5:54 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] problem when run custom action before
costinitialize

 

I did that, 

 

Component...

File ... Name=MyService.exe 

/File

 

ServiceControl Id=MyService Name=MyService.exe Stop=uninstall
Remove=uninstall Wait=yes

  ServiceArgument /d [INSTALLDIR]EF.G/ServiceArgument

/ServiceControl

/Component

 

I still get file-in-use popup when uninstall.(Stop service is happened
after CostFinilize, InstallValidate)

 

 

From: Rob Mensching 
Sent: Thursday, March 29, 2007 2:41 PM
To: Bei Liu (Volt); wix-users@lists.sourceforge.net
Subject: RE: problem when run custom action before costinitialize

 

You should be able to just schedule the service to be stopped and no
file-in-use error should occur.

 

From: Bei Liu (Volt) 
Sent: Thursday, March 29, 2007 2:11 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: problem when run custom action before costinitialize

 

I have a service installed by my installer.  I'll run after install. I
want to remove it before uninstall. Also don't want to get the file in
use popup.

 

From: Rob Mensching 
Sent: Thursday, March 29, 2007 2:09 PM
To: Bei Liu (Volt); wix-users@lists.sourceforge.net
Subject: RE: problem when run custom action before costinitialize

 

Why?  What are you trying to do?

 

From: Bei Liu (Volt) 
Sent: Thursday, March 29, 2007 1:30 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: problem when run custom action before costinitialize

 

2. I just want to run it when uninstall. Is that possible?

 

Thanks,

 

 

 

From: Rob Mensching 
Sent: Thursday, March 29, 2007 1:25 PM
To: Bei Liu (Volt); wix-users@lists.sourceforge.net
Subject: RE: problem when run custom action before costinitialize

 

1.  Not as far as I know.

 

2.  That doesn't make any sense to me.  CostInitialize happens long
before the transaction that installs things happens.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bei Liu
(Volt)
Sent: Thursday, March 29, 2007 1:12 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] problem when run custom action before
costinitialize

 

Can I schedule a custom action that using the directory manager before
costinitialize?

 

If not, is there a way to run an application that installed by the msi
before costinitialize?

 

Thanks,



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] How To Do Tutorial Step 2.5 Insertions in Wix3 Quickly

2007-03-30 Thread ScottStout

I want to make a minor change to the WixUI_Mondo and rebuild it.  Is there a
way to do this quickly as shown in the tutorial (Step 2.5 Insertions)   The
tutorial simply does:

candle.exe myWixUI_Mondo.wxs UserRegistrationDialog.wxs BrowseDialog.wxs
etc.wxs
lit.exe -out MyWixUI_Mondo.wixlib MyWixUI_Mondo.wixobj
UserRegistrationDialog.wixobj BrowseDialog.wixobj etc.wixobj

I am just trying to get the candle line to work at this point, and it seems
there are now a lot of variables that need to be set.  At this point I'm not
familiar enough with the system at this point to decipher all of these.  

I saw that one level up there is a UIExtension.build file.  I tried building
this in NANT, ad it ends up having a some dependencies.  

I tried just stripping the candle portion out of this file and running that. 
It was still asking for some variables to be set.

Is there a quick way to build this without having to be set up to buid the
entire Wix application?   I prefer not to have to install the IIS SDK, the
VSPI SDK, etc just for this quick change to the UI.
-- 
View this message in context: 
http://www.nabble.com/How-To-Do-Tutorial-Step-2.5-Insertions-in-Wix3-Quickly-tf3493367.html#a9756807
Sent from the wix-users mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] problem when run custom action before costinitialize

2007-03-30 Thread John Vottero
Wait=Yes means wait up to 30 seconds for the service to enter a
STOPPED state rather than a STOP_PENDING state.  In our case, our
service would report STOPPED very quickly but, the process would still
be running up to 90 seconds later because it was waiting for an I/O to
complete that would never complete.

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] On Behalf Of Wilson, Phil
 Sent: Friday, March 30, 2007 12:42 PM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] problem when run custom action before
 costinitialize
 
 ...and the point of that Wait=Yes is that it translates to Wait=1 in
 the ServiceControl table so that it does really wait for the Service
to
 finish, not just for the SCM to respond.
 
 
 Phil Wilson
 
  
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of John
 Vottero
 Sent: Thursday, March 29, 2007 7:32 PM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] problem when run custom action before
 costinitialize
 
 
 
 You could have a race condition (we did).  I don't know if it's
Windows
 Installer or a WiX Custom Action that stops services but, it appears
 that it continues when the service controller reports that the service
 is stopped.  The service controller reports a service as stopped when
 the service successfully responds to a stop request (i.e. a
ServiceBase
 based class' OnStop method completes successfully). But, the files are
 in-use until the process exits.  If your OnStop method just starts the
 shutdown and then returns, you have a problem.  Your OnStop method
 should start the shutdown of the service threads and then wait for
them
 to complete before it exits.
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Bei Liu
 (Volt)
 Sent: Thursday, March 29, 2007 5:54 PM
 To: Rob Mensching; wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] problem when run custom action before
 costinitialize
 
 
 
 I did that,
 
 
 
 Component...
 
 File ... Name=MyService.exe 
 
 /File
 
 
 
 ServiceControl Id=MyService Name=MyService.exe Stop=uninstall
 Remove=uninstall Wait=yes
 
   ServiceArgument /d
[INSTALLDIR]EF.G/ServiceArgument
 
 /ServiceControl
 
 /Component
 
 
 
 I still get file-in-use popup when uninstall.(Stop service is
 happened
 after CostFinilize, InstallValidate)
 
 
 
 
 
 From: Rob Mensching
 Sent: Thursday, March 29, 2007 2:41 PM
 To: Bei Liu (Volt); wix-users@lists.sourceforge.net
 Subject: RE: problem when run custom action before costinitialize
 
 
 
 You should be able to just schedule the service to be stopped and no
 file-in-use error should occur.
 
 
 
 From: Bei Liu (Volt)
 Sent: Thursday, March 29, 2007 2:11 PM
 To: Rob Mensching; wix-users@lists.sourceforge.net
 Subject: RE: problem when run custom action before costinitialize
 
 
 
 I have a service installed by my installer.  I'll run after install. I
 want to remove it before uninstall. Also don't want to get the file
in
 use popup.
 
 
 
 From: Rob Mensching
 Sent: Thursday, March 29, 2007 2:09 PM
 To: Bei Liu (Volt); wix-users@lists.sourceforge.net
 Subject: RE: problem when run custom action before costinitialize
 
 
 
 Why?  What are you trying to do?
 
 
 
 From: Bei Liu (Volt)
 Sent: Thursday, March 29, 2007 1:30 PM
 To: Rob Mensching; wix-users@lists.sourceforge.net
 Subject: RE: problem when run custom action before costinitialize
 
 
 
 2. I just want to run it when uninstall. Is that possible?
 
 
 
 Thanks,
 
 
 
 
 
 
 
 From: Rob Mensching
 Sent: Thursday, March 29, 2007 1:25 PM
 To: Bei Liu (Volt); wix-users@lists.sourceforge.net
 Subject: RE: problem when run custom action before costinitialize
 
 
 
 1.  Not as far as I know.
 
 
 
 2.  That doesn't make any sense to me.  CostInitialize happens long
 before the transaction that installs things happens.
 
 
 
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Bei Liu
 (Volt)
 Sent: Thursday, March 29, 2007 1:12 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] problem when run custom action before
 costinitialize
 
 
 
 Can I schedule a custom action that using the directory manager before
 costinitialize?
 
 
 
 If not, is there a way to run an application that installed by the msi
 before costinitialize?
 
 
 
 Thanks,
 
 
 

---
 --
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
share
 your
 opinions on IT  business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVD
 EV
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


-
Take Surveys. Earn Cash. Influence the Future of IT

Re: [WiX-users] Patching fails with 1627

2007-03-30 Thread Huck, Jacob
In case someone was looking at a similar issue:  basically we have
multiple cab files in a debug install (to contain the pdbs, which exceed
2GB in many cases).  When generating the patch, I was leaving
MediaDiskId blank, but in needed to be set to a value greater than the
highest Media Id in the msi's.
 
Thanks
-jh



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Huck,
Jacob
Sent: Sunday, February 25, 2007 11:03 PM
To: Bob Arnson; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching fails with 1627


Sounded promising, but unless I did it incorrectly, it didn't work--I'm
still getting the same error.
 
How were you able to determine it was a schema issue (and then
specifically that column)?  I'd love to think I could apply the same
logic to my issue.
 
Thanks
-jh



From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Sunday, February 25, 2007 1:38 PM
To: Huck, Jacob
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching fails with 1627


Huck, Jacob wrote: 

  ERROR: Failed to execute a view
  ERROR:The Last Error Received is: 1627
  ERROR:The Last Error Received is: 1: 2259 2:
c:\temp\~pcw_tmp.tmp\3000.MSI 3:  4:


I've gotten that before when I was use a File/Sequence column of I4; by
default, Patchwiz supplies a Patch/Sequence column of I2 so you need to
use the MsiFileToUseToCreatePatchTables option to specify an I4 column.

-- 
sig://boB
http://bobs.org
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] multiple cultures and codepage error

2007-03-30 Thread Huck, Jacob
We've broken our build into numerous WiX fragments which in turn compile
into numerous wix libs.  All wixlibs contain english strings at a
minimum and a few (namely the Dialog wixlibs) contain muliple languages
under different cultures and codepages.  
 
For example, our common_dialogs.wixlib might contain the following
 
One .wxl file contains:
WixLocalization Culture=ja Codepage=932
xmlns=http://schemas.microsoft.com/wix/2003/11/localization
http://schemas.microsoft.com/wix/2003/11/localization 
...
 
Another
WixLocalization Culture=en-us Codepage=1252
xmlns=http://schemas.microsoft.com/wix/2003/11/localization
http://schemas.microsoft.com/wix/2003/11/localization 
...
 
and so on.  All are passed into lit.exe at the same time, which compiles
with an issue.
 
When I go to light an msi using the above wixlib and numerous other
wixlibs that are not localized, I find that when I pass in
-cultures:en-us the msi compiles without any issues, but as soon as I
pass in -cultures:ja;en-us, I get the following error:
 
light.exe : error LGHT0101 : The codepage '1252' has been specified in
multiple localization files.  Please resolve the conflict.
 
Any insight into this error?  When I compiled it with just en-us, it
clearly was using codepage 1252 in multiple loc files.  My understanding
was that the multiple entries passed into the -culture arg were to
indicate an order of use ja strings first if found, and en-us strings
if not.  
 
Thanks
-jh
 
 
 
 
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] COMPlus in Wix V3

2007-03-30 Thread Krishna Vaishnav

Hello

I do not see ComPlus in Wix V3 bits. When is it going to be available?

Thanks
-Krishna
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Disk costing, directory deleting

2007-03-30 Thread Jason Van Eaton
I need to accomplish 2 tasks and I am not seeing any obvious solutions (using 
3.0.2420.0).

1.  I am creating a source code install.  I would like to prevent users 
from installing on drives that that do not have enough room to build the source 
code.  So although the source itself only consumes 220MB, I would like to 
reserve 2GB.  Is that possible?
2.  When uninstalling, I would like to provide an option to delete the 
INSTALLDIR in its entirety (whether empty or not).  How should I accomplish 
that?

Thanks for your help.

JVE




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Default values to a control

2007-03-30 Thread rkevinburton
I am relatively new to Wix. I am trying to build a dialog and I would like 
there to be a default value for the text entered and I would like to have text 
for a password field masked. I am sure this can be done I just don't know how 
right now.

Kevin

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How To Do Tutorial Step 2.5 Insertions in Wix3 Quickly

2007-03-30 Thread ScottStout

This provides a quicker way to accomplish what I was trying to accomplish:

http://www.nabble.com/CNDL0150-Error-for-Custom-Dialog-tf2871087.html#a8024749
-- 
View this message in context: 
http://www.nabble.com/How-To-Do-Tutorial-Step-2.5-Insertions-in-Wix3-Quickly-tf3493367.html#a9760750
Sent from the wix-users mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Disk costing, directory deleting

2007-03-30 Thread Rob Mensching
1.  ReserveCost element.

2.  If you describe all of the files in the MSI, then MSI will clean up 
properly.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Van Eaton
Sent: Friday, March 30, 2007 1:21 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Disk costing, directory deleting

I need to accomplish 2 tasks and I am not seeing any obvious solutions (using 
3.0.2420.0).

1.  I am creating a source code install.  I would like to prevent users 
from installing on drives that that do not have enough room to build the source 
code.  So although the source itself only consumes 220MB, I would like to 
reserve 2GB.  Is that possible?
2.  When uninstalling, I would like to provide an option to delete the 
INSTALLDIR in its entirety (whether empty or not).  How should I accomplish 
that?

Thanks for your help.

JVE




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] CA with elevated privileges under Vista!

2007-03-30 Thread Chuck
I have the following situation:

I am creating an MSI in which I need to run a CA early in the 
installation process, the DA is in a C dll. The CA Requires Admin 
access under Vista.  I am wrapping the msi in a setup.exe boot strapper 
that has a manifest with requestedExecutionLevel 
level=requireAdministrator. In my WIX project I have a condition for 
AdminUser and in the package I have InstallPrivileges set to elevated. 
The dll has requireAdministrator in its manifest.

The problem that I'm having is that the code that I'm executing in my CA 
fails to execute correctly.  I extracted the code and compiled it into 
an exe with the same manifest as above.  When I run the exe the code 
completes correctly!

In both cases I am getting prompted for an Admin password...which would 
lead one to think that the installer is running as an Admin user...but 
the CA fails.

Any thoughts on this would be greatly appreciated.

Thanx
Chuck

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] CA with elevated privileges under Vista!

2007-03-30 Thread Wilson, Phil
A couple or four things: 

1) Does early in the installation process mean in the UI sequence? 

2) Manifests target executables, not Dlls - they run with the level of
the exe that loads them. 

3) If the setup.exe isn't asking for elevation via Cancel/Allow but is
asking for an admin account, then it means you're not an administrator
but you need to be. Someone has to provide admin credentials, either you
elevated to admin or somebody over the shoulder on your behalf. 

4) AdminUser is unreliable under Vista.  
 
http://blogs.msdn.com/rflaming/archive/2006/09/21/uac-in-msi-notes-the-a
dminuser-mistake.aspx  

Phil Wilson 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chuck
Sent: Friday, March 30, 2007 4:12 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CA with elevated privileges under Vista!

I have the following situation:

I am creating an MSI in which I need to run a CA early in the
installation process, the DA is in a C dll. The CA Requires Admin
access under Vista.  I am wrapping the msi in a setup.exe boot strapper
that has a manifest with requestedExecutionLevel
level=requireAdministrator. In my WIX project I have a condition for
AdminUser and in the package I have InstallPrivileges set to elevated. 
The dll has requireAdministrator in its manifest.

The problem that I'm having is that the code that I'm executing in my CA
fails to execute correctly.  I extracted the code and compiled it into
an exe with the same manifest as above.  When I run the exe the code
completes correctly!

In both cases I am getting prompted for an Admin password...which would
lead one to think that the installer is running as an Admin user...but
the CA fails.

Any thoughts on this would be greatly appreciated.

Thanx
Chuck


-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Use sca to create database,does it require mdac.

2007-03-30 Thread 姚春林

Hello

How the wix connect to sqlserver ?
If it use the mdac, when client haven't installed it install will Fatal.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Disk costing, directory deleting

2007-03-30 Thread Jason Van Eaton
1.  Thanks.

2.  I am not going to describe all of the objs, generated headers, binaries, 
pdbs, etc.  I am just looking for a way to nuke the directory and tie that into 
a user option in the UI.

JVE

-Original Message-
From: Rob Mensching
Sent: Friday, March 30, 2007 3:10 PM
To: Jason Van Eaton; wix-users@lists.sourceforge.net
Subject: RE: Disk costing, directory deleting

1.  ReserveCost element.

2.  If you describe all of the files in the MSI, then MSI will clean up 
properly.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Van Eaton
Sent: Friday, March 30, 2007 1:21 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Disk costing, directory deleting

I need to accomplish 2 tasks and I am not seeing any obvious solutions (using 
3.0.2420.0).

1.  I am creating a source code install.  I would like to prevent users 
from installing on drives that that do not have enough room to build the source 
code.  So although the source itself only consumes 220MB, I would like to 
reserve 2GB.  Is that possible?
2.  When uninstalling, I would like to provide an option to delete the 
INSTALLDIR in its entirety (whether empty or not).  How should I accomplish 
that?

Thanks for your help.

JVE




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users