[WiX-users] WixVSExtension and VSTF2005_SP_LEVEL

2008-08-08 Thread William Bartholomew
I have two questions about WixVSExtension:

 

1.   Can you use VSTF2005_SP_LEVEL as a Boolean variable to
determine if Team Foundation Client 2005 is installed at all, regardless
of its service pack level?

2.   Is there an equivalent to determine if Team Foundation Client
2008 is installed? I can't find one in the documentation.

 

Thanks,

William

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Installing Visual Studio Add-ins and ICE64 Validation Errors

2008-08-08 Thread William Bartholomew
I'm writing an installer for a Visual Studio add-in which requires me to
place a file in %USERPROFILE%\Visual Studio 2005\Addins or
%USERPROFILE%\Visual Studio 2008\Addins depending on the Visual Studio
version I'm installing for. If this directory doesn't exist, it should
be created, but on uninstallation of my package I probably shouldn't
remove it (because other add-ins may have been installed after mine).

 

So far I've used the following WiX markup:

 



  



  



  

  





  

  





  

  



  



  



 

The problem is that I get an ICE64 validation error (The directory
VS2008LOCATION/VS2008ADDINSLOCATION is in the user profile but is not
listed in the RemoveFile table). After doing some searching the common
solution to this problem is to add a RemoveFolder element, however, I'm
not sure this is the correct thing to do in this instance because my
installer does not "own" those directories.

 

Is there a better way around the ICE64 validation error? Is there a
better way for me to determine the location of the VS 2005/2008 Addins
directories?

 

 

Thanks,

William Bartholomew

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] HOWTO:avoid changing the Registry when patching

2008-08-08 Thread John Nannenga
I believe REINSTALLMODE comes into play here.
 Ref:   http://msdn.microsoft.com/en-us/library/aa371182(VS.85).aspx

So, in your first post, you had a non-transitive component installing a 
registry key conditioned on NOT PATCH.  Assuming your installation wasn't 
slipstreaming (applying a patch during initial installation), this condition 
evaluated to TRUE and your component and related registry items were written.  
During subsequent maintenance operations (patching and repairing), 
non-transitive component conditions are not re-evaluated.  During your patch 
application, I suspect the REINSTALLMODE property included "u" and or "m" which 
according to the WI SDK, rewrites all required registry entries (to Current 
User / Local Machine).  Since the component is "installed" that has your 
registry keys [in question] defined, this would cause your registry keys to be 
rewritten.

As a general note, instead of doing something like this:
NOT PATCH
... you'd want to favor setting the appropriate REINSTALLMODE settings.


And in general, you want to sparingly make use of the "PATCH" property for 
conditioning; as major headaches would be encountered within your install 
should one want to slipstream it, someday.







From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tony Juricic [EMAIL 
PROTECTED]
Sent: Friday, August 08, 2008 5:56 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] HOWTO:avoid changing the Registry when patching

I tried adding Transitive attribute to the registry component and that
deleted the component when patch was applied. Thus 'NOT PATCH' is a
correct condition since transitive components are removed when condition
changes from true to false.

However, for some reason that I would really love explained, this
condition is not evaluated to decide whether to install a component when
patching.

There is very useful ProtectFile element, child of UpgradeImage element
that does the job for the files but apparently there is nothing similar
for Registry keys and values?

Seriously?

If I can find any entertainment value in this, it is in somewhat
reminding me of the good ole' days of emailing people at Microsoft,
voicing annoyance at having to code OpenFile dialog box again and asking
for a standard implementation to be the part of the OS. :O

Anyhow, a kind of fix for the problem is to put condition on the action:

NOT PATCH

but this doesn't make me too happy because it affects all registry
components.

Any other ideas?


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Excluding registry entries from patching

2008-08-08 Thread Tony Juricic
You can always use custom action to write that part of the Registry.

However that would not be politically correct. I mean, using CA when MSI 
database solution is available. Unfortunately sometimes it appears as if MSI 
people do everything they can to force us to use CAs even in cases which look 
relatively easy to cover in MSI.

On WiX side new WiX patching should be able to cover this scenario if it works 
as advertised - it allows you to select the set of components affected by 
patching. Just exclude your Registry component and you're done. 

Again unfortunately new patching has issues of its own like:
- binary delta patching doesn't work in some cases
- nobody seems to know how is file sequencing handled, which is pretty 
important if you have a lot of files that may change and may release more than 
one patch
- nobody seems to know if it is possible to have multiple targets

Plus it is possible that new patching excluding a specific registry component 
still doesn't work since this looks like the installer service problem, rather 
than something specific for WiX


-Original Message-
From: Athay, David [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 08, 2008 5:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Excluding registry entries from patching

I have a problem where I am specifying a registry entry in a component that
writes out the INSTALLDIR property to the registry.  My problem is that
patches to this MSI always reset the INSTALLDIR to the default value (the
Windows Installer default is C:\Program Files)

I need to either A) find a way of excluding that part of my install from
patching, or B) find a way to make sure that the MSP always sets INSTALLDIR
to what the original installation directory was before it processes the
patch so that the registry will still be valid after patching.

Any suggestions?

--
David Athay | CE Up & Running Team | Intuit, Inc. | Work: (858) 215-7149 | 




-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Excluding registry entries from patching

2008-08-08 Thread John Nannenga
You've got a ton of options available to you; since I don't know the details of 
your installation, I'll try to give you a couple options (pick one [or 
something similar, or perhaps a hybrid] that makes the most sense for your 
situation).  If none of the below work for you, holler and I'll try to send 
some more your way...

1) Instead of writing out the value of INSTALLDIR, perhaps author the registry 
key value to use the path of a component that is installed under INSTALLDIR.

2) Condition the setting of INSTALLDIR to the default value on whether or not 
INSTALLDIR already exists; or simply if "NOT Installed".  Use a registry search 
to query the [historical] value of INSTALLDIR from the registry to properly set 
INSTALLDIR, if additional items within your installation will need the correct 
value of INSTALLDIR.




From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Athay, David [EMAIL 
PROTECTED]
Sent: Friday, August 08, 2008 4:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Excluding registry entries from patching

I have a problem where I am specifying a registry entry in a component that
writes out the INSTALLDIR property to the registry.  My problem is that
patches to this MSI always reset the INSTALLDIR to the default value (the
Windows Installer default is C:\Program Files)

I need to either A) find a way of excluding that part of my install from
patching, or B) find a way to make sure that the MSP always sets INSTALLDIR
to what the original installation directory was before it processes the
patch so that the registry will still be valid after patching.

Any suggestions?

--
David Athay | CE Up & Running Team | Intuit, Inc. | Work: (858) 215-7149 |


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Dynamic Text in License Dialog

2008-08-08 Thread Alireza Keyvani
Hi everyone,

 

Wix beginner here! I'm trying to customize the license agreement dialogbox
(LicenseAgreementDlg.wxs) in order to add a control (a combo box for
example) that lets the user choose the language in which the license
agreement is displayed (most probably English or French). So I'm thinking I
need to receive a "selection changed" event from the control and, in
response, somehow load a different text into the textbox. Any ideas?

 

Thank you,

 

Alireza



*** This email and any attachments thereto may contain private, confidential, 
and privileged material for the sole use of the intended recipient.  Any 
review, copying, or distribution of this email (or any attachments thereto) by 
others is strictly prohibited.  If you are not the intended recipient, please 
contact the sender immediately and permanently delete the original and any 
copies of this email and any attachments thereto. ***
-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] HOWTO:avoid changing the Registry when patching

2008-08-08 Thread Tony Juricic
I tried adding Transitive attribute to the registry component and that
deleted the component when patch was applied. Thus 'NOT PATCH' is a
correct condition since transitive components are removed when condition
changes from true to false.

However, for some reason that I would really love explained, this
condition is not evaluated to decide whether to install a component when
patching.

There is very useful ProtectFile element, child of UpgradeImage element
that does the job for the files but apparently there is nothing similar
for Registry keys and values? 

Seriously?

If I can find any entertainment value in this, it is in somewhat
reminding me of the good ole' days of emailing people at Microsoft,
voicing annoyance at having to code OpenFile dialog box again and asking
for a standard implementation to be the part of the OS. :O

Anyhow, a kind of fix for the problem is to put condition on the action:

NOT PATCH

but this doesn't make me too happy because it affects all registry
components. 

Any other ideas?
 

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Excluding registry entries from patching

2008-08-08 Thread Athay, David
I have a problem where I am specifying a registry entry in a component that
writes out the INSTALLDIR property to the registry.  My problem is that
patches to this MSI always reset the INSTALLDIR to the default value (the
Windows Installer default is C:\Program Files)

I need to either A) find a way of excluding that part of my install from
patching, or B) find a way to make sure that the MSP always sets INSTALLDIR
to what the original installation directory was before it processes the
patch so that the registry will still be valid after patching.

Any suggestions?

--
David Athay | CE Up & Running Team | Intuit, Inc. | Work: (858) 215-7149 | 


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Dmitry Berkovich
I am going to use suggestion of Tony (session.Format("[directory]").
Its works on install and uninstall stages.

Dima

P.S - Tony thanks


On Fri, Aug 8, 2008 at 8:53 PM, Dmitry Berkovich <[EMAIL PROTECTED]> wrote:
> Alex,
>  CurrentState = Local
>   RequestState = Absent
>
> Dima
>
> On Fri, Aug 8, 2008 at 8:27 PM, Alexander Shevchuk
> <[EMAIL PROTECTED]> wrote:
>> What log is saying about your component?  Specifically, 
>> Installed/Request/Action values.
>>
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry 
>> Berkovich
>> Sent: Friday, August 08, 2008 10:20 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Getting folder localtion of component during 
>> unisntall
>>
>> Alex,
>>  This is exactly what happened, my component was installed and going
>> to be unsiatlled. The problem that my CA need now folder where
>> component was installed.
>> I am looking the way to detect it.
>>
>> Thanks,
>>  Dima
>>
>> On Fri, Aug 8, 2008 at 8:01 PM, Alexander Shevchuk
>> <[EMAIL PROTECTED]> wrote:
>>> Dmitry,
>>>
>>> Does description below applies to your situation (from 
>>> http://msdn.microsoft.com/en-us/library/aa368609(VS.85).aspx)?
>>>
>>> "Note that if a component is already installed, and is not reinstalled, 
>>> removed, or moved during the current installation, the action state of the 
>>> component is null and the string [$componentkey] evaluates to Null."
>>>
>>> If you experience blank path during complete uninstall make sure that 
>>> component is not marked as Permanent.
>>>
>>> Also, make sure your component is not installed to run from source because 
>>> your CA might be doing something with the source files, not locally 
>>> installed ones.
>>>
>>> Regards,
>>>
>>> Alex Shevchuk
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry 
>>> Berkovich
>>> Sent: Friday, August 08, 2008 1:38 AM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: [WiX-users] Getting folder localtion of component during unisntall
>>>
>>> Hi,
>>>  I have some CA that executed during uninstall (just before
>>> RemoveFiles action). My custom action need to know folder where
>>> component was installed. The problem that
>>> session.Format("[$component]") return me empty string. (on
>>> installation phase it contain full path to folder where component
>>> installed).
>>>
>>> Question : what can I do that my CA on uninstall stage will receive
>>> the full path of folder where component installed?
>>>
>>>
>>> Thanks,
>>>  Dima
>>>
>>> -
>>> 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 an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>> -
>>> 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 an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>
>> -
>> 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 an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>> -
>> 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 an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>

-
This SF.Net email is sponsored b

[WiX-users] HOWTO:avoid changing the Registry when patching

2008-08-08 Thread Tony Juricic
I am using condition "NOT PATCH" to change the text in UI to say "Patch"
instead of "Repair" when patch is applied. That works just fine.

Now I want to avoid installing one Registry component during patch
application but not during the repair. I used the same condition (i.e.
NOT PATCH rather than NOT Installed):

  
NOT PATCH
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Dmitry Berkovich
Alex,
  CurrentState = Local
   RequestState = Absent

Dima

On Fri, Aug 8, 2008 at 8:27 PM, Alexander Shevchuk
<[EMAIL PROTECTED]> wrote:
> What log is saying about your component?  Specifically, 
> Installed/Request/Action values.
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry 
> Berkovich
> Sent: Friday, August 08, 2008 10:20 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Getting folder localtion of component during 
> unisntall
>
> Alex,
>  This is exactly what happened, my component was installed and going
> to be unsiatlled. The problem that my CA need now folder where
> component was installed.
> I am looking the way to detect it.
>
> Thanks,
>  Dima
>
> On Fri, Aug 8, 2008 at 8:01 PM, Alexander Shevchuk
> <[EMAIL PROTECTED]> wrote:
>> Dmitry,
>>
>> Does description below applies to your situation (from 
>> http://msdn.microsoft.com/en-us/library/aa368609(VS.85).aspx)?
>>
>> "Note that if a component is already installed, and is not reinstalled, 
>> removed, or moved during the current installation, the action state of the 
>> component is null and the string [$componentkey] evaluates to Null."
>>
>> If you experience blank path during complete uninstall make sure that 
>> component is not marked as Permanent.
>>
>> Also, make sure your component is not installed to run from source because 
>> your CA might be doing something with the source files, not locally 
>> installed ones.
>>
>> Regards,
>>
>> Alex Shevchuk
>>
>>
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry 
>> Berkovich
>> Sent: Friday, August 08, 2008 1:38 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] Getting folder localtion of component during unisntall
>>
>> Hi,
>>  I have some CA that executed during uninstall (just before
>> RemoveFiles action). My custom action need to know folder where
>> component was installed. The problem that
>> session.Format("[$component]") return me empty string. (on
>> installation phase it contain full path to folder where component
>> installed).
>>
>> Question : what can I do that my CA on uninstall stage will receive
>> the full path of folder where component installed?
>>
>>
>> Thanks,
>>  Dima
>>
>> -
>> 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 an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>> -
>> 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 an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.source

Re: [WiX-users] Uninstall of patch running LaunchCondition of RTM msi

2008-08-08 Thread Shawn Dwyer
Thanks Bob.

Do I need to do anything special so that MSI won't let the user install the
product a second time?  Without that Condition entry, the second time I run
the installer it goes through the entire UI sequence, and then just
disappears with no indication of what went wrong.

I like the idea of an uninstallable minor upgrade patch that removes the
launch condition.  How do I author a patch to remove launch conditions?

When following the instruction in Wix.chm (v2), when I create the updated
installer.msi with new Package Id, should the rest of it be the same as the
original installer.msi with possibly some new components, or should/can it
just contain the Wix for installing the handful of files I want
replaced/added in the patch?

Thanks again,

Shawn

On Fri, Aug 8, 2008 at 11:48 AM, Bob Arnson <[EMAIL PROTECTED]> wrote:

> Shawn Dwyer wrote:
> > I'm now in the process of creating our first patch, but unfortunately
> when I
> > uninstall the patch this message is being shown and the patch fails to
> > uninstall.  I am able to uninstall the full product which removes the
> patch
> > with it.
> >
>
> Uninstalling a patch runs a repair of the unpatched product. (So likely
> your current product would likewise fail on repair.) You don't need a
> launch condition like that, because MSI will install a product only once
> (ignoring things like SxS installs and instance transforms.)
>
> You might try an uninstallable minor upgrade patch that removes the
> launch condition; other patches can target that minor upgrade as a new
> baseline.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Alexander Shevchuk
What log is saying about your component?  Specifically, 
Installed/Request/Action values.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Berkovich
Sent: Friday, August 08, 2008 10:20 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Getting folder localtion of component during unisntall

Alex,
  This is exactly what happened, my component was installed and going
to be unsiatlled. The problem that my CA need now folder where
component was installed.
I am looking the way to detect it.

Thanks,
  Dima

On Fri, Aug 8, 2008 at 8:01 PM, Alexander Shevchuk
<[EMAIL PROTECTED]> wrote:
> Dmitry,
>
> Does description below applies to your situation (from 
> http://msdn.microsoft.com/en-us/library/aa368609(VS.85).aspx)?
>
> "Note that if a component is already installed, and is not reinstalled, 
> removed, or moved during the current installation, the action state of the 
> component is null and the string [$componentkey] evaluates to Null."
>
> If you experience blank path during complete uninstall make sure that 
> component is not marked as Permanent.
>
> Also, make sure your component is not installed to run from source because 
> your CA might be doing something with the source files, not locally installed 
> ones.
>
> Regards,
>
> Alex Shevchuk
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry 
> Berkovich
> Sent: Friday, August 08, 2008 1:38 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Getting folder localtion of component during unisntall
>
> Hi,
>  I have some CA that executed during uninstall (just before
> RemoveFiles action). My custom action need to know folder where
> component was installed. The problem that
> session.Format("[$component]") return me empty string. (on
> installation phase it contain full path to folder where component
> installed).
>
> Question : what can I do that my CA on uninstall stage will receive
> the full path of folder where component installed?
>
>
> Thanks,
>  Dima
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Authoring installation of VB6 COM components

2008-08-08 Thread Evans, Jim
I'm pretty sure this has been asked on the list before, but searching
didn't yield a definitive answer for me. In my current project, I'm
working on migrating our current installer to using MSI via WiX, and I
thought I'd try WiX v3. In the project, I have several COM components
that were written using VB 6. I need to know what entries I need to
write into the registry to correctly register the COM components. I have
several questions regarding this process:

 

1. What is the best way to harvest the registry entries for each COM
component? I could use heat, but these are VB6 components, so I get a
bunch of extra stuff in the generated file. I could use tallow from WiX
v2, but I'm not sure that would be any better. I suppose I could export
the registry, register the component, export the registry again, and use
a file comparison tool to generate a list of changes, but that's going
to be tedious and error-prone.

 

2. What is the preferred way in WiX to author the registration of the
components? I've found conflicting advice on whether to use the 
or  elements, or just to write raw registry keys directly.

 

--Jim Evans

Numara Software, Inc.

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Dmitry Berkovich
Alex,
  This is exactly what happened, my component was installed and going
to be unsiatlled. The problem that my CA need now folder where
component was installed.
I am looking the way to detect it.

Thanks,
  Dima

On Fri, Aug 8, 2008 at 8:01 PM, Alexander Shevchuk
<[EMAIL PROTECTED]> wrote:
> Dmitry,
>
> Does description below applies to your situation (from 
> http://msdn.microsoft.com/en-us/library/aa368609(VS.85).aspx)?
>
> "Note that if a component is already installed, and is not reinstalled, 
> removed, or moved during the current installation, the action state of the 
> component is null and the string [$componentkey] evaluates to Null."
>
> If you experience blank path during complete uninstall make sure that 
> component is not marked as Permanent.
>
> Also, make sure your component is not installed to run from source because 
> your CA might be doing something with the source files, not locally installed 
> ones.
>
> Regards,
>
> Alex Shevchuk
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry 
> Berkovich
> Sent: Friday, August 08, 2008 1:38 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Getting folder localtion of component during unisntall
>
> Hi,
>  I have some CA that executed during uninstall (just before
> RemoveFiles action). My custom action need to know folder where
> component was installed. The problem that
> session.Format("[$component]") return me empty string. (on
> installation phase it contain full path to folder where component
> installed).
>
> Question : what can I do that my CA on uninstall stage will receive
> the full path of folder where component installed?
>
>
> Thanks,
>  Dima
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] DTF and .NET Framework on Windows Server 2003

2008-08-08 Thread Jason Ginchereau
Yes. DTF runs each managed custom action in its own dedicated process. Because 
the process is separate and new, there is no risk of some other CLR version 
already being loaded into it. Only an unmanaged stub runs in the MSI custom 
action server process -- that stub coordinates the launch of the new process 
for managed code and the communication with it.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Buddell, James
Sent: Friday, August 08, 2008 5:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] DTF and .NET Framework on Windows Server 2003

http://robmensching.com/blog/archive/2007/04/19.aspx

The above blog tells us that one of the reasons not to use managed code
for DLL CAs is because .NET Framework version 1.1 is always loaded on
Windows Server 2003 regardless of the code's required .NET version. I
know that DTF addresses the sticky CLR problem, but can find no mention
of this second problem. Does DTF resolve this issue?

If it's been fixed separately in a Windows Server 2003 update then
please could someone supply the reference so that I can check that we
have the fix deployed.

Thanks,
James




-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Alexander Shevchuk
Dmitry,

Does description below applies to your situation (from 
http://msdn.microsoft.com/en-us/library/aa368609(VS.85).aspx)?

"Note that if a component is already installed, and is not reinstalled, 
removed, or moved during the current installation, the action state of the 
component is null and the string [$componentkey] evaluates to Null."

If you experience blank path during complete uninstall make sure that component 
is not marked as Permanent.

Also, make sure your component is not installed to run from source because your 
CA might be doing something with the source files, not locally installed ones.

Regards,

Alex Shevchuk




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Berkovich
Sent: Friday, August 08, 2008 1:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Getting folder localtion of component during unisntall

Hi,
  I have some CA that executed during uninstall (just before
RemoveFiles action). My custom action need to know folder where
component was installed. The problem that
session.Format("[$component]") return me empty string. (on
installation phase it contain full path to folder where component
installed).

Question : what can I do that my CA on uninstall stage will receive
the full path of folder where component installed?


Thanks,
 Dima

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] User permissions not removed on uninstall

2008-08-08 Thread MarkZune


Bob Arnson-6 wrote:
> 
> How are you creating the permissions?
> 

I'm using the PermissionEx element. The [MY_PATH] folder already exists
before the install occurs. I'm also adding fileshare permissions to the same
folder. Source snippet is below:















...














...


...
-- 
View this message in context: 
http://www.nabble.com/User-permissions-not-removed-on-uninstall-tp18879550p18895339.html
Sent from the wix-users mailing list archive at Nabble.com.


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Tony Juricic
I use one of my main installed folders and go back one level to get the
root. All installed folders become public properties (property name the
same as folder Id) available also during the uninstall if not in
deferred CA.


-Original Message-
From: Dmitry Berkovich [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 08, 2008 12:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Getting folder localtion of component during
unisntall

Hi boB,

It happed NOT in defered CA.

Dima

On Fri, Aug 8, 2008 at 6:44 PM, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Dmitry Berkovich wrote:
>> The problem that
>> session.Format("[$component]") return me empty string. (on
>> installation phase it contain full path to folder where component
>> installed).
>>
>> Question : what can I do that my CA on uninstall stage will receive
>> the full path of folder where component installed?
>>
>
> Deferred custom actions cannot access the session. See "Obtaining
> Context Information for Deferred Execution Custom Actions" in the MSI
SDK.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
>

-
> 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 an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX-users Digest, Vol 27, Issue 25

2008-08-08 Thread Tony Juricic
I use one of my main installed folders and go back one level to get the
root. All installed folders become public properties (property name the
same as folder Id) available also during the uninstall if not in
deferred CA.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, August 08, 2008 12:12 PM
To: wix-users@lists.sourceforge.net
Subject: WiX-users Digest, Vol 27, Issue 25

Send WiX-users mailing list submissions to
wix-users@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]

You can reach the person managing the list at
[EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of WiX-users digest..."

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Uninstall of patch running LaunchCondition of RTM msi

2008-08-08 Thread Bob Arnson
Shawn Dwyer wrote:
> I'm now in the process of creating our first patch, but unfortunately when I
> uninstall the patch this message is being shown and the patch fails to
> uninstall.  I am able to uninstall the full product which removes the patch
> with it.
>   

Uninstalling a patch runs a repair of the unpatched product. (So likely 
your current product would likewise fail on repair.) You don't need a 
launch condition like that, because MSI will install a product only once 
(ignoring things like SxS installs and instance transforms.)

You might try an uninstallable minor upgrade patch that removes the 
launch condition; other patches can target that minor upgrade as a new 
baseline.

-- 
sig://boB
http://joyofsetup.com/



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Vista uninstall from control panel

2008-08-08 Thread Bob Arnson
Mat wrote:
> I've been running into a problem which I haven't been able to solve 
> related to vista and uninstalling. I have a package which is set to 
> install per-machine and elevated, which requires the user to be 
> administrator to install the package. Under windows vista when the user 
> is the computer administrator and the msi package is run it installs no 
> problem. When the program is uninstalled from the shortcut in the start 
> menu (created on installation) it uninstalls no problem. When the 
> program is uninstalled via the control panel it begins to uninstall and 
> states it is validating requirements, but then says that it requires the 
> user to have administrator rights to uninstall the program.
>   

Get a verbose log using logging policy 
. If the package is marked as 
per-machine, MSI will automatically prompt for elevation on uninstall. 
(A shortcut pointing to msiexec.exe prompts for elevation "early" so the 
entire .msi runs elevated.)

-- 
sig://boB
http://joyofsetup.com/

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Dmitry Berkovich
Hi boB,

It happed NOT in defered CA.

Dima

On Fri, Aug 8, 2008 at 6:44 PM, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Dmitry Berkovich wrote:
>> The problem that
>> session.Format("[$component]") return me empty string. (on
>> installation phase it contain full path to folder where component
>> installed).
>>
>> Question : what can I do that my CA on uninstall stage will receive
>> the full path of folder where component installed?
>>
>
> Deferred custom actions cannot access the session. See "Obtaining
> Context Information for Deferred Execution Custom Actions" in the MSI SDK.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] User permissions not removed on uninstall

2008-08-08 Thread Bob Arnson
MarkZune wrote:
> I'm creating a user ("ServiceUser") as well as specific folder permissions
> during my install for "ServiceUser". When I run the uninstall though,
> "ServiceUser" is removed, but it appears the permissions that I've created
> for "ServiceUser" are still there. 

How are you creating the permissions?

-- 
sig://boB
http://joyofsetup.com/



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Guidance appreciated on tidying up per machine/per user installations

2008-08-08 Thread Ryan O'Neill
Bob's answer of 'don't bother' seemed more suitable, it being Friday and
just gone five PM!

Thanks chaps.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Buddell, James
Sent: 08 August 2008 17:03
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Guidance appreciated on tidying up per machine/per
user installations

You could also use Active Setup to run a tidy-up script for each user.
Take a look at http://www.appdeploy.com/articles/activesetup.asp, the
structure you'd use is the same though you won't be able to use an MSI
command line as the MSI is already uninstalled.

Cheers,
James

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 08 August 2008 16:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Guidance appreciated on tidying up per
machine/per user installations

Ryan O'Neill wrote:
> When I uninstall the app I would like to offer the option to clean 
> these up, so I guess the uninstall from control panel needs an 
> elevated bootstrapper (I'll have to look this up) as it would need to 
> enumerate all users and delete their AppData\MyProduct directories.
>   

Don't bother -- it's not something you can guarantee is possible. For
example, roaming profiles stored on the network won't be accessible.

--
sig://boB
http://joyofsetup.com/




-
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 an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This e-mail is confidential and the information contained in it may be
privileged.  It should not be read, copied or used by anyone other than the
intended recipient.  If you have received it in error, please contact the
sender immediately by telephoning +44 (0)20 7623 8000 or by return email,
and delete the e-mail and do not disclose its contents to any person.  We
believe, but do not warrant, that this e-mail and any attachments are virus
free, but you must take full responsibility for virus checking.  Please
refer to http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail
disclaimer statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking division of
Dresdner Bank AG, and operates through Dresdner Bank AG, Dresdner Kleinwort
Limited, Dresdner Kleinwort Securities Limited and their affiliated or
associated companies.  Dresdner Bank AG is a company incorporated in Germany
with limited liability and registered in England (registered no. FC007638,
place of business 30 Gresham Street, London EC2V 7PG), and is authorised by
the German Federal Financial Supervisory Authority and by the Financial
Services Authority ('FSA') and regulated by the FSA for the conduct of
designated business in the UK.  Dresdner Kleinwort Limited is a company
incorporated in England (registered no. 551334, registered office 30 Gresham
Street, London EC2V 7PG), and is authorised and regulated by the FSA.
Dresdner Kleinwort Securities Limited is a company incorporated in England
(registered no. 1767419, registered office 30 Gresham Street, London EC2V
7PG), and is authorised an
 d regulated by the FSA.


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.138 / Virus Database: 270.6.0/1601 - Release Date: 08/08/2008
09:02


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Guidance appreciated on tidying up per machine/per user installations

2008-08-08 Thread Buddell, James
You could also use Active Setup to run a tidy-up script for each user.
Take a look at http://www.appdeploy.com/articles/activesetup.asp, the
structure you'd use is the same though you won't be able to use an MSI
command line as the MSI is already uninstalled.

Cheers,
James

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 08 August 2008 16:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Guidance appreciated on tidying up per
machine/per user installations

Ryan O'Neill wrote:
> When I uninstall the app I would like to offer the option to clean 
> these up, so I guess the uninstall from control panel needs an 
> elevated bootstrapper (I'll have to look this up) as it would need to 
> enumerate all users and delete their AppData\MyProduct directories.
>   

Don't bother -- it's not something you can guarantee is possible. For
example, roaming profiles stored on the network won't be accessible.

--
sig://boB
http://joyofsetup.com/




-
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 an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
This e-mail is confidential and the information contained in it may be 
privileged.  It should not be read, copied or used by anyone other than the 
intended recipient.  If you have received it in error, please contact the 
sender immediately by telephoning +44 (0)20 7623 8000 or by return email, and 
delete the e-mail and do not disclose its contents to any person.  We believe, 
but do not warrant, that this e-mail and any attachments are virus free, but 
you must take full responsibility for virus checking.  Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking division of 
Dresdner Bank AG, and operates through Dresdner Bank AG, Dresdner Kleinwort 
Limited, Dresdner Kleinwort Securities Limited and their affiliated or 
associated companies.  Dresdner Bank AG is a company incorporated in Germany 
with limited liability and registered in England (registered no. FC007638, 
place of business 30 Gresham Street, London EC2V 7PG), and is authorised by the 
German Federal Financial Supervisory Authority and by the Financial Services 
Authority ('FSA') and regulated by the FSA for the conduct of designated 
business in the UK.  Dresdner Kleinwort Limited is a company incorporated in 
England (registered no. 551334, registered office 30 Gresham Street, London 
EC2V 7PG), and is authorised and regulated by the FSA.  Dresdner Kleinwort 
Securities Limited is a company incorporated in England (registered no. 
1767419, registered office 30 Gresham Street, London EC2V 7PG), and is 
authorised an
 d regulated by the FSA.


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Ways to lock text edit boxes beside "disabled"?

2008-08-08 Thread Bob Arnson
Roger Yen wrote:
> I've been wanting to ask this question for awhile, is there any way to
> "lock" text boxes in wix and not make it disabled, ie. the words in it
> gets grayed out and I don't want that, I really just want an un-editable
> text box that gets a text path from a custom action? 
>   

MSI doesn't expose the edit control's read-only attribute. A text 
control is as close as you're going to get but as you note, it can't 
subscribe to changes like a PathEdit can.

-- 
sig://boB
http://joyofsetup.com/



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Best practices for COM component installation

2008-08-08 Thread Bob Arnson
Evans, Jim wrote:
> What are some of the "best practices" for authoring the installation of
> COM components? Obviously, I know selfreg is evil. When it comes to the
> registration of COM components, should you author the registry entries
> within the same Windows Installer component, or as separate components?
>   

Each executable and its associated registration should get its own 
component, since the component is the atomic unit of MSI installation. 
See "Defining Installer Components" in the MSI SDK for details. That 
said, it doesn't matter a whole lot, because generally users install 
whole features, not individual components.

-- 
sig://boB
http://joyofsetup.com/



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Bob Arnson
Dmitry Berkovich wrote:
> The problem that
> session.Format("[$component]") return me empty string. (on
> installation phase it contain full path to folder where component
> installed).
>
> Question : what can I do that my CA on uninstall stage will receive
> the full path of folder where component installed?
>   

Deferred custom actions cannot access the session. See "Obtaining 
Context Information for Deferred Execution Custom Actions" in the MSI SDK.

-- 
sig://boB
http://joyofsetup.com/



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Guidance appreciated on tidying up per machine/per user installations

2008-08-08 Thread Bob Arnson
Ryan O'Neill wrote:
> When I uninstall the app I would like to offer the option to clean these up,
> so I guess the uninstall from control panel needs an elevated bootstrapper
> (I'll have to look this up) as it would need to enumerate all users and
> delete their AppData\MyProduct directories.
>   

Don't bother -- it's not something you can guarantee is possible. For 
example, roaming profiles stored on the network won't be accessible.

-- 
sig://boB
http://joyofsetup.com/



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Ways to lock text edit boxes beside "disabled"?

2008-08-08 Thread Christopher Karper
I don't think so.  Changing the usual behavior of the UI is generally
considered poor practice.   If something looks like an editable textbox, it
*should* be an editable textbox.

Chris

On Fri, Aug 8, 2008 at 11:19 AM, Roger Yen <[EMAIL PROTECTED]> wrote:

> Hello,
>
>
>
> I've been wanting to ask this question for awhile, is there any way to
> "lock" text boxes in wix and not make it disabled, ie. the words in it
> gets grayed out and I don't want that, I really just want an un-editable
> text box that gets a text path from a custom action?
>
> Using a sunken label somehow achieves this goal, but the text in it
> won't get updated unless I change the dialog and go back.
>
>
>
> Thanks,
>
>
>
> Roger Yen
>
>
>
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
> -
> 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 an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Ways to lock text edit boxes beside "disabled"?

2008-08-08 Thread Roger Yen
Hello,

 

I've been wanting to ask this question for awhile, is there any way to
"lock" text boxes in wix and not make it disabled, ie. the words in it
gets grayed out and I don't want that, I really just want an un-editable
text box that gets a text path from a custom action? 

Using a sunken label somehow achieves this goal, but the text in it
won't get updated unless I change the dialog and go back.

 

Thanks,

 

Roger Yen

 


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] DTF and .NET Framework on Windows Server 2003

2008-08-08 Thread Buddell, James
http://robmensching.com/blog/archive/2007/04/19.aspx

The above blog tells us that one of the reasons not to use managed code
for DLL CAs is because .NET Framework version 1.1 is always loaded on
Windows Server 2003 regardless of the code's required .NET version. I
know that DTF addresses the sticky CLR problem, but can find no mention
of this second problem. Does DTF resolve this issue?

If it's been fixed separately in a Windows Server 2003 update then
please could someone supply the reference so that I can check that we
have the fix deployed.

Thanks,
James


--
This e-mail is confidential and the information contained in it may be 
privileged.  It should not be read, copied or used by anyone other than the 
intended recipient.  If you have received it in error, please contact the 
sender immediately by telephoning +44 (0)20 7623 8000 or by return email, and 
delete the e-mail and do not disclose its contents to any person.  We believe, 
but do not warrant, that this e-mail and any attachments are virus free, but 
you must take full responsibility for virus checking.  Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking division of 
Dresdner Bank AG, and operates through Dresdner Bank AG, Dresdner Kleinwort 
Limited, Dresdner Kleinwort Securities Limited and their affiliated or 
associated companies.  Dresdner Bank AG is a company incorporated in Germany 
with limited liability and registered in England (registered no. FC007638, 
place of business 30 Gresham Street, London EC2V 7PG), and is authorised by the 
German Federal Financial Supervisory Authority and by the Financial Services 
Authority ('FSA') and regulated by the FSA for the conduct of designated 
business in the UK.  Dresdner Kleinwort Limited is a company incorporated in 
England (registered no. 551334, registered office 30 Gresham Street, London 
EC2V 7PG), and is authorised and regulated by the FSA.  Dresdner Kleinwort 
Securities Limited is a company incorporated in England (registered no. 
1767419, registered office 30 Gresham Street, London EC2V 7PG), and is 
authorised an
 d regulated by the FSA.


-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Guidance appreciated on tidying up per machine/per user installations

2008-08-08 Thread Ryan O'Neill
Hi all,

 

I have an app which includes a printer driver which means it needs admin
access to install. As it is a printer driver it can only really be
considered a 'per machine' setup as anyone could print to it.

 

When someone uses the printer driver it creates a per user configuration
file in their AppData\MyProduct directory and also leaves copies of printed
files there.

 

When I uninstall the app I would like to offer the option to clean these up,
so I guess the uninstall from control panel needs an elevated bootstrapper
(I'll have to look this up) as it would need to enumerate all users and
delete their AppData\MyProduct directories.

 

Is this acceptable usage of the per user/per machine concept? Does anyone
have any hints on how to create an uninstall bootstrapper for elevating
under Vista?

 

Advice greatly appreciated.

 

Regards

 

Ryan

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Using properties in DirectorySearch

2008-08-08 Thread Jeff Eldridge
Sorry for the delay in replying to this. I'm still working through a couple of 
issues before I can give a definite answer.

Cheers,
Jeff

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 05 August 2008 15:11
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using properties in DirectorySearch

Jeff Eldridge wrote:
> Is it possible to use property values in the Path attribute for the 
> DirectorySearch element?

Yes, at least according to the DrLocator Table doc in the MSI SDK. Is it
not working as expected?

--
sig://boB
http://joyofsetup.com/



-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


About Microsoft Ireland:  www.microsoft.com/ireland
Microsoft Ireland Operations Limited. A company incorporated and registered in 
Ireland number 256796.
Microsoft Ireland Research. A company incorporated and registered in Ireland 
number 342235.
Registered office 70 Sir John Rogerson's Quay, Dublin 2, Ireland

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Getting folder localtion of component during unisntall

2008-08-08 Thread Dmitry Berkovich
Hi,
  I have some CA that executed during uninstall (just before
RemoveFiles action). My custom action need to know folder where
component was installed. The problem that
session.Format("[$component]") return me empty string. (on
installation phase it contain full path to folder where component
installed).

Question : what can I do that my CA on uninstall stage will receive
the full path of folder where component installed?


Thanks,
 Dima

-
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 an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users