[WiX-users] Sql Server: Reporting Services

[Murray Hipper]

Hi All, 

As menioned in a previous mail out, I was wondering if there was any
comunity support on SQL Server Reporting Services (SSRS). In our
organisation Reporting Servies forms a pretty big part of the picture of
our products and so a deployment method is required for these artefacts.

Idealy we're looking for the deployment and maintainace of Reports,
Models, Resources and Data Sources.

Does anyone know of any group currently working on such a extension or
custom action that we might leaverage off? 
Or is it a item the community has not heavly been involved in yet?

Thanks,
Murray Hipper
Software Developer 
[EMAIL PROTECTED]
 

 

 


This e-mail and any attachments to it (the "Communication") are confidential 
and are for the use only of the intended recipient. The Communication may 
contain copyright material of the Snowden Group ("Snowden"), or any of its 
related entities or of third parties. If you are not the intended recipient of 
the Communication, please notify the sender immediately by return e-mail, 
delete the Communication, and do not copy, print, retransmit, disclose, store 
or act in reliance on the Communication. Any views expressed in the 
Communication are those of the individual sender only, unless expressly stated 
to be those of Snowden. Although virus protection devices and procedures are in 
place, Snowden does not guarantee the integrity of the Communication, or that 
it is free from errors, viruses or interference. Snowden advises email 
recipients to carry out their own virus checks before opening any attachment.  
Please note that the main telephone number for the Snowden Perth office has ch
 anged to +61 8 9213 9213.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Repairing an Installation

[Andreas Hellwig]

Thanks for your answer. Yes I am getting the browse dialog, asking for 
the msi file that was used to install the software. So that's the 
exepected behavior.

Andreas Hellwig


Wilson, Phil schrieb:
> MSI doesn't cache the entire MSI file - it discards the embedded CAB file - 
> so to check or reinstall files it needs access to the original installation 
> source.
>
> However, you should be seeing a browse dialog asking for the source. If 
> you're not getting a browse dialog, that message you're seeing is may be 
> something else. Are you seeing error 1606 or 1706?  1706 is missing source, 
> 1606 is typically caused by a property being used as a directory, but it's 
> not resolving to the local file system so it looks like a network location.
>
> Phil Wilson
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Hellwig
> Sent: Monday, June 16, 2008 7:53 AM
> To: WiX-Users
> Subject: [WiX-users] Repairing an Installation
>
> Hi,
>
> I have a little problem with the installer I'm developing. It seems to
> be impossible to repair the installation without the original msi file.
> If I delete the msi file, repairing allways ends with the error "The
> feature you are trying to use is on a network resource that is
> unavailable.". I thought the Windows Installer is caching the original
> msi file. If it doesn't, is there a possibility to fix the repair option?
>
> Andreas Hellwig
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] UI extension and XmlConfig locales

[Bob Arnson]

Alex Goryuk wrote:
> Can someone point me to the following English strings?
>1. !(loc.msierrXmlConfigFailedRead)
>2. !(loc.msierrXmlConfigFailedOpen)
>3. !(loc.msierrXmlConfigFailedSelect)
>4. !(loc.msierrXmlConfigFailedSave)
>   

They're provided in WixUtilExtension. You need to pass the -cultures 
switch to select the language (currently only en-us is supported for 
WixUtilExtension). Or upgrade to a newer build of WiX; I added support 
for default cultures a while back.

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



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Ensuring services are running before install and cycling services after install

[Bob Arnson]

Ryan O'Neill wrote:
> The problem is that I want to ensure that the Spooler service is running
> before I do any printer manipulation as some of the API calls need that
> service running. I don't know how to have two sets of StartService.
>   

You can't -- actions can be scheduled only once. Generally you stop 
services at the beginning and (re)start them at the end. You'll need a 
custom action to start services early.

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



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] BUG: Group cannot be added to component.

[Bob Arnson]

Demented Devil wrote:
> Now banging my head against the wall - for some reason my embedded wixlib is
> not being attached to the msi file being compiled even though my extension
> dll is being used (ie: I've got a GroupEx table in my MSI as expected but
> the custom action fragments are missing - weird.
>   

Is your compiler extension adding a reference to the CustomAction/@Id?

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



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixLib and WixVariable

[Bob Arnson]

Wouter Demuynck wrote:
>   
>   http://schemas.microsoft.com/wix/2006/wi";>
> 
>   
>   
>  
>
>   

One possibility is that the !(wix.id) uses aren't enough to reference 
the WixVariable definitions in the library. Try this: Add a Property to 
the library and add a PropertyRef for that Id to the Product. If that 
works, please file a bug; I think the !(wix.id) should be sufficient to 
bring in the library.

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



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Help me fix my mistake please...

[Chris Mumford]

I learned a few years back not to change my upgrade code, unfortunately a
little too late. The good news is that I only changed it once. My current
WiX source is:



  ...

  




  

  

And what I'm seeing is that version 3.0.0.1 and later is being upgraded
properly, but prior versions (those having UpgradeCode
9B672C80-9A35-4EA5-9A9B-7D7E3626E912) are not being uninstalled and are left
on the machine.

Can anybody spot what I'm doing wrong here?

Thanks,

-Chris
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] SPAM-LOW reading configuration properties from XML

[Wix User]

I have followed the example as given here.
http://www.dalun.com/wix/05.22.2007.htm

I have the path of .net assembly coming from the configuration xml.
but when I concatenate as follows I get an error.


   


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] SPAM-LOW upgrading package

[Wix User]

I wanted to make an upgrade package. my code is given below.
i still get the message when running the msi "another version of this
product is already installed" with an OK button.
















 








-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ComponentRegister/ComponentUnregister problem on reinstall

[Ben Greene]

Hi,

I posted this last week, but now I've discovered some more information and 
hopefully someone will be able to help now :)

I've created a fairly straightforward installer apart from some CustomActions 
and one custom dialog.
The first installation goes fine, and the uninstallation appears to (no errors 
in the MSI log in either).
When you try to reinstall, I get hundreds of error message boxes -

DEBUG: Error 2909:  Could not unregister component {GUID} (for each component)
then
DEBUG: Error 2908:  Could not register component {GUID}  (for each component)

Once I press OK on each one, the product installs correctly.  After this, if I 
try to uninstall again there doesn't seem to be a problem, but no files get 
removed.

Does anyone know how I could fix this?  I think I could add an entry to the 
error table to suppress the messages, but the uninstall still seems broken.

Ben
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] DTF: Saving data in deffered custom action

[Christopher Painter]

Ah, I see that now.  I saw your reply and realized the part of the question 
that I missed.  I've actually done a lot with persisting data across sessions 
over the years as I am not a beleiver in `configuration data is a pain`. :-)   
I've even been known to tie into custom AD schema extensions to allow managing 
configuration data in a generic manner across an enterprise.  Very interesting 
stuff that I don't understand why it's not built into MSI proper.


Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Mon, 6/16/08, Jason Ginchereau <[EMAIL PROTECTED]> wrote:

> From: Jason Ginchereau <[EMAIL PROTECTED]>
> Subject: RE: [WiX-users] DTF: Saving data in deffered custom action
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, "General discussion for Windows 
> Installer XML toolset." 
> Date: Monday, June 16, 2008, 6:52 PM
> >> maybe I'm missing something but the constructor
> choices for the CustomActionData class could probably be a
> little better. The CustomActionData property is always
> `CustomActionData` so maybe there should be an overload
> that takes the session class as an argument and
> automatically gets the CustomActionData property.
> 
> I guess you missed it. From a deferred CA, the
> session.CustomActionData property will get that data more
> easily.
> 
> However I think Phil's question was not about passing
> data from immediate to deferred, hence my other reply.
> 
> -Jason-
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Christopher Painter
> Sent: Monday, June 16, 2008 4:46 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] DTF: Saving data in deffered
> custom action
> 
> If you wire up an installer class CA in VDPROJ and edit the
> resultant MSI in Orca you'll see that you are actually
> getting 2 CA's for each CA.   Was is a Type 51 CA
> that's setting a property with the same name as the
> second deferred CA.   This is the serialization of
> properties that the installcontext is deserializing for
> you.
> 
> So for DTF, whether it's WiX or InstallShield or
> whatever,  you need an immeadiate CA that serializes and
> sets the property that will become CustomActionData and
> then in your deferred CA you need to deserialize it.
> 
> The serialization looks something like this: ( shoot from
> hip coding, not tested )
> 
> CustomActionData cad = new CustomActionData();
> cad.Add( new
> KeyValuePair<"PROPA","VALUEA");
> session["DeferredCustomActionName"] =
> cad.ToString();
> 
> The deserialization looks something like this:
> 
> CustomActionData cad = new
> CustomActionData(session["CustomActionData"]);
> string valuea = cad["PROPA"];
> 
> BTW, in case Jason is reading, maybe I'm missing
> something but the constructor choices for the
> CustomActionData class could probably be a little better. 
> The CustomActionData property is always `CustomActionData`
> so maybe there should be an overload that takes the session
> class as an argument and automatically gets the
> CustomActionData property.
> 
> I hope that helps.
> 
> Regards,
> Chris
> 
> 
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread
> that deserves attention? E-Mail Me
> 
> 
> --- On Mon, 6/16/08, Phil H <[EMAIL PROTECTED]>
> wrote:
> 
> > From: Phil H <[EMAIL PROTECTED]>
> > Subject: [WiX-users]  DTF: Saving data in deffered
> custom action
> > To: wix-users@lists.sourceforge.net
> > Date: Monday, June 16, 2008, 6:34 PM
> > I have inherited some WIX code (ie I am a newbie) and
> have
> > moved the managed
> > custom action over to DTF (which is very nice BTW).
> >
> > Previously the CA did something along these lines:
> >
> > public class MyInstaller :
> > System.Configuration.Install.Installer
> > {
> >   public override void
> > Install(System.Collections.IDictionary stateSaver)
> >   {
> >   base.Install (stateSaver);
> >   stateSaver.Add(SS_KEY_INSTALLED_PROFILE,
> AddProfile());
> >   :
> >   }
> >
> >   public override void
> > Uninstall(System.Collections.IDictionary savedState)
> >   {
> >   :
> >   bool didInstallProfile =
> > (bool)savedState[SS_KEY_INSTALLED_PROFILE];
> >   :
> >   }
> > }
> >
> >
> > Using DTF how can I store a value during the install
> that I
> > can retrieve in
> > the uninstall? Note that I am using a deferred custom
> > action so the Database
> > etc properties of the DTF Session object aren't
> > available.
> >
> > Out of hope I tried session.CustomActionData but that
> > doesn't seem to
> > persist.
> >
> > TIA,
> >
> > Phil
> >


  

-
Check out the new SourceForge.net Marketplace.
It's the

Re: [WiX-users] DTF: Saving data in deffered custom action

[Jason Ginchereau]

>> maybe I'm missing something but the constructor choices for the 
>> CustomActionData class could probably be a little better. The 
>> CustomActionData property is always `CustomActionData` so maybe there should 
>> be an overload that takes the session class as an argument and automatically 
>> gets the CustomActionData property.

I guess you missed it. From a deferred CA, the session.CustomActionData 
property will get that data more easily.

However I think Phil's question was not about passing data from immediate to 
deferred, hence my other reply.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Painter
Sent: Monday, June 16, 2008 4:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DTF: Saving data in deffered custom action

If you wire up an installer class CA in VDPROJ and edit the resultant MSI in 
Orca you'll see that you are actually getting 2 CA's for each CA.   Was is a 
Type 51 CA that's setting a property with the same name as the second deferred 
CA.   This is the serialization of properties that the installcontext is 
deserializing for you.

So for DTF, whether it's WiX or InstallShield or whatever,  you need an 
immeadiate CA that serializes and sets the property that will become 
CustomActionData and then in your deferred CA you need to deserialize it.

The serialization looks something like this: ( shoot from hip coding, not 
tested )

CustomActionData cad = new CustomActionData();
cad.Add( new KeyValuePair<"PROPA","VALUEA");
session["DeferredCustomActionName"] = cad.ToString();

The deserialization looks something like this:

CustomActionData cad = new 
CustomActionData(session["CustomActionData"]);
string valuea = cad["PROPA"];

BTW, in case Jason is reading, maybe I'm missing something but the constructor 
choices for the CustomActionData class could probably be a little better.  The 
CustomActionData property is always `CustomActionData` so maybe there should be 
an overload that takes the session class as an argument and automatically gets 
the CustomActionData property.

I hope that helps.

Regards,
Chris


Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Mon, 6/16/08, Phil H <[EMAIL PROTECTED]> wrote:

> From: Phil H <[EMAIL PROTECTED]>
> Subject: [WiX-users]  DTF: Saving data in deffered custom action
> To: wix-users@lists.sourceforge.net
> Date: Monday, June 16, 2008, 6:34 PM
> I have inherited some WIX code (ie I am a newbie) and have
> moved the managed
> custom action over to DTF (which is very nice BTW).
>
> Previously the CA did something along these lines:
>
> public class MyInstaller :
> System.Configuration.Install.Installer
> {
>   public override void
> Install(System.Collections.IDictionary stateSaver)
>   {
>   base.Install (stateSaver);
>   stateSaver.Add(SS_KEY_INSTALLED_PROFILE, AddProfile());
>   :
>   }
>
>   public override void
> Uninstall(System.Collections.IDictionary savedState)
>   {
>   :
>   bool didInstallProfile =
> (bool)savedState[SS_KEY_INSTALLED_PROFILE];
>   :
>   }
> }
>
>
> Using DTF how can I store a value during the install that I
> can retrieve in
> the uninstall? Note that I am using a deferred custom
> action so the Database
> etc properties of the DTF Session object aren't
> available.
>
> Out of hope I tried session.CustomActionData but that
> doesn't seem to
> persist.
>
> TIA,
>
> Phil
>


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] DTF: Saving data in deffered custom action

[Christopher Painter]

It would have helpe if I read the entire question. :-)

For persisting Data I take a multiple step approach that allows considering all 
the modes an install will run including interactive with custom dialogs for 
setting values and silent installs for passing values in.   The idea is the 
priority of values is

(Greatest to least)
1) Value set during UI
2) Value set from command line
3) Value harvested from statesaver
4) Default value from property table

I have found this pattern very bulletproof over the years and I can share a 
more detailed example if you like.

Regards,
Chris


Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Mon, 6/16/08, Jason Ginchereau <[EMAIL PROTECTED]> wrote:

> From: Jason Ginchereau <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] DTF: Saving data in deffered custom action
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Monday, June 16, 2008, 6:47 PM
> Session.CustomActionData is primarily meant for passing data
> from immediate to deferred CAs.
> 
> DTF doesn't currently provide a built-in mechanism for
> persisting state across install sessions, though that might
> be a nice feature to add.
> 
> For now you'll need to stash the data either in a
> registry key or in a file. (The
> System.Configuration.Install.Installer
> "stateServer" data gets saved in a .installstate
> file in the same directory as the assembly.) I guess you
> could make use of the CustomActionData class here, since it
> provides a convenient way to serialize a string dictionary.
> 
> Just be careful to think about what happens to the data in
> all scenarios including rollback, repair, and
> upgrade/patching.
> 
> -Jason-
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Phil H
> Sent: Monday, June 16, 2008 4:35 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] DTF: Saving data in deffered custom
> action
> 
> 
> I have inherited some WIX code (ie I am a newbie) and have
> moved the managed
> custom action over to DTF (which is very nice BTW).
> 
> Previously the CA did something along these lines:
> 
> public class MyInstaller :
> System.Configuration.Install.Installer
> {
> public override void
> Install(System.Collections.IDictionary stateSaver)
> {
> base.Install (stateSaver);
> stateSaver.Add(SS_KEY_INSTALLED_PROFILE,
> AddProfile());
> :
> }
> 
> public override void
> Uninstall(System.Collections.IDictionary savedState)
> {
> :
> bool didInstallProfile =
> (bool)savedState[SS_KEY_INSTALLED_PROFILE];
> :
> }
> }
> 
> 
> Using DTF how can I store a value during the install that I
> can retrieve in
> the uninstall? Note that I am using a deferred custom
> action so the Database
> etc properties of the DTF Session object aren't
> available.
> 
> Out of hope I tried session.CustomActionData but that
> doesn't seem to
> persist.
> 
> TIA,
> 
> Phil
> 
> 
> 
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] DTF: Saving data in deffered custom action

[Jason Ginchereau]

Session.CustomActionData is primarily meant for passing data from immediate to 
deferred CAs.

DTF doesn't currently provide a built-in mechanism for persisting state across 
install sessions, though that might be a nice feature to add.

For now you'll need to stash the data either in a registry key or in a file. 
(The System.Configuration.Install.Installer "stateServer" data gets saved in a 
.installstate file in the same directory as the assembly.) I guess you could 
make use of the CustomActionData class here, since it provides a convenient way 
to serialize a string dictionary.

Just be careful to think about what happens to the data in all scenarios 
including rollback, repair, and upgrade/patching.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil H
Sent: Monday, June 16, 2008 4:35 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] DTF: Saving data in deffered custom action


I have inherited some WIX code (ie I am a newbie) and have moved the managed
custom action over to DTF (which is very nice BTW).

Previously the CA did something along these lines:

public class MyInstaller : System.Configuration.Install.Installer
{
public override void Install(System.Collections.IDictionary stateSaver)
{
base.Install (stateSaver);
stateSaver.Add(SS_KEY_INSTALLED_PROFILE, AddProfile());
:
}

public override void Uninstall(System.Collections.IDictionary 
savedState)
{
:
bool didInstallProfile = 
(bool)savedState[SS_KEY_INSTALLED_PROFILE];
:
}
}


Using DTF how can I store a value during the install that I can retrieve in
the uninstall? Note that I am using a deferred custom action so the Database
etc properties of the DTF Session object aren't available.

Out of hope I tried session.CustomActionData but that doesn't seem to
persist.

TIA,

Phil



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] DTF: Saving data in deffered custom action

[Christopher Painter]

If you wire up an installer class CA in VDPROJ and edit the resultant MSI in 
Orca you'll see that you are actually getting 2 CA's for each CA.   Was is a 
Type 51 CA that's setting a property with the same name as the second deferred 
CA.   This is the serialization of properties that the installcontext is 
deserializing for you.

So for DTF, whether it's WiX or InstallShield or whatever,  you need an 
immeadiate CA that serializes and sets the property that will become 
CustomActionData and then in your deferred CA you need to deserialize it.

The serialization looks something like this: ( shoot from hip coding, not 
tested )

CustomActionData cad = new CustomActionData();
cad.Add( new KeyValuePair<"PROPA","VALUEA");
session["DeferredCustomActionName"] = cad.ToString();

The deserialization looks something like this:

CustomActionData cad = new 
CustomActionData(session["CustomActionData"]);
string valuea = cad["PROPA"];

BTW, in case Jason is reading, maybe I'm missing something but the constructor 
choices for the CustomActionData class could probably be a little better.  The 
CustomActionData property is always `CustomActionData` so maybe there should be 
an overload that takes the session class as an argument and automatically gets 
the CustomActionData property.

I hope that helps.

Regards,
Chris



Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Mon, 6/16/08, Phil H <[EMAIL PROTECTED]> wrote:

> From: Phil H <[EMAIL PROTECTED]>
> Subject: [WiX-users]  DTF: Saving data in deffered custom action
> To: wix-users@lists.sourceforge.net
> Date: Monday, June 16, 2008, 6:34 PM
> I have inherited some WIX code (ie I am a newbie) and have
> moved the managed
> custom action over to DTF (which is very nice BTW).
> 
> Previously the CA did something along these lines: 
> 
> public class MyInstaller :
> System.Configuration.Install.Installer
> { 
>   public override void
> Install(System.Collections.IDictionary stateSaver)
>   {
>   base.Install (stateSaver);
>   stateSaver.Add(SS_KEY_INSTALLED_PROFILE, AddProfile());
>   :   
>   }
>   
>   public override void
> Uninstall(System.Collections.IDictionary savedState)
>   {
>   :
>   bool didInstallProfile =
> (bool)savedState[SS_KEY_INSTALLED_PROFILE];
>   :
>   }
> }
> 
> 
> Using DTF how can I store a value during the install that I
> can retrieve in
> the uninstall? Note that I am using a deferred custom
> action so the Database
> etc properties of the DTF Session object aren't
> available.
> 
> Out of hope I tried session.CustomActionData but that
> doesn't seem to
> persist.
> 
> TIA,
> 
> Phil
> 
> -- 
> View this message in context:
> http://www.nabble.com/DTF%3A-Saving-data-in-deffered-custom-action-tp17858653p17858653.html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> 
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] DTF: Saving data in deffered custom action

[Phil H]

I have inherited some WIX code (ie I am a newbie) and have moved the managed
custom action over to DTF (which is very nice BTW).

Previously the CA did something along these lines: 

public class MyInstaller : System.Configuration.Install.Installer
{   
public override void Install(System.Collections.IDictionary stateSaver)
{
base.Install (stateSaver);
stateSaver.Add(SS_KEY_INSTALLED_PROFILE, AddProfile());
:   
}

public override void Uninstall(System.Collections.IDictionary 
savedState)
{
:
bool didInstallProfile = 
(bool)savedState[SS_KEY_INSTALLED_PROFILE];
:
}
}


Using DTF how can I store a value during the install that I can retrieve in
the uninstall? Note that I am using a deferred custom action so the Database
etc properties of the DTF Session object aren't available.

Out of hope I tried session.CustomActionData but that doesn't seem to
persist.

TIA,

Phil

-- 
View this message in context: 
http://www.nabble.com/DTF%3A-Saving-data-in-deffered-custom-action-tp17858653p17858653.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] File Version for patches

[Lyle Hollenbeck]

Can some one explain how file version numbers relate to patches?  My
original file version number is 5.10.1040.08 and the new file version
number is 5.10.1040.09 and the patch did not make any changes.  If I
change my new file version number to 5.10.1041 the changes take.  This
is confusing to me since I had come across a page in the MSDN that said
the "ProductVersion" only used the first three positions but this did
not apply to file version numbers.  Unfortunately I can no longer find
the page that had this statement.  I am using WIX 2.0.5805.0

 

Lyle Hollenbeck

 

 



---
Confidentiality Notice:  This electronic mail transmission is confidential, 
may be privileged and should be read or retained only by the intended
recipient.  If you have received this transmission in error, please
immediately notify the sender and delete it from your system.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Question about of using upgrade/patch

[Dmitry Berkovich]

Hi,
  I have design question for  community.
My application has one common dll (common.dll) and two exe
applications, where both of them depend on this common dll.
Could someone suggest me when I need use minor/major upgrade/patch for
each scenario that follows:
   1) My group release new version every 2 month. When we are
releasing new version, we need to upgrade from previous version, where
new version will have additional set of features or some features are
removed. It easy requirement, I can uninstall previous version and
install new one.
   2) In timeslot between old to new version we can find a bug, so we
need release upgrade, where this upgrade can contain additional
components or some dlls need be updated, When bug founded in
common.dll, it can be upgraded for all exe`s that use him.
   3) It same like (2) but changes can be done in common.dll, where
first exe use new common.dll, but second exe need use common.dll from
original version.

Technically (without installer) I know how to support it. Since I
don't want to use GAC, I will install 2 exe`s to INSTALLDIR, where
common.dll will be installed to INSTALLDIR\Common_X.Y.Z folder.
runtime entry in each exe.config will contain   node that will be reference to common folder. So when
I will do patch for scenario (3) I will create new folder
INSTALLDIR\Common_X.Y.K that will contain common.dll with new version,
and for some exe I will update .




Thanks in advance
Dima

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] XmlFile CreateElement

[Alexander Shevchuk]

Or you can use the fact that your newly created element does not have attribute 
yet:

//ParentNode/ChildNodes/ChildNode[\[]not(@Name)[\]]


Alex




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Perlman
Sent: Monday, June 16, 2008 11:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] XmlFile CreateElement

You could also use XmlConfig.

>From an xpath point of view you can use something like so in your XmlSetting2 
>which would get you the 3rd child element.

"//ParentNode/ChildNodes/ChildNode[\[]3[\]]

Ryan



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of md5hans
Sent: Monday, June 16, 2008 6:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] XmlFile CreateElement


Hi!

I have a question about manipulating XML-files. I want to create a new
element inside an existing node, after the element is created I want to set
some attributes on it.

My problem is that there already exists elements of the kind I want to add,
how can I make the setValue action work on the new element instead of on of
the existing? (the first one)

My XML-file have the following structure


   
   
   
   


And I want to create a new ChildNode element and set the Name value to "C".




when I try this it adds a new empty ChildNode element and modifies the name
of the "A" childnode. I suppose that it's not so suprisning since I do not
specify which ChildNode element that should be modified...

Should I set the value attribute in createElement and then use that value
(by using a XPath) when identifying the new child node where I want to set
the name attribute? If so, how do I set the Text value when defining a
XPath?

/Hans
--
View this message in context: 
http://www.nabble.com/XmlFile-CreateElement-tp17864933p17864933.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Linq to MSI

[Jason Ginchereau]

I've contacted Bart.. He happens to work just one building over from me. We're 
going to meet this week to discuss possible future collaboration on LINQ to MSI.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Painter
Sent: Saturday, June 14, 2008 8:20 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Linq to MSI

Should someone tell him about DTF?

I was once working on a MSI Provider for ADO.NET 2.0 ... I guess Linq is the 
way to go now.

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Sat, 6/14/08, Martin MacPherson <[EMAIL PROTECTED]> wrote:

> From: Martin MacPherson <[EMAIL PROTECTED]>
> Subject: [WiX-users] Linq to MSI
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Saturday, June 14, 2008, 5:36 AM
> Don't know if anyone has come across this yet but Bart
> De Smet is doing a
> series of articles around creating a Linq provider for MSI:
>
> http://communities.bartdesmet.net/blogs/bart/archive/2008/06/06/linq-to-msi-part-0-introduction.aspx
>
> http://communities.bartdesmet.net/blogs/bart/archive/2008/06/13/linq-to-msi-part-1-interop.aspx


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] XmlFile CreateElement

[Ryan Perlman]

You could also use XmlConfig.

>From an xpath point of view you can use something like so in your XmlSetting2 
>which would get you the 3rd child element.

"//ParentNode/ChildNodes/ChildNode[\[]3[\]]

Ryan



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of md5hans
Sent: Monday, June 16, 2008 6:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] XmlFile CreateElement


Hi!

I have a question about manipulating XML-files. I want to create a new
element inside an existing node, after the element is created I want to set
some attributes on it.

My problem is that there already exists elements of the kind I want to add,
how can I make the setValue action work on the new element instead of on of
the existing? (the first one)

My XML-file have the following structure


   
   
   
   


And I want to create a new ChildNode element and set the Name value to "C".




when I try this it adds a new empty ChildNode element and modifies the name
of the "A" childnode. I suppose that it's not so suprisning since I do not
specify which ChildNode element that should be modified...

Should I set the value attribute in createElement and then use that value
(by using a XPath) when identifying the new child node where I want to set
the name attribute? If so, how do I set the Text value when defining a
XPath?

/Hans
--
View this message in context: 
http://www.nabble.com/XmlFile-CreateElement-tp17864933p17864933.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] UI extension and XmlConfig locales

[Alex Goryuk]

Hi,

Can someone point me to the following English strings?
   1. !(loc.msierrXmlConfigFailedRead)
   2. !(loc.msierrXmlConfigFailedOpen)
   3. !(loc.msierrXmlConfigFailedSelect)
   4. !(loc.msierrXmlConfigFailedSave)

Apparently they are only translated into en-US, as part of
WixUtilExtension.dll, but
http://wix.cvs.sourceforge.net/*checkout*/wix/wix/src/ext/UIExtension/wixlib
/WixUI_en-us.wxl does not contain them.
Based on this bug: 
http://sourceforge.net/mailarchive/message.php?msg_id=E1II8pj-0004if-UF%40sc
8-sf-web23.sourceforge.net

Thanks,
Alex G.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Properties

[Alexander Shevchuk]

Steps 1 and 2 can be done in the custom action scheduled before AppSearch.  
Step 3 can be done by AppSearch.

Alex


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Natxo Mateos
Sent: Monday, June 16, 2008 5:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Properties

Hi,

I've got one question related to properties. There is no other way to
store and manipulate strings than using properties?

I have to implement the next sequence:

1. Access the registry
2. Use the value read to construct another string
3. Access to the key calculated in (2)

The problem is due that step (2) is done via a Custom Action, step (3)
must be done in an external dll.
There no other way to achieve this, without having to call an external
dll to search in the registry?

Thanks in advance,

--

Regards,

*Natxo Mateos*
[EMAIL PROTECTED]

*Asuni CAD* - _www.asuni.es _ - 93 319 6868 - 91
541 6439
*Especialistas en el desarrollo de aplicaciones a medida sobre AutoCAD*

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Mixed-case guids

[Alexander Shevchuk]

>Can you explain what you mean by "proper GUIDs"?
>I wasn't aware that Votive was generating bad GUIDs.

GUID data type (http://msdn.microsoft.com/en-us/library/aa368767(VS.85).aspx) 
requires GUIDs to be all upper-case:

" Note that utilities such as GUIDGEN can generate GUIDs containing lowercase 
letters. These must all be changed to uppercase letters before the GUID can be 
used by the installer as a valid product code, package code, or component code."


>Votive does not do any conversion. We tried to get all uppercase letters for
>the GUID, but Visual Studio automatically generates those when it creates
>the project templates. There may be a way around it by using the Wizard
>infrastructure, but it was a low priority item.
>
>Justin

Now I see where problem is.  Still, it might be a good idea to put some 
comments regarding changing the wizard generated GUIDs.


Alex


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] External DLL Custom Action

[Wilson, Phil]

Definitely. I've seen this issue come up more than a few times  There seems to 
be a common perception that binaries generated with different versions of 
Visual Studio C++ can all use the same version of the runtime support, but 
starting with VS.NET they're all unique.

Phil Wilson

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dana Gutride
Sent: Monday, June 16, 2008 5:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] External DLL Custom Action

The first thing you might want to check is it linked statically or
dynamically to the VC80 runtime libraries.  Changing to Visual Studio 2005
most likely introduced a dependency for you because of the C runtime
changes.  If you don't want to link statically to the CRT, you could also
use a bootstrapper to install the VC80 redistributable package prior to
running your install.

Dana

On Mon, Jun 16, 2008 at 5:47 AM, Natxo Mateos <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> I've coded a simple dll (where I do a registry search) to be used as a
> Custom Action. If I compile it with Visual Studio 2002, all works
> propertly, and during the installation, the dll is called. But if I try
> to use the VS 2005 compiler, the installer fails, displaying a message
> where alerts that some external dll couldn't be called.
>
> --
>
> Regards,
>
> *Natxo Mateos*
> [EMAIL PROTECTED]
>
> *Asuni CAD* - _www.asuni.es _ - 93 319 6868 - 91
> 541 6439
> *Especialistas en el desarrollo de aplicaciones a medida sobre AutoCAD*
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Disabling feature options on parent feature?

[Brian Simoneau]

This has been answered on the mailing list before.  Search for "Removing
Install to Run From Network Feature Option".  This happens when a
feature only has sub-features and not components.

-Brian Simoneau

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Reed
(SQL)
Sent: Monday, June 16, 2008 12:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Disabling feature options on parent feature?

I've got a set of features that I moved under a new parent feature, and
the new parent feature has a pair of options that A) don't make sense
and B) I don't want... but I don't see how to disable them in the v3
schema. They only appear for the parent feature when it has children;
other features at the same level as the parent do not exhibit these
options.

How do I turn off these two feature options?

* Will be installed from network
* Entire feature will be installed to run from network


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Repairing an Installation

[Wilson, Phil]

MSI doesn't cache the entire MSI file - it discards the embedded CAB file - so 
to check or reinstall files it needs access to the original installation source.

However, you should be seeing a browse dialog asking for the source. If you're 
not getting a browse dialog, that message you're seeing is may be something 
else. Are you seeing error 1606 or 1706?  1706 is missing source, 1606 is 
typically caused by a property being used as a directory, but it's not 
resolving to the local file system so it looks like a network location.

Phil Wilson

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Hellwig
Sent: Monday, June 16, 2008 7:53 AM
To: WiX-Users
Subject: [WiX-users] Repairing an Installation

Hi,

I have a little problem with the installer I'm developing. It seems to
be impossible to repair the installation without the original msi file.
If I delete the msi file, repairing allways ends with the error "The
feature you are trying to use is on a network resource that is
unavailable.". I thought the Windows Installer is caching the original
msi file. If it doesn't, is there a possibility to fix the repair option?

Andreas Hellwig

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem with DTF Custom action invoked via PushButton Event : DoAction

[Jason Ginchereau]

Update regarding #4: CA build behavior relating to GAC assemblies should be 
much better after a fix in the latest build 3.0.42140.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ginchereau
Sent: Monday, June 09, 2008 10:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Problem with DTF Custom action invoked via PushButton 
Event : DoAction

1. Already answered by Christopher Painter -- Thanks.

2. Based on reports from you and Amy on this list, it would seem the bug is not 
entirely fixed. I'll have to investigate further. Are there certain API calls 
that often cause the CA to die? (Setting properties?)

>> My CA method has a try/catch that surrounds all the code, to catch any 
>> exception, log it to the session and return ActionResult.Failure.

Note that is not necessary because the code that calls the CA method does 
exactly that already.

3. Good suggestion, I'll consider automatically including the PDB in the 
package for Debug builds. Meanwhile you can accomplish this by editing the 
project file: set a CustomActionContents property to a semicolon-delimited list 
of additional files to be included.

4. Any referenced assembly that's in the GAC (and CopyLocal=false) should get 
loaded automatically by the CLR during the MakeSfxCA step and omitted from the 
package. That is what I have observed to happen so far, but maybe there is need 
for further investigation.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Krishna Nadiminti
Sent: Sunday, June 08, 2008 8:38 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with DTF Custom action invoked via PushButton 
Event : DoAction


Hi Jason,

I've created a few custom actions in C# using your wonderful DTF framework.

So far, I found a couple of issues. One of them seems to be a showstopper -
for now.

1. I invoke my C# custom action when a PushButton raises the DoAction
control event. The action gets called correctly, (most of the time about 80%
of the time) and while it seems to do the right thing, I don't get any of
the messages I logged from inside my custom action using session.Log. My
other custom actions which are directly sequenced in the
InstallExecuteSequence do log messages out, and those messages appear
correctly.

2. This is the 80% part. I read a previous post from someone, who said a
similar thing, and your reply saying it was fixed. I'm currently using Wix
v.3.0.4207. But, in my case occasionally it just doesn't work. No error
messages are shown in the log - nothing. Just says my CA died and that's it.
Now, if I rebuild, and re-launch the setup, it generally works. I'm using VS
2008 and Votive by the way, to build stuff. My CA method has a try/catch
that surrounds all the code, to catch any exception, log it to the session
and return ActionResult.Failure.

3. Now, this may be helpful to developers in the future: how about packaging
the .pdb file of the .NET custom action dll along with the dll and
MS.Deployment.dll? This would give people slightly better info regarding the
line number etc where their .NET CA code fails.

4. Another one, related to 3, is the build process for the PackCustomAction
MSBuild target (in the MakeSFX)... My custom action that runs in immediate
mode, during the UI sequence and does not modify the system, shows a
Winforms dialog. I have to show a list of x509 certs to the user to select
one, and Wix UI is simply incapable of doing that. (I really dont want to
hack up the listView control and stuff in Wix/MSI's standard UI - it just
doesn't serve my purpose). Anyway, this Winforms thing actually works but I
had a couple of issues along the way : The MakeSfxCA step after my custom
action compilation complains about System.Windows.Forms not being in my
bin\Debug directory. If I set System.Windows.Forms.dll, and its dependencies
to be copied locally, in VS 2008, then MakeSFX does not complain - otherwise
- it blows up.
I looked into the code to see what it is doing - and understand where and
why it blows up: it tries to load the Assembly dependencies from the
bin\Debug directory (or whereever the .NET CA compiles to), and can't find
it! Now, I think there should be some code in there to avoid checking for
Exported types, and methods decorated with [CustomAction], IF the dependency
is a standard .NET Fx dll or perhaps you could check if the dll is GAC-ed.
Both of these first require to not assume that all the dependencies are in
the bin\Debug directory.

I hope that makes sense. Please let me know what you think.

Thanks,
Krishna.
--


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sou

[WiX-users] Disabling feature options on parent feature?

[David Reed (SQL)]

I've got a set of features that I moved under a new parent feature, and the new 
parent feature has a pair of options that A) don't make sense and B) I don't 
want... but I don't see how to disable them in the v3 schema. They only appear 
for the parent feature when it has children; other features at the same level 
as the parent do not exhibit these options.

How do I turn off these two feature options?

* Will be installed from network
* Entire feature will be installed to run from network

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to force administrative install to INSTALLDIR

[Jim Williams]

Try:  msiexec /a package.msi TARGETDIR=C:\users\volker\test\

Jim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Volker
Enderlein
Sent: Monday, June 16, 2008 2:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to force administrative install to INSTALLDIR

Hi NG,

I am using the examples from the wix tutorial. When I try to perform an 
administrative install with such a package without UI ( msiexec /a 
package.msi INSTALLDIR=C:\users\volker\test\) it does not install to 
this given folder. Instead the package is installed to a location where 
my root directory is (H:\PFiles\test\) where the PFiles component comes 
from the ProgramFilesFolder directory with short name "PFiles". I 
searched the archives and documentation but did not came up with a
solution.

How can I force my package to be installed in the correct directory?

Cheers Volker


sample package attached



http://schemas.microsoft.com/wix/2003/01/wi";>
   

 

 
 
 
   
 
   
 
 
   
 
   
 
   
 
   
   
 
   
 

 
   
   
 
 
 
 
   




-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Repairing an Installation

[Andreas Hellwig]

Hi,

I have a little problem with the installer I'm developing. It seems to 
be impossible to repair the installation without the original msi file. 
If I delete the msi file, repairing allways ends with the error "The 
feature you are trying to use is on a network resource that is 
unavailable.". I thought the Windows Installer is caching the original 
msi file. If it doesn't, is there a possibility to fix the repair option?

Andreas Hellwig

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] XmlFile CreateElement

[md5hans]

Hi!

I have a question about manipulating XML-files. I want to create a new
element inside an existing node, after the element is created I want to set
some attributes on it. 

My problem is that there already exists elements of the kind I want to add,
how can I make the setValue action work on the new element instead of on of
the existing? (the first one)

My XML-file have the following structure


   
   
   
   


And I want to create a new ChildNode element and set the Name value to "C".




when I try this it adds a new empty ChildNode element and modifies the name
of the "A" childnode. I suppose that it's not so suprisning since I do not
specify which ChildNode element that should be modified...

Should I set the value attribute in createElement and then use that value
(by using a XPath) when identifying the new child node where I want to set
the name attribute? If so, how do I set the Text value when defining a
XPath?

/Hans
-- 
View this message in context: 
http://www.nabble.com/XmlFile-CreateElement-tp17864933p17864933.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating COM+ components using Wix 3.0

[Roy Abou Assaly]

Fredrik Grohn-4 wrote:
> 
> There is a custom action library to do COM+ registration in WiX. For v2
> see the PubCA schema:
> http://wix.sourceforge.net/manual-wix2/pubca_xsd_index.htm
> 
> I am on the road, so I don't have an example ready to send, but if you
> search the list archive there should be something.
> 
> 

Thanks Fredrik.  I'll be checking it out this week.

Roy

-- 
View this message in context: 
http://www.nabble.com/Creating-COM%2B-components-using-Wix-3.0-tp17808293p17864754.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] External DLL Custom Action

[Dana Gutride]

The first thing you might want to check is it linked statically or
dynamically to the VC80 runtime libraries.  Changing to Visual Studio 2005
most likely introduced a dependency for you because of the C runtime
changes.  If you don't want to link statically to the CRT, you could also
use a bootstrapper to install the VC80 redistributable package prior to
running your install.

Dana

On Mon, Jun 16, 2008 at 5:47 AM, Natxo Mateos <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> I've coded a simple dll (where I do a registry search) to be used as a
> Custom Action. If I compile it with Visual Studio 2002, all works
> propertly, and during the installation, the dll is called. But if I try
> to use the VS 2005 compiler, the installer fails, displaying a message
> where alerts that some external dll couldn't be called.
>
> --
>
> Regards,
>
> *Natxo Mateos*
> [EMAIL PROTECTED]
>
> *Asuni CAD* - _www.asuni.es _ - 93 319 6868 - 91
> 541 6439
> *Especialistas en el desarrollo de aplicaciones a medida sobre AutoCAD*
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Properties

[Natxo Mateos]

Hi,

I've got one question related to properties. There is no other way to 
store and manipulate strings than using properties?

I have to implement the next sequence:

1. Access the registry
2. Use the value read to construct another string
3. Access to the key calculated in (2)
   
The problem is due that step (2) is done via a Custom Action, step (3) 
must be done in an external dll.
There no other way to achieve this, without having to call an external 
dll to search in the registry?

Thanks in advance,

-- 

Regards,

*Natxo Mateos*
[EMAIL PROTECTED]

*Asuni CAD* - _www.asuni.es _ - 93 319 6868 - 91 
541 6439
*Especialistas en el desarrollo de aplicaciones a medida sobre AutoCAD*

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] External DLL Custom Action

[Natxo Mateos]

Hi,

I've coded a simple dll (where I do a registry search) to be used as a 
Custom Action. If I compile it with Visual Studio 2002, all works 
propertly, and during the installation, the dll is called. But if I try 
to use the VS 2005 compiler, the installer fails, displaying a message 
where alerts that some external dll couldn't be called.

-- 

Regards,

*Natxo Mateos*
[EMAIL PROTECTED]

*Asuni CAD* - _www.asuni.es _ - 93 319 6868 - 91 
541 6439
*Especialistas en el desarrollo de aplicaciones a medida sobre AutoCAD*

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to force administrative install to INSTALLDIR

[Ryan O'Neill]

Hi,

I think I know whereabouts you have a problem but I can't give you precise
instructions. I suspect that what is happening is that your installdir and
other properties only get set in the UI sequence, without a UI then the
target directory is not set and you get it installed to the root.

You can set public properties (all caps) on the command line of msiexec for
admin installs. Otherwise you'll have to schedule the setting of targetdir
(or the relevant property) from your execute sequence table, but only if it
is not already set.

Hope that helps.

Ryan

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Volker
Enderlein
Sent: 16 June 2008 10:59
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to force administrative install to INSTALLDIR

Hi NG,

I am using the examples from the wix tutorial. When I try to perform an 
administrative install with such a package without UI ( msiexec /a 
package.msi INSTALLDIR=C:\users\volker\test\) it does not install to 
this given folder. Instead the package is installed to a location where 
my root directory is (H:\PFiles\test\) where the PFiles component comes 
from the ProgramFilesFolder directory with short name "PFiles". I 
searched the archives and documentation but did not came up with a solution.

How can I force my package to be installed in the correct directory?

Cheers Volker


sample package attached



http://schemas.microsoft.com/wix/2003/01/wi";>
   

 

 
 
 
   
 
   
 
 
   
 
   
 
   
 
   
   
 
   
 

 
   
   
 
 
 
 
   



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
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. 
Version: 8.0.100 / Virus Database: 270.3.0/1504 - Release Date: 15/06/2008
17:52


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to make the ProgramMenuDir configurable?

[Volker Enderlein]

Hi Markus,

thank you for your hint, I already discovered this when testing the 
package and found the solution you described after a long search.

Cheers Volker

Markus Wagner wrote:
> Hi Volker,
> 
> If you use a custom action to set a directory with a property value you have
> to ensure that you save the property value somewhere. Otherwise you have a
> problem during uninstall if the property has an other value than during
> install.
> 
> Unfortunatly you notice this not until the uninstall when your files will
> not be removed.
> 
> In my projects I save the property value in the registry. And it works fine.
> 
> Markus
> 
> 
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag von Volker
> Enderlein
> Gesendet: Freitag, 6. Juni 2008 20:59
> An: General discussion for Windows Installer XML toolset.
> Betreff: Re: [WiX-users] How to make the ProgramMenuDir configurable?
> 
> 
> Volker Enderlein schrieb:
>> Bob Arnson schrieb:
>>> Volker Enderlein wrote:
 i came across the idea of making the ProgramMenuDir configurable as
 InstallShield and other installers do. You can give a different name to 
 the program group. Is that possible in WiX and if yes how?
   
>>> Create a subdirectory of ProgramMenuFolder and you can give it any 
>>> name
>>> you want.
>>>
>> Thanks for your answer Bob, but I think I need to clarify the
>> difficulties I am facing.
>>
>> I know how to place a directory under the ProgramMenuFolder like
>>
>> 
>> 
>> 
>>
>> But say I have a property GROUPSEL which has been set in a UIDialog 
>> and
>> want to use this name. How would I do that?
>>
>> 
>>
>>
>>
>>
>>
>> 
>> 
>>
>> I searched the archives and the help manual, but don't find a properly
>> solution. Maybe it's simply related using the wrong keywords.
>>
>> Thank you, Cheers Volker
>>
> I knew I was missing some fundamentals of WiX. I found the answer 
> reading the wix tutorial a second time more carefully.
> 
> Value='[TARGETDIR]\Program Files\Acme\Foobar 1.0\bin' />
> 
> should do the trick.
> 
> Thanks agaín for your answer.
> 
> Keep up the good work, Cheers Volker
> 



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to force administrative install to INSTALLDIR

[Volker Enderlein]

Hi NG,

I am using the examples from the wix tutorial. When I try to perform an 
administrative install with such a package without UI ( msiexec /a 
package.msi INSTALLDIR=C:\users\volker\test\) it does not install to 
this given folder. Instead the package is installed to a location where 
my root directory is (H:\PFiles\test\) where the PFiles component comes 
from the ProgramFilesFolder directory with short name "PFiles". I 
searched the archives and documentation but did not came up with a solution.

How can I force my package to be installed in the correct directory?

Cheers Volker


sample package attached



http://schemas.microsoft.com/wix/2003/01/wi";>
   

 

 
 
 
   
 
   
 
 
   
 
   
 
   
 
   
   
 
   
 

 
   
   
 
 
 
 
   



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Ensuring services are running before install and cycling services after install

[Ryan O'Neill]

Hi all,

 

I am installing a printer driver and would like to cycle the Spooler service
after an install. This is not a problem as I understand how to use the
StartServices and StopServices scheduling elements in
InstallExecuteSequence.

 

The problem is that I want to ensure that the Spooler service is running
before I do any printer manipulation as some of the API calls need that
service running. I don't know how to have two sets of StartService.

 

Ideally the InstallExecuteSequence would run in the following order;

1)   Show UI

2)   Start spooler service

3)   Install printer driver, port monitor etc

4)   Stop Spooler service

5)   Start Spooler service

 

So, I need the Spooler service running in order to install the printer (and
for an install without errors) as some people have it disabled on their
machines.

I also need to cycle the Spooler service in case the printer port monitor
was already running and we had a previous version of the port monitor on
there (this will unload the DLLs that I copy and force them to reload for
the next print).

 

I suppose I could use 'net start spooler' somehow but this feels kind of
kludgy.

 

Opinions greatly appreciated.

 

Regards

 

Ryan

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixLib and WixVariable

[Wouter Demuynck]

Yes, I am getting the following error:

The WiX variable !(wix.ProductName) is unknown.  Please ensure the
variable is declared on the command line for light.exe, via a
WixVariable element, or inline using the syntax !(wix.ProductName=some
value which doesn't contain parenthesis).

I'm using the previous weekly release (v3.0.4207.0), and I'm having
the same issues when invoking Candle/Light from the command line
without using the Votive integration.

I have set up a simple solution to test this (all by using Votive
inside Visual Studio 2005):

Solution
Library Project:
  
  http://schemas.microsoft.com/wix/2006/wi";>

  
  
 
   

MSI Project (Library project referenced with project reference):
  
  http://schemas.microsoft.com/wix/2006/wi";>

  

  


  

  
  

  

  



  
  


  

Kind regards,

Wouter

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users