[WiX-users] RE : How to create an optional shortcut

[Jacquet Fabian]

Thank you for this explanation.

I don't really understand why you add a registry key...
Maybe I don't know what is a keypath

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Stuart A. Malone
Envoyé : vendredi 23 mars 2007 8:00
À : wix-users@lists.sourceforge.net
Objet : [WiX-users] How to create an optional shortcut



It looks like several people, including me, have asked recently how  
to create an optional shortcut -- that is, how to create a shortcut  
that is only installed if a checkbox is checked in the UI.  Thanks to  
some private help from another member of the list (who can identify  
himself if he'd like to), I now have a solution that seems to be  
working.  I thought I would share it with the list.

Please understand that I am fairly new to both WiX and Windows  
Installer, so some of this information may be inaccurate.  I welcome  
corrections to my understanding of what's going on and improvements  
to the technique.

The basic idea is to place the shortcut in a separate component, and  
then conditionalize the component.  There are a couple of tricks,  
however.

First, choose a unique property name that will control installation  
of the shortcut.  You probably want to name this property in all  
capital letters so that it is a public property, and can be set on  
the command line.  I chose INSTALLDESKTOPSHORTCUT.  If you want the  
shortcut to be installed by default, then include the line:



If you don't want the shortcut to be installed by default, then leave  
this property out.  Note that setting the property to "0" is NOT  
equivalent to leaving it unset.

Next, add a user interface for setting the property.  If you are  
using the standard WiX UI library, you may need to create a local  
copy of your chosen dialog in order to modify it.  In my case, I  
modified the InstallDirDlg and added:



If you are generating installers in multiple languages, you may want  
to use a localization variable rather than hard-wiring the text of  
the control.

Next, if you don't already have a Directory element for the folder  
where the shortcut will be placed, create one.  In my case, I want  
the shortcut on the desktop so I created the element:



directly under the toplevel Directory element of my installer.

Next, add a new conditional component for your shortcut.  This is one  
of the tricky parts to get right, both because the shortcut needs to  
point to a file in a different component, and because you need to  
create an artificial object to act as the KeyPath of the component.   
In this case, we create an otherwise unnecessary registry key to act  
as the KeyPath of the component, but an empty file would probably  
also work.  The exact path to the registry key is not important, but  
it should be unique and be in the conventional HKCU/Software/Company/ 
Product area of the registry.  This component should be an XML  
sibling to the component that it will be targeting.  In my case, it  
looks like this:


  INSTALLDESKTOPSHORTCUT
  
  

  
  


Note that "Life_Balance.exe" is the Id of the File element that I  
want the shortcut to point to.  Of course, you should substitute your  
own company, product, and file ids for the ones I have used here.

Lastly, you need to add the new component to the same feature that  
installs the target of the shortcut:



When you run Light to link the installer, you will get an ICE69  
warning that your shortcut targets a file in a different component.   
You can safely ignore this warning, since both components are in the  
same feature and will always be installed together.

I hope this information will save somebody out there some time and  
trouble.


Best wishes,

--Stuart A. Malone
   Llamagraphics, Inc.
   Makers of Life Balance personal coaching software
   http://www.llamagraphics.com/



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



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

Re: [WiX-users] Directories/Merge Modules

[Stefan Pavlik]

Hi Thomas

The C:\Windows\Installer\ folder is hidden system folder which is
used by Windows Installer INTERNALY. It means that you should not
install any files to this folder (I think).

Anyway, you should use the

to get the correct Windows folder location.

Regards

Stefan

Thomas Svare wrote:
> Hello,
> 
>  
> 
> I’m converting an existing InstallShield merge module to Wix.  This
> merge module puts some files in the Windows Installer cache directory to
> support maintenance operations.
> 
>  
> 
> My code is as follows:
> 
>  
> 
> 
> 
> 
> 
>  Name="{XX~" LongName="{----}">
> 
>  
> 
> 
> 
> .
> 
> .
> 
> 
> 
> 
> 
> 
> 
>
> 
> When installed the files go to
> C:\Installer\{----}, the Windows
> directory is ignored.  A verbose log show the WindowsFolder.guid
> property correctly but the files end up in the wrong place.
> 
>  
> 
> Any ideas on what I’m doing wrong?
> 
>  
> 
> Thanks,
> 
> Tom
-- 
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies s.r.o. | www.whitestein.com
Panenska 28 | 811 03 Bratislava | Slovak Republic
Main +421 2 5443-5502 | Direct +421 2 5930-0735

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

[WiX-users] Ways of downgrading

[Igor Lemsky]

In my product I need support functionallity of downgrading. For example,
after release of the version 2.0.5 and version 2.1.0 and after installing
2.1.0 user can install 2.0.5 and it installs correctly. But how to implement
this without bootstrapping, using only MSI functionality?
If I use major upgrade and RemoveExistingProducts it leave newer versions of
the files (for assemblies - due to version check, for other - modify date)
- if RemoveExistingProducts after InstallFinalize or little earlier. If
RemoveExistingProducts is before InstallInitialize, it removes files
entirely - because it uninstall them, but then not install, it was newer
versions of them...
Only way is to remove right after FindRelatedProducts but then we lost
Rollback functionality (if we cancel downgrade process - newer product will
not remain).

Of course there is way - minor upgrade and REINSTALL, but it also has some
limitations, or no?
Can anyone help me to find better way?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] RE : RE : Conditional shortcut

[Jacquet Fabian]

Here is an exemple





DesktopIcon = "1"
  


The only problem I have is DesktopIcon property is used in a dialog (with a 
checkbox control) and it doesn't change anything. Checked or not, the shortcut 
is installed only if I initialize DesktopIcon property to 1. I'm searching why. 

-Message d'origine-
De : Stuart A. Malone [mailto:[EMAIL PROTECTED] 
Envoyé : jeudi 22 mars 2007 17:16
À : Jacquet Fabian; wix-users@lists.sourceforge.net
Objet : Re: [WiX-users] RE : Conditional shortcut



Hello Jacquet,

Could you post a working example of that?

As you can see in my thread "Shortcut targeting file in a different  
component?", I've been trying to do exactly what you're describing,  
but have been unable to get it to work. I would certainly love to see  
an example of the correct syntax to do this.


Best wishes,

--Stuart A. Malone
   Llamagraphics, Inc.
   Makers of Life Balance personal coaching software
   http://www.llamagraphics.com/



On Mar 22, 2007, at 7:05 AM, Jacquet Fabian wrote:

> I found by myself.
>
> A short cut can contain a target attribute.
> So you can put the shortcut in a different component (And not only
> as child of file tag) and set a condition on this component.
>
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:wix-users-
> [EMAIL PROTECTED] De la part de Jacquet Fabian
> Envoyé : lundi 19 mars 2007 16:46
> À : wix-users@lists.sourceforge.net
> Objet : [WiX-users] Conditional shortcut
>
> Hi,
>
> I have to create a short cut to an exe file only if a text box is
> checked.
> I don't see a shortcut can have a condition child tag.
>
> How can I do this?
> --
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users







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

Re: [WiX-users] Accessing the Source Directory

[Anthony Wieser]

From: "Rob Mensching" <[EMAIL PROTECTED]>
To: "Geoff Finger" <[EMAIL PROTECTED]>; 
Sent: Friday, March 23, 2007 12:28 AM
Subject: Re: [WiX-users] Accessing the Source Directory


> Why are you copying files from the original media instead of just using the 
> File element?
> 

While I'm not the original poster on this, I considered doing the same, and was 
looking for a solution (though I've not implemented it).

I develop software which is distributed by a by a company who don't want a 
complicated build process.  As a result, I've given them a directory tree which 
has my installer and autorun.inf, and a couple of folders that contain customer 
specific calibration files.

In addition, we support customizable language files, which are installed into 
these extra folders as well.  All of these files are of the form: strings.XXX 
where XXX is the primary language identifier.  As a result, I don't need to 
know (and in fact don't) exactly which files are being sent to customers, yet 
the installation just works.

Because it's built this way, my client doesn't need to have build tools 
installed on their PC.  They just need to copy the customers calibration into 
the directory structure, and then copy the files to disk.  Most of the 
installation remains unchanged, and therefore under version control.

I was considering building a custom action that copied all of the files across 
from the installation folder, but if there's a better way, I'd love to hear it.

Anthony Wieser
Wieser Software Ltd


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

Re: [WiX-users] public properties, saving state

[Nitin Chaudhari]

Hi,

What do u mean by set the property based on a registry entry?

I have this property : 

And this Custom action which sets the above property



There is another custom action which uses the above property



The installation log shows the following:

…

Action start 19:08:22: LaunchConditions.

Action ended 19:08:22: LaunchConditions. Return value 1.

MSI (s) (48:C4) [19:08:22:819]: Doing action: GEN_XLS_PATH

MSI (s) (48:C4) [19:08:22:819]: Note: 1: 2205 2:  3: ActionText

Action 19:08:22: GEN_XLS_PATH.

Action start 19:08:22: GEN_XLS_PATH.

MSI (s) (48:C4) [19:08:22:819]: *PROPERTY CHANGE: Modifying EXCEL_PROGRAM
property. Its current value is 'DUMMY.EXE'. Its new value: 'D:\Program
Files\Microsoft Office\OFFICE11\Excel.exe'.*

Action ended 19:08:22: GEN_XLS_PATH. Return value 1.

MSI (s) (48:C4) [19:08:22:834]: Doing action: FindRelatedProducts

…

MSI (c) (B8:28) [19:08:36:835]: Doing action: LaunchExcel

MSI (c) (B8:28) [19:08:36:850]: Note: 1: 2205 2:  3: ActionText

Action 19:08:36: LaunchExcel.

Action start 19:08:36: LaunchExcel.

Action ended 19:08:36: Complete. Return value 1.

Action ended 19:08:36: INSTALL. Return value 1.

Action ended 19:08:36: LaunchExcel. Return value 1631.

Property(C): INSTALLDIR = C:\Program Files\GSR\Addin\

Property(C): *EXCEL_PROGRAM = DUMMY.EXE*

Property(C): TARGETDIR = F:\

…

The property was changed, but still while executing LaunchExcel it is being
shown as DUMMY.EXE

Any idea what is going wrong here?

Thanks,

Nitin Chaudhari



On 3/22/07, Lindsay Harris <[EMAIL PROTECTED]> wrote:


 Hi Chris, thanks for your reply, I have already started implementing it
that way, I guess I was hoping there was a more elegant solution.



Thanks,

Lindsay



*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 22, 2007 11:23 AM
*To:* Lindsay Harris; wix-users@lists.sourceforge.net
*Subject:* RE: [WiX-users] public properties, saving state



I don't know if the functionality you're thinking of exists, but
alternatively you could set the property based on a registry entry you set
during installation.



Chris


 --

*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Lindsay Harris
*Sent:* Thursday, March 22, 2007 1:33 PM
*To:* wix-users@lists.sourceforge.net
*Subject:* [WiX-users] public properties, saving state



Hi,



I was wondering, is there a certain way to define a public property so
that whatever value u give it on install for example, will still be there
when u initiate a repair, or modify, or uninstall.



For example, this is how I define a public property:







Is this expected behavior and I am doing something wrong?



Any advice would be appreciated,

Thanks,

Lindsay Harris

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


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

Re: [WiX-users] wix, C# installer class, uninstall

[Nitin Chaudhari]

Hi Dana,
Thanks for the reply, having $TheComponent=2 in my custom action did solve
the issue. So now the following works.


$MainDLL=2

$MainDLL=2


On similar lines I tried $MainDLL>2 for rollback and commit
actions... it did not seem to work...  any pointers to related
documentation.

My current install sequence is as follows :

   
 
 

 1

 $MainDLL>2
 $MainDLL>2

 $MainDLL>2
 $MainDLL>2

 $HelperLibrary>2
 $HelperLibrary>2

 $MainDLL>2
 $MainDLL>2

 $MainDLL=2
 $MainDLL=2

 
   

Thanks,
Nitin

On 3/23/07, Dana Gutride <[EMAIL PROTECTED]> wrote:


It might be a good idea to schedule this based on the state of the
component or feature.  That way you can tie the custom action's execution to
whether or not the specific component is being installed/uninstalled based
on that state.

$TheComponent=2 (component is being uninstalled)
$TheComponent>2 (component is being installed)

Read here for more info:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/conditional_statement_syntax.asp

Dana


On 3/22/07, Chris Bardon <[EMAIL PROTECTED]> wrote:

> Have you tried something like this:
>
> 
>After="MsiUnpublishAssemblies">INSTALLED
> 
>
> This should execute the action only if the product is installed.
>
> 
>
> From: [EMAIL PROTECTED]
> [mailto: [EMAIL PROTECTED] On Behalf Of Nitin
> Chaudhari
> Sent: Thursday, March 22, 2007 9:37 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] wix, C# installer class, uninstall
>
>
> I am using a C# installer class, during installation, I am able to call
> my C# install function, however I am not able hook uninstall in wix to
> call my C# uninstall function.
>
> In Wix, I am using the following XML to hook uninstall... but the MSI
> log shows that this custom action is being invoked during installation
> itself.
>  After="MsiUnpublishAssemblies">1
>
>  After="CA2.uninstall.SetProperty">1
>
> How can I ensure that my custom action is executed only on uninstall?
>
> Thanks,
>
> Nitin
>
>
> -
>
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>


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


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

Re: [WiX-users] FW: Directories/Merge Modules

[Rob Mensching]

I believe that but why are you putting stuff in the Windows directory?  If 
you're not part of Windows don't freakin' put stuff in the Windows directory 
(unless some Windows API puts stuff in the Windows directory, like installing 
assemblies to GAC).  And I mean that in the nicest sense.  


From: Thomas Svare [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 5:50 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules

Rob,

There have been some maintenance/uninstall issues with needing physical media 
that have be avoided by putting UI type dll's there.  I'll find out the entire 
history tomorrow and post.

I'm very interested to see if this is necessary or what the recommended course 
is for the situation.

Thanks,
Tom


From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 5:17 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules

You really should not be writing to the Installer directory.  Why are you doing 
that?

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules

Hello,

I've fixed my problem but I'm not entirely sure why the fix works and I'd like 
to know.  In fact, I made the change so I could search my verbose log a little 
easier.

I ended up changing the Directory Id and short name for the Guid directory to 
something like Xyz so that it would be easier to type a search string.



This solved my problem.  I'm not sure why.  I can only think the previous 
directory id was causing problems due to all caps and numerics or something 
like that.  I'd be interested to know what the issue was.

Thanks,
Tom

From: Thomas Svare
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules

Hello,

I'm converting an existing InstallShield merge module to Wix.  This merge 
module puts some files in the Windows Installer cache directory to support 
maintenance operations.

My code is as follows:






.
.




When installed the files go to 
C:\Installer\{----}, the Windows directory is 
ignored.  A verbose log show the WindowsFolder.guid property correctly but the 
files end up in the wrong place.

Any ideas on what I'm doing wrong?

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

Re: [WiX-users] FW: Directories/Merge Modules

[Thomas Svare]

Rob,

 

There have been some maintenance/uninstall issues with needing physical
media that have be avoided by putting UI type dll's there.  I'll find
out the entire history tomorrow and post.  

 

I'm very interested to see if this is necessary or what the recommended
course is for the situation.

 

Thanks,
Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 22, 2007 5:17 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules

 

You really should not be writing to the Installer directory.  Why are
you doing that?

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules

 

Hello,

 

I've fixed my problem but I'm not entirely sure why the fix works and
I'd like to know.  In fact, I made the change so I could search my
verbose log a little easier.

 

I ended up changing the Directory Id and short name for the Guid
directory to something like Xyz so that it would be easier to type a
search string.

 



 

This solved my problem.  I'm not sure why.  I can only think the
previous directory id was causing problems due to all caps and numerics
or something like that.  I'd be interested to know what the issue was.

 

Thanks,

Tom



From: Thomas Svare 
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules

 

Hello,

 

I'm converting an existing InstallShield merge module to Wix.  This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.

 

My code is as follows:

 







 



.

.









When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored.  A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.

 

Any ideas on what I'm doing wrong?

 

Thanks,

Tom

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

Re: [WiX-users] Accessing the Source Directory

[Rob Mensching]

Why are you copying files from the original media instead of just using the 
File element?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger
Sent: Thursday, March 22, 2007 3:45 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Accessing the Source Directory

I've been trying to figure out how to copy some files located in the
directory the msi file is being run from to the Install directory, the
big problem being that I couldn't find an easy way to fetch the value
of the source directory.

SourceDir leads to the root of the drive and CURRENTDIRECTORY isn't
accessible through Wix. Searching through the archives let to a lot of
suggestions involving the msi property OriginalDatabase, however that
includes the file name so there is the added complication of writing a
custom action to strip that off.

While looking through the log files after some experiments however I
noticed that SourceDir starts at the actual Source directory before
being truncated to just the root. I managed to use the following
custom action to grab the value before the truncation happens:



and in AdminUISequence:

NOT Installed

Since I didn't see that suggestion in response to any of the previous
similar questions I thought it might be useful to share.

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

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

[WiX-users] WIND ADVISORY REMAINS IN EFFECT UNTIL NOON ADT TODAY.

[Eustace]

MOSTLY CLOUDY WITH RAIN SHOWERS THROUGH THE MORNING. THE FLOOD ADVISORY FOR 
RAIN AND MELTING SNOW REMAINS IN EFFECT UNTIL 600 AM ADT FRIDAY FOR CAPE 
FAIRWEATHER TO CAPE SUCKLING COASTAL AREA. SOUTHEAST WINDS ARE EXPECTED TO 
INCREASE TO 20 TO 30 MPH WITH GUSTS TO 45 MPH BY LATE TONIGHT THROUGH FRIDAY 
MORNING.
WIND ADVISORY IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. EASTERN 
BARANOF ISLAND AND SOUTHERN ADMIRALTY ISLAND.
STORM DRAINS SHOULD BE KEPT CLEAR OF SNOW DEBRIS AS MUCH AS POSSIBLE. MOVE TO 
HIGHER GROUND. INNER CHANNELS FROM KUPREANOF ISLAND TO ETOLIN ISLAND. WIND 
ADVISORY IN EFFECT FROM 9 AM TO 6 PM ADT FRIDAY. A STRONG WEATHER SYSTEM 
FORECAST TO MOVE ACROSS THE PANHANDLE LATE TONIGHT AND EARLY FRIDAY.
JUNEAU BOROUGH AND NORTHERN ADMIRALTY ISLAND.
SOUTHWEST WIND 15 TO 25 MPH. JUNEAU 610 AM ADT THU MAR 22 2007 . WHICH IS IN 
EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. WIND ADVISORY IN EFFECT FROM 
9 PM THIS EVENING TO 12 PM ADT FRIDAY.
WHICH IS IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. A WIND ADVISORY 
MEANS THAT SUSTAINED WIND SPEED OR FREQUENT GUSTS WILL OCCUR BETWEEN 40 AND 60 
MPH. PELICAN 610 AM ADT THU MAR 22 2007 .
WIND ADVISORY REMAINS IN EFFECT UNTIL NOON ADT TODAY.
THE WATER DEPTH MAY BE TOO GREAT TO ALLOW YOUR CAR TO CROSS SAFELY. WIND 
ADVISORY IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY.
FLOOD ADVISORY REMAINS IN EFFECT UNTIL 6 PM ADT FRIDAY. THE FLOOD ADVISORY FOR 
RAIN AND MELTING SNOW REMAINS IN EFFECT UNTIL 600 AM ADT FRIDAY FOR CAPE 
FAIRWEATHER TO CAPE SUCKLING COASTAL AREA.
HAINES 610 AM ADT THU MAR 22 2007 .
This same information is available in other file formats including the XML 
based RSS and CAP formats.
IF YOU LIVE OR WORK NEAR A STEEP HILLSIDE PAY CLOSE ATTENTION TO CHANGING 
WEATHER AND SNOW CONDITIONS AND BE PREPARED TO LEAVE THE AREA IMMEDIATELY.
SOUTHEAST WIND 20 TO 30 MPH WITH GUSTS TO 45 MPH.
HAINES 610 AM ADT THU MAR 22 2007 .
FLOOD ADVISORY REMAINS IN EFFECT UNTIL 6 PM ADT FRIDAY.

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

[WiX-users] Accessing the Source Directory

[Geoff Finger]

I've been trying to figure out how to copy some files located in the
directory the msi file is being run from to the Install directory, the
big problem being that I couldn't find an easy way to fetch the value
of the source directory.

SourceDir leads to the root of the drive and CURRENTDIRECTORY isn't
accessible through Wix. Searching through the archives let to a lot of
suggestions involving the msi property OriginalDatabase, however that
includes the file name so there is the added complication of writing a
custom action to strip that off.

While looking through the log files after some experiments however I
noticed that SourceDir starts at the actual Source directory before
being truncated to just the root. I managed to use the following
custom action to grab the value before the truncation happens:



and in AdminUISequence:

NOT Installed

Since I didn't see that suggestion in response to any of the previous
similar questions I thought it might be useful to share.

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

Re: [WiX-users] FW: Directories/Merge Modules

[Rob Mensching]

You really should not be writing to the Installer directory.  Why are you doing 
that?

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules

Hello,

I've fixed my problem but I'm not entirely sure why the fix works and I'd like 
to know.  In fact, I made the change so I could search my verbose log a little 
easier.

I ended up changing the Directory Id and short name for the Guid directory to 
something like Xyz so that it would be easier to type a search string.



This solved my problem.  I'm not sure why.  I can only think the previous 
directory id was causing problems due to all caps and numerics or something 
like that.  I'd be interested to know what the issue was.

Thanks,
Tom

From: Thomas Svare
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules

Hello,

I'm converting an existing InstallShield merge module to Wix.  This merge 
module puts some files in the Windows Installer cache directory to support 
maintenance operations.

My code is as follows:






.
.




When installed the files go to 
C:\Installer\{----}, the Windows directory is 
ignored.  A verbose log show the WindowsFolder.guid property correctly but the 
files end up in the wrong place.

Any ideas on what I'm doing wrong?

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

[WiX-users] FW: Directories/Merge Modules

[Thomas Svare]

Hello,

 

I've fixed my problem but I'm not entirely sure why the fix works and
I'd like to know.  In fact, I made the change so I could search my
verbose log a little easier.

 

I ended up changing the Directory Id and short name for the Guid
directory to something like Xyz so that it would be easier to type a
search string.

 



 

This solved my problem.  I'm not sure why.  I can only think the
previous directory id was causing problems due to all caps and numerics
or something like that.  I'd be interested to know what the issue was.

 

Thanks,

Tom



From: Thomas Svare 
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules

 

Hello,

 

I'm converting an existing InstallShield merge module to Wix.  This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.

 

My code is as follows:

 







 



.

.









When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored.  A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.

 

Any ideas on what I'm doing wrong?

 

Thanks,

Tom

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

[WiX-users] How to create an optional shortcut

[Stuart A. Malone]

It looks like several people, including me, have asked recently how  
to create an optional shortcut -- that is, how to create a shortcut  
that is only installed if a checkbox is checked in the UI.  Thanks to  
some private help from another member of the list (who can identify  
himself if he'd like to), I now have a solution that seems to be  
working.  I thought I would share it with the list.

Please understand that I am fairly new to both WiX and Windows  
Installer, so some of this information may be inaccurate.  I welcome  
corrections to my understanding of what's going on and improvements  
to the technique.

The basic idea is to place the shortcut in a separate component, and  
then conditionalize the component.  There are a couple of tricks,  
however.

First, choose a unique property name that will control installation  
of the shortcut.  You probably want to name this property in all  
capital letters so that it is a public property, and can be set on  
the command line.  I chose INSTALLDESKTOPSHORTCUT.  If you want the  
shortcut to be installed by default, then include the line:



If you don't want the shortcut to be installed by default, then leave  
this property out.  Note that setting the property to "0" is NOT  
equivalent to leaving it unset.

Next, add a user interface for setting the property.  If you are  
using the standard WiX UI library, you may need to create a local  
copy of your chosen dialog in order to modify it.  In my case, I  
modified the InstallDirDlg and added:



If you are generating installers in multiple languages, you may want  
to use a localization variable rather than hard-wiring the text of  
the control.

Next, if you don't already have a Directory element for the folder  
where the shortcut will be placed, create one.  In my case, I want  
the shortcut on the desktop so I created the element:



directly under the toplevel Directory element of my installer.

Next, add a new conditional component for your shortcut.  This is one  
of the tricky parts to get right, both because the shortcut needs to  
point to a file in a different component, and because you need to  
create an artificial object to act as the KeyPath of the component.   
In this case, we create an otherwise unnecessary registry key to act  
as the KeyPath of the component, but an empty file would probably  
also work.  The exact path to the registry key is not important, but  
it should be unique and be in the conventional HKCU/Software/Company/ 
Product area of the registry.  This component should be an XML  
sibling to the component that it will be targeting.  In my case, it  
looks like this:


  INSTALLDESKTOPSHORTCUT
  
  

  
  


Note that "Life_Balance.exe" is the Id of the File element that I  
want the shortcut to point to.  Of course, you should substitute your  
own company, product, and file ids for the ones I have used here.

Lastly, you need to add the new component to the same feature that  
installs the target of the shortcut:



When you run Light to link the installer, you will get an ICE69  
warning that your shortcut targets a file in a different component.   
You can safely ignore this warning, since both components are in the  
same feature and will always be installed together.

I hope this information will save somebody out there some time and  
trouble.


Best wishes,

--Stuart A. Malone
   Llamagraphics, Inc.
   Makers of Life Balance personal coaching software
   http://www.llamagraphics.com/



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

Re: [WiX-users] wix, C# installer class, uninstall

[Dana Gutride]

It might be a good idea to schedule this based on the state of the component
or feature.  That way you can tie the custom action's execution to whether
or not the specific component is being installed/uninstalled based on that
state.

$TheComponent=2 (component is being uninstalled)
$TheComponent>2 (component is being installed)

Read here for more info:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/conditional_statement_syntax.asp

Dana


On 3/22/07, Chris Bardon <[EMAIL PROTECTED]> wrote:


Have you tried something like this:


  INSTALLED


This should execute the action only if the product is installed.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nitin
Chaudhari
Sent: Thursday, March 22, 2007 9:37 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] wix, C# installer class, uninstall


I am using a C# installer class, during installation, I am able to call
my C# install function, however I am not able hook uninstall in wix to
call my C# uninstall function.

In Wix, I am using the following XML to hook uninstall... but the MSI
log shows that this custom action is being invoked during installation
itself.
1

1

How can I ensure that my custom action is executed only on uninstall?

Thanks,

Nitin


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

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

[WiX-users] Directories/Merge Modules

[Thomas Svare]

Hello,

 

I'm converting an existing InstallShield merge module to Wix.  This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.

 

My code is as follows:

 







 



.

.









When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored.  A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.

 

Any ideas on what I'm doing wrong?

 

Thanks,

Tom

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

[WiX-users] The vocals are heartfelt, really pretty and to a nice musical and rhythmical backdrop.

[Brock Joachim]

It's so easy to get lost in this song when you hear it.
Of course there are far more french wines that I'm willing to drink than movies 
I'm willing to watch - but lets not ruin the plan here.
Still it may not all be obvious. 2007  20:31:57leckerDer vorbereitende Einkauf 
will bedacht sein. It's all lovely stuff. they cycle to work), those who are 
serious about exercising (they're regularly logging exercise) and those who 
occasionally exercise. ASSP is a SMTP proxy server that kills spam before it 
gets delivered into your standard SMTP gateway. With it's slow progression you 
feel like you're being pushed along by the ebbs and whorls of a river on a 
summer's day.
With it's slow progression you feel like you're being pushed along by the ebbs 
and whorls of a river on a summer's day. As if I couldn't buy 10 not in a book 
(heaven forbid!
You can't help but tap your feet and chuckle. homelstrial Grapes)) Blog started 
2. I assumed, given all the media coverage, that I'd be getting these new 
Permanent stamps.
If you don't know what those young kids are listening to at their discotheques, 
you should have a listen to this one.
Definitely worth a look if you make a lot of ppt files and may want to make 
them more globally accessible. Sit back and enjoy the ride on this one.
This has certainly damaged their image in my eyes.
creating web based presentations instead of Microsoft specific ones. Don't 
expect anything but fun from this movie - sit down and enjoy. There's an even 
more interesting turbine coming (no specs, details, costs yet) called 
StormBlade which provides a jet-like turbine rather than the prop(ellar) kind.

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

[WiX-users] ALL PERSONS WITH INTERESTS ALONG THESE RIVERS SHOULD MONITOR THE LATEST FORECASTS.

[Samson C . Wood]

MOTORISTS MUST REMAIN ALERT AS ANY ADDITIONAL RISES MAY PUT WATER OVER
THE ROAD OR PUSH DEBRIS INTO THE DRIVING LANES.
0 QUINCY   17   15. 1 FEET WAS BELOW THE 9 FOOT FLOOD STAGE.
VANDALIA 535 AM CDT THU MAR 22 2007 .
AND IF THESE STORMS DO STRENGTHEN LARGE HAIL AND DAMAGING WINDS WILL BE
POSSIBLE. THIS FLOOD WARNING IS A RESULT OF LESS THAN A HALF INCH OF
RAIN THE PAST 24 HOURS AND AROUND AN INCH OF RAIN IN THE NEXT 24 HOURS.
8 CLARKSVILLE 24   25   24. DENSE FOG IN SOUTHEAST MISSISSIPPI THIS
MORNING.
WHEN ENCOUNTERING FLOODED ROADS.
OR LOW WATER CROSSINGS. THE THREAT FOR OVERLAND FLOODING IN RICHLAND
COUNTY WILL CONTINUE.
IT DOES NOT APPEAR THAT FLOOD STAGE WILL BE REACHED.
SOME OF THE STREAMS AND CREEKS THAT WILL BE AFFECTED BY THE HEAVY
RAINFALL ARE STRAIGHT CREEK AND JONES CREEK.
DO NOT DRIVE INTO AREAS WHERE WATER TOPS THE ROADWAY. BENTON COUNTY IN
CENTRAL MISSOURI.
MILLER COUNTY IN CENTRAL MISSOURI. THE WATER DEPTH MAY BE TOO GREAT TO
ALLOW YOUR CAR TO CROSS SAFELY. WHITESIDE AND IN MISSOURI. SEVERE
THUNDERSTORM WATCH 67 IN EFFECT UNTIL 1 PM EDT THIS AFTERNOON.
AND FLOWING FREELY INTO FIELDS.
1 FEET WAS BELOW THE 9 FOOT FLOOD STAGE. AND BE PREPARED TO TAKE THE
NECESSARY PRECAUTIONS TO PROTECT LIFE AND PROPERTY FROM RISING WATER
LEVELS. IT DOES NOT APPEAR THAT FLOOD STAGE WILL BE REACHED.
THE TAIL END OF A COMPLEX OF THUNDERSTORMS WILL GRAZE AREAS NORTH OF A
HILLSDALE LAKE TO PLEASANT HILL LINE WITH SOME LIGHT SHOWERS.
THE WATER DEPTH MAY BE TOO GREAT TO ALLOW YOUR CAR TO CROSS SAFELY.
THE WATER DEPTH AND ROAD CONDITION MAY BE UNSAFE. THE RUNOFF WILL
COMPOUND HIGH WATER LEVELS FROM SNOW MELT. DO NOT ATTEMPT TO CROSS WATER
COVERED BRIDGES.
0 WINFIELD LD 25   26   24.
AND SOME OF THESE STORMS WILL PRODUCE BRIEF HEAVY DOWNPOURS. THE THREAT
FOR OVERLAND FLOODING IN RICHLAND COUNTY WILL CONTINUE.
5 TO 1 INCH FORECAST IN THE NEXT 24 HOURS.
THIS FLOOD STATEMENT INCLUDES FORECASTS FOR THE RED RIVER AT FARGO. A
FLASH FLOOD WARNING MEANS THAT FLOODING IS IMMINENT OR OCCURRING.
DENSE FOG ADVISORY IN EFFECT UNTIL 9 AM CDT THIS MORNING.
A RIVER FLOOD WARNING REMAINS IN EFFECT FOR THE RED RIVER AT FARGO FOR
MINOR FLOODING.
ISOLATED STORMS WILL AFFECT AREAS NEAR MCLEANSBORO.


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

[WiX-users] Creating a "semi-automated" install with Wix-setting properties in advance

[Chris Bardon]

I'm working on replacing an existing setup procedure with a Wix
installer, and I think I have almost all of the components I need.  The
one thing I'm missing however, is a piece of functionality we have in
Installshield that's pretty important to how our applications are
delivered.  We have a client application that is published on an
intranet site for a particular customer.  The MSI is built once, but
then the install package is customized by creating an SFX file with the
installshield MSI, bootstrapper, and an install.ini file that contains
settings specific to that customer.  This allows some information
(server connection parameters etc) to be pre-filled in the installer for
each site, rather than forcing users to know the information ahead of
time.  
 
The approach I've started looking at is to duplicate the installscript
logic using a custom DLL, but I've run into problems with shipping a DLL
alongside the MSI.  Evidently if a DLL is launched by an MSI, the
working directory of the DLL (where I'm looking for my settings file) is
NOT the same as the directory of the MSI (which would be the directory
the sfx extracts to).  I'm certainly not tied to this solution though,
and I'm wondering if anyone has a better method that would let someone
quickly customize an installer without having to run a compiler on it
(although I've thought of this as an option as well-batch file shortcut
to the WiX compiler/linker with a fragment that sets the relevant
properties).  
 
I'd appreciate any thoughts on how to accomplish this.  I know that you
can pass properties in on the command line, and that's the solution I'm
proposing for active directory based installs, but the majority of our
users don't have AD, so we need a way for our deployment guys to quickly
modify these installers for different sites.  
 
Thanks for your suggestions,
 
Chris
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive

[Justin Rockwood]

Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into
that.

As far as forcing a recompile... You can do that by including your inputs
into your .wixproj project file as  elements. In Votive, you do
this by selecting "Content" from the Build Type property in the property
browser (hit F4 if it's not showing). If you're working just with the
MSBuild .wixproj file, you can just add Relative path to
file in an  section. When compiling, I account for the
 elements to trigger a rebuild if they change.

Justin

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser
Sent: Thursday, March 22, 2007 4:12 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problems with Post Build Step and Dependencies in
Votive

Hi,

I'm trying to set up my project to automatically sign my msi files, so I've
added a a post build step that looks like this:
signcode   -t
http://timestamp.verisign.com/scripts/timstamp.dll
$(TargetDir)AutoSharesWx.msi

and the run post build event is set to:
"When the build updates the project output
That all seems to work fine, though you get a strange error if the build
fails:
1>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(360,7): Error
MSB4057: The target "_TimeStampAfterCompile" does not exist in the project.

Ignoring that though, what I really want to be able to do is set
dependencies on my Votive project to force it to recompile when my inputs
change (say A.exe as an example).  I've tried adding A.exe as a reference,
but that doesn't work, nor does adding it as an embedded resource in the
project.

I must be missing something.

Anthony Wieser
Wieser Software Ltd


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


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

Re: [WiX-users] public properties, saving state

[Lindsay Harris]

Hi Chris, thanks for your reply, I have already started implementing it that 
way, I guess I was hoping there was a more elegant solution.

Thanks,
Lindsay

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 11:23 AM
To: Lindsay Harris; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] public properties, saving state

I don't know if the functionality you're thinking of exists, but alternatively 
you could set the property based on a registry entry you set during 
installation.

Chris


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lindsay Harris
Sent: Thursday, March 22, 2007 1:33 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] public properties, saving state

Hi,

I was wondering, is there a certain way to define a public property so that 
whatever value u give it on install for example, will still be there when u 
initiate a repair, or modify, or uninstall.

For example, this is how I define a public property:



Is this expected behavior and I am doing something wrong?

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

Re: [WiX-users] public properties, saving state

[Chris.Rowland]

I don't know if the functionality you're thinking of exists, but
alternatively you could set the property based on a registry entry you
set during installation.

 

Chris

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lindsay
Harris
Sent: Thursday, March 22, 2007 1:33 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] public properties, saving state

 

Hi,

 

I was wondering, is there a certain way to define a public property so
that whatever value u give it on install for example, will still be
there when u initiate a repair, or modify, or uninstall.

 

For example, this is how I define a public property:



 

 

Is this expected behavior and I am doing something wrong?

 

Any advice would be appreciated,

Thanks,

Lindsay Harris 

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

[WiX-users] XmlConfig - "Unexpected child element" error

[Callum Hibbert]

Hello,

I'm new to WiX though I have some simple installers working.

I am trying to get the XmlConfig Element to work but I get an "element
contains unexpected child element" error when I use the "XmlConfig" element.
I can't find much on Google or the Archives, there are some mentions but no
satisfactory resolutions.

I've tried importing the util schema but then I get an error saying
extensions are not allowed.

I'm hand cranking the wxs file (I'm not using Votive), can some tell me how
to "enable" use of the "XmlConfig" element.

Thanks,

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

[WiX-users] public properties, saving state

[Lindsay Harris]

Hi,

I was wondering, is there a certain way to define a public property so that 
whatever value u give it on install for example, will still be there when u 
initiate a repair, or modify, or uninstall.

For example, this is how I define a public property:



Is this expected behavior and I am doing something wrong?

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

[WiX-users] Compnonant Condition

[Jacquet Fabian]

Do you know when is evaluated a condition in a Component?

 

I have a condition on a property which is changed in the UI and the
result of this condition doesn't change with the UI choice.

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

Re: [WiX-users] RE : Conditional shortcut

[Stuart A. Malone]

Hello Jacquet,

Could you post a working example of that?

As you can see in my thread "Shortcut targeting file in a different  
component?", I've been trying to do exactly what you're describing,  
but have been unable to get it to work. I would certainly love to see  
an example of the correct syntax to do this.


Best wishes,

--Stuart A. Malone
   Llamagraphics, Inc.
   Makers of Life Balance personal coaching software
   http://www.llamagraphics.com/



On Mar 22, 2007, at 7:05 AM, Jacquet Fabian wrote:

> I found by myself.
>
> A short cut can contain a target attribute.
> So you can put the shortcut in a different component (And not only  
> as child of file tag) and set a condition on this component.
>
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:wix-users- 
> [EMAIL PROTECTED] De la part de Jacquet Fabian
> Envoyé : lundi 19 mars 2007 16:46
> À : wix-users@lists.sourceforge.net
> Objet : [WiX-users] Conditional shortcut
>
> Hi,
>
> I have to create a short cut to an exe file only if a text box is  
> checked.
> I don't see a shortcut can have a condition child tag.
>
> How can I do this?
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users






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

Re: [WiX-users] Microsoft Setup Analysis Tool

[Michael Saupe]

Yes, I tried the Validate option in Orca.
The Orca validation result is: no errors or warnings.

But I get the mentioned error using the Microsoft Setup Analysis Tool.

Regards,
Michael

 Original-Nachricht 
Datum: Thu, 22 Mar 2007 15:29:33 +0100
Von: "Albert van Peppen" <[EMAIL PROTECTED]>
An: "Michael Saupe" <[EMAIL PROTECTED]>, wix-users@lists.sourceforge.net
Betreff: RE: [WiX-users] Microsoft Setup Analysis Tool

>  
> 
> Did you try the Validate option in Orca?
> It will show you all ICE errors and warnings ;)
> 
> Regards,
> 
> Albert
> 
> -Oorspronkelijk bericht-
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Namens Michael Saupe
> Verzonden: donderdag 22 maart 2007 13:41
> Aan: wix-users@lists.sourceforge.net
> Onderwerp: [WiX-users] Microsoft Setup Analysis Tool
> 
> Hello,
> 
> I've created an application installer with WiX toolset (v2.0).
> Everything works fine during my tests.
> 
> But today I tested the installer with the Microsoft Setup Analysis Tool
> (SAT) (included in the Microsoft Application Compatibility Toolkit) and
> I got the error message "setup_installer.msi did not run successfully.
> ERROR: The run did not complete successfully.".
> 
> What could be the problem?
> 
> Btw: When I tested the samples of the WiX tutorial, I got the same error
> message.
> 
> Any input would be very helpful.
> 
> Regards,
> Michael
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT Join
> SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

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

[WiX-users] "vital" file not installed and no error

[Chris.Rowland]

I'm testing a scenario where our software has been installed with the
old installer, and I install a newer version of the software over top of
it using the wix 2.0  based installer.

 

I wanted to test that if a file could not be written it would cause an
error of some sort.  Every file in my install is marked as Vital="yes"
so I believe it should fail if a file cannot be written.

 

 

To test this, I opened the previously installed readme.txt in word.  I
tried to copy over it with drag & drop and got an error that the file
was in use.  Seems to be the type of situation I want to test.

 

So, I perform the install with the new installer, and everything appears
to succeed.  I look in the installation directory, and I can confirm
that some files were replaced, but the readme.txt file was not.  The
install log gives no indication of the file being in use, and no prompt
was made to restart.

 

I then run the installer again and select remove.  Uninstallation DOES
fail this time, complaining that the file is in use.

 

Did I go wrong somewhere, or is this the expected behavior?

 

Chris Rowland* Software Engineer * SunGard * Data Management Solutions *
1194 Oak Valley Drive, Suite 100 * Ann Arbor, MI 48108 * Tel
734.332.4423 * Fax 734.332.4440 *
http://www.sungard.com/datamanagementsolutions
 

 

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

Re: [WiX-users] simple custom action DLL-not being called?

[Rob Hamflett]

Chris Bardon wrote:
 > Is there a convention for where these types of things should go?

The thing with Custom Actions is that they're there for when you want to do 
unconventional things, 
so I guess you just put them wherever they need to be.  The only thing of note 
is that a CA that 
modifies the system should be deferred and run between InstallInitialize and 
InstallFinalize in the 
InstallExecuteSequence.

Rob


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

Re: [WiX-users] Registering COM object - unhandled extension element in v3

[Bob Arnson]

Rob Hamflett wrote:
> There's a download for Votive 2.0.4820 available.  I've got 2.0.4415 
> installed.  I don't use the any 
> of the project stuff, but it is good for the Intellisense.
>   

In the WiX v3 installer, the schemas for IntelliSense can be installed 
without Votive. But they're the WiX v3 schemas. You can't have both 
Votive v2 and v3 installed at the same time.

-- 
sig://boB
http://bobs.org



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

Re: [WiX-users] One other questions abotu installation

[Bob Arnson]

Friedrich Dominicus wrote:
> This suggest that maybe the setup.exe may be used to first install the
> merge module and after that the installer. Is it supposed to work that
> way? 
>   

Merge modules are only installed when merged into an .msi installer. 
They're not standalone entities. That topic shows how to create an 
installer that consumes (merges) the merge module.

-- 
sig://boB
http://bobs.org



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

Re: [WiX-users] RE : RE : Reboot to replace files

[Bob Arnson]

Jacquet Fabian wrote:

I'm sorry, the exact error message is:
"The Windows Installer service cannot update the system file 
c:\WINDOWS\System32\mfc42.dll because the file is protected by 
Windows. You may need to update your operating system for this program 
to work correctly"
 
When the installation was done with a vb6 program, we called a method 
which copy the file during next boot.


That didn't do anything, though -- Windows File Protection restores 
system files back to a known state. Only service packs can install 
updated system files. See http://support.microsoft.com/kb/222193.


--
sig://boB
http://bobs.org

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

Re: [WiX-users] XmlFile and Votive?

[Bob Arnson]

Chris Bardon wrote:
> The first attempt tells me that the namespace prefix "Util" (upper or
> lower case) isn't defined, and the fully qualified example says that the
> component element contains an unexpected child element.  All I did for
> the DLL was to reference WixUtilExtension and rebuild-is there another
> line I need to add to the wix source to include the schema extensions
> (similar to a using directive or an #include)?  
>   

It definitely needs to be "util." I'm not that familiar with Votive, but 
I believe that's how it should work. Which version of WiX are you using?

-- 
sig://boB
http://bobs.org



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

Re: [WiX-users] simple custom action DLL-not being called?

[Chris Bardon]

Ah, I think I solved it.  Moved the tag from the InstallExecuteSequence
section to the InstallUISequence one, and it executed like it was
supposed to.  Is there a convention for where these types of things
should go?  I want to populate some property values from an included XML
file before installing, and I was thinking about putting the custom
action before AppSearch.  Are there any reasons not to do this?  
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Bardon
Sent: Thursday, March 22, 2007 10:52 AM
To: Rob Hamflett; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] simple custom action DLL-not being called?

Looks like it.  I had a #pragma in there similar to the one in the
sample at http://www.tramontana.co.hu/wix/lesson3.php#3.3 (#pragma
comment(linker, "/EXPORT:[EMAIL PROTECTED]")), but I tried adding a .def
file in addition to that-still nothing.

When I check the verbose log, I don't even see the installer attempting
to call the custom action.  Shouldn't it at least show a failure if it
can't be found? 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Thursday, March 22, 2007 10:01 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] simple custom action DLL-not being called?

Is the entry point exposed properly?  Either through a definition file,
or I think the other way is through a pragma.

Rob

Chris Bardon wrote:
> I'm trying to create a custom DLL that sets an installer property that

> the user can then modify, so I tried starting with a simple example:
>  
> extern "C" UINT __stdcall TestFn(MSIHANDLE hInstall) {
>   MsiSetProperty(hInstall,TEXT("AGENTID"),TEXT("AgentID from
DLL"));
>   return ERROR_SUCCESS;
> }
> 
> I can compile/link the DLL just fine, and then I refer to it in my Wix

> source like so:
> 
>  
>  Return="check" Execute="immediate" />
> 
>   
>
> 
> 
> When I run the installer though, the property doesn't seem to be set 
> by the action, and if I check the trace, nothing in the log seems to 
> even indicate that the custom action ran.  Is there something else 
> that I need to do to get a custom DLL to be called?
> 
> Thanks,
> 
> Chris
> 
> 
>  
> 
> 
> --
> --- Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to share 
> your opinions on IT & business topics through brief surveys-and earn 
> cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV
> DEV



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


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

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

Re: [WiX-users] simple custom action DLL-not being called?

[Chris Bardon]

Looks like it.  I had a #pragma in there similar to the one in the
sample at http://www.tramontana.co.hu/wix/lesson3.php#3.3 (#pragma
comment(linker, "/EXPORT:[EMAIL PROTECTED]")), but I tried adding a .def
file in addition to that-still nothing.

When I check the verbose log, I don't even see the installer attempting
to call the custom action.  Shouldn't it at least show a failure if it
can't be found? 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Thursday, March 22, 2007 10:01 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] simple custom action DLL-not being called?

Is the entry point exposed properly?  Either through a definition file,
or I think the other way is through a pragma.

Rob

Chris Bardon wrote:
> I'm trying to create a custom DLL that sets an installer property that

> the user can then modify, so I tried starting with a simple example:
>  
> extern "C" UINT __stdcall TestFn(MSIHANDLE hInstall) {
>   MsiSetProperty(hInstall,TEXT("AGENTID"),TEXT("AgentID from
DLL"));
>   return ERROR_SUCCESS;
> }
> 
> I can compile/link the DLL just fine, and then I refer to it in my Wix

> source like so:
> 
>  
>  Return="check" Execute="immediate" />
> 
>   
>
> 
> 
> When I run the installer though, the property doesn't seem to be set 
> by the action, and if I check the trace, nothing in the log seems to 
> even indicate that the custom action ran.  Is there something else 
> that I need to do to get a custom DLL to be called?
> 
> Thanks,
> 
> Chris
> 
> 
>  
> 
> 
> --
> --- Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to share 
> your opinions on IT & business topics through brief surveys-and earn 
> cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV
> DEV



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

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

[WiX-users] One other questions abotu installation

[Friedrich Dominicus]

Just rereading a few pages On 
http://msdn2.microsoft.com/en-us/library/aw2dz878(VS.80).aspx
One can read 

To deploy to another computer

|1.
| 
|   In Windows Explorer, navigate to your project directory and
| find the built installer. The default path will be \Documents and
| Settings\yourloginname\My Documents\Visual Studio
| 2005\Projects\Solution Folder Name\My Notepad Installer\project
| configuration\My Notepad Installer.msi. The default project
| configuration is Debug or Release. 
|2.
| 
|   Copy Merge Module Installer.msi, Setup.exe, and all other
| files and subdirectories in the directory to another computer. 
|   NoteNote
| 
|   To install on a computer that is not on a network, copy the
| files to traditional media such as CD-ROM. 
| 
|   On the target computer, double-click the Setup.exe file to run the 
installer.
|   NoteNote
| 
|   You must have install permissions on the target computer in
| order to run the installer.
| 

This suggest that maybe the setup.exe may be used to first install the
merge module and after that the installer. Is it supposed to work that
way? 

Regards
Friedrich

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

Re: [WiX-users] Microsoft Setup Analysis Tool

[Albert van Peppen]

 

Did you try the Validate option in Orca?
It will show you all ICE errors and warnings ;)

Regards,

Albert

-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Michael Saupe
Verzonden: donderdag 22 maart 2007 13:41
Aan: wix-users@lists.sourceforge.net
Onderwerp: [WiX-users] Microsoft Setup Analysis Tool

Hello,

I've created an application installer with WiX toolset (v2.0).
Everything works fine during my tests.

But today I tested the installer with the Microsoft Setup Analysis Tool
(SAT) (included in the Microsoft Application Compatibility Toolkit) and
I got the error message "setup_installer.msi did not run successfully.
ERROR: The run did not complete successfully.".

What could be the problem?

Btw: When I tested the samples of the WiX tutorial, I got the same error
message.

Any input would be very helpful.

Regards,
Michael
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out


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

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

Re: [WiX-users] Just a question out of frustration

[Friedrich Dominicus]

<[EMAIL PROTECTED]> writes:


> 1) At first I installed the difxapp tools
>- Howerver it is unclear to me if a printer falls under it's
> requirements.
>
> [Snip]
>
> I assume Printer falls under PlugAndPlay.
>
> RJF: That was also my assumption, but as mentioned before I have not
> worked with printer drivers and so I am starting from a position of
> ignorance!
Well I spend the last few weeks on it and am not much more foxy yet.
>
> 2) then wix2 and wix3 (I have not idea really what one to prefer)
>
> RJF: WiX2 is considered "Stable", i.e. it is unlikely that any updates
> will require you to make significant modifications to your source files.
> Rob has stated that WiX3 is getting to that point, but that there may
> still be some breaking changes. If you want to ship to customers in the
> next 3-6 months, I think I would choose to stay with WiX2. (According to
> the documentation, the DIFxApp.wixlib is supported under WiX2 or
 > later).
I'm currently using wix-2

>
> RJF: I'm not sure what a co-installer is. If you mean a separate package
> to perform part of the installation, then I would certainly hope not.
> You may still need a custom action after installing the driver to
> actually set up a printer, and if there isn't already one available and
> tested by others than I think it would be a very good thing (if
> possible) to create one collaboratively for the benefit of the entire
> WiX community.
AFAIK there is no such thing... Howerver I wanted also to add a special port
and Port Monitor
>
> - Am I expected to write any other special "setup" routine
> I can't tell and that makes me aggressive. Why the hell couldn't that
> be documented? No don't say check the examples. The examples do not
> help the slighest. The give you some .inf file and say use this or
> that for installation.
>
> RJF: I would have to agree. From my brief look at the documentation it
> isn't at all clear. Unfortunately every company (including Microsoft)
> has limited resources, and I can completely understand why thy might
> concentrate their documentation efforts on areas that are important to
> more customers. The other possibility is that the people who wrote the
> documentation create this type of installation so frequently that they
> have failed to mention steps and assumptions which are "trivial" to
> them, but not to us.
Well maybe that is so but if they wrote such stuff over and over again
would it be so terrible hard to have one example included? I just can
tell they say use the Print Add Wizzard. Of course that's what End
user can and will do but it's not much help if you want an installer 
doing that all...

>
> - the mentionin of core drivers has meant to me that I can expect that
> the needed files (unidrv.dll) are installed on any Vista. So I do
> not have to provide them in my installer. But that's  guess, it's not
> stated anywhere I have looked explicitly. So maybe I'm wrong about
> this assumption
>
> RJF: That may be true for Vista, but unless you are creating a
> constrained Vista only install it's a very bad assumption to make.
In this case I'm just interested in VISTA stuff. I'm not going another
round just for the fun of it to see wether I can make it work for
older Versions..., and well it's not needed because the old installer
works for Windows form W95 up to WS2003, so no current need to add
Vista. Howerver that installation is just a Dialog box and all the
things are installed programmatically. It's easy to understand and
easy to extend... 


> The
> basic rule for a robust installation should be to assume almost nothing.
> With the exception of the assumption that you are running on a given
> version of Microsoft Installer (or later), and that Microsoft Installer
> is operating correctly you should explicitly verify other prerequisites,
> and minimize dependencies on anything external to the MSI file.
That's probably a good idea. And as written I "partially" solved it
that way. Howerver that is not what the docs are saying, see e.g
http://msdn2.microsoft.com/en-us/library/206sadcd(VS.80).aspx


> 5) Now it's getting realyl messy. After the driver is installed I want
> the setup to add a Printer symbol. As written before I can not see how
> to achieve that without using a custom action. 
>
> RJF: And it is entirely possible that a custom action is required.
> Custom actions should (IMHO) always be linked statically, simply because
> there are no guarantees that a particular version of a given runtime (or
> even any version) is present on the machine where the installation will
> be run.
Well I can not see that suggestion anywhere. It's just that I've
learned it the "hard" way.
>
> the comment at the end is very encouriging. Yes I know I have
> Installer larger than 3 available, but then tell my why I can not
> simply add the proper merge module and are done with it?
>
> RJF: That is an excellent question. Since you say the custom action was
> run after "InstallFiles" in the installati

Re: [WiX-users] simple custom action DLL-not being called?

[Rob Hamflett]

Is the entry point exposed properly?  Either through a definition file, or I 
think the other way is 
through a pragma.

Rob

Chris Bardon wrote:
> I'm trying to create a custom DLL that sets an installer property that
> the user can then modify, so I tried starting with a simple example:
>  
> extern "C" UINT __stdcall TestFn(MSIHANDLE hInstall)
> {
>   MsiSetProperty(hInstall,TEXT("AGENTID"),TEXT("AgentID from
> DLL"));
>   return ERROR_SUCCESS;
> }
> 
> I can compile/link the DLL just fine, and then I refer to it in my Wix
> source like so:
> 
> 
>  Return="check" Execute="immediate" />
> 
>   
>
> 
> 
> When I run the installer though, the property doesn't seem to be set by
> the action, and if I check the trace, nothing in the log seems to even
> indicate that the custom action ran.  Is there something else that I
> need to do to get a custom DLL to be called?  
> 
> Thanks,
> 
> Chris
> 
> 
>  
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


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

Re: [WiX-users] wix, C# installer class, uninstall

[Chris Bardon]

Have you tried something like this:


  INSTALLED


This should execute the action only if the product is installed.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nitin
Chaudhari
Sent: Thursday, March 22, 2007 9:37 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] wix, C# installer class, uninstall


I am using a C# installer class, during installation, I am able to call
my C# install function, however I am not able hook uninstall in wix to
call my C# uninstall function.
 
In Wix, I am using the following XML to hook uninstall... but the MSI
log shows that this custom action is being invoked during installation
itself.
1

1

How can I ensure that my custom action is executed only on uninstall?

Thanks,

Nitin


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

[WiX-users] wix, C# installer class, uninstall

[Nitin Chaudhari]

I am using a C# installer class, during installation, I am able to call my
C# install function, however I am not able hook uninstall in wix to call my
C# uninstall function.

In Wix, I am using the following XML to hook uninstall... but the MSI log
shows that this custom action is being invoked during installation itself.

1

1

How can I ensure that my custom action is executed only on uninstall?

Thanks,

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

Re: [WiX-users] XmlFile and Votive?

[Chris Bardon]

You know what, I checked again and it looks like I was looking at the v2
.chm.  That would probably explain why it wasn't there :)
 
I tried referring to util:XmlConfig though, and I'm still getting errors
from Candle.  I tried both your suggestion and a fully qualified example
(empty, I know, but I'm just trying to get by the first level of
errors):








The first attempt tells me that the namespace prefix "Util" (upper or
lower case) isn't defined, and the fully qualified example says that the
component element contains an unexpected child element.  All I did for
the DLL was to reference WixUtilExtension and rebuild-is there another
line I need to add to the wix source to include the schema extensions
(similar to a using directive or an #include)?  

Thanks again for all your help though-I wouldn't have made it near as
far as I have without this list.

Chris




From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 21, 2007 11:18 AM
To: Chris Bardon
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] XmlFile and Votive?


Chris Bardon wrote: 

Thanks for the heads on up XmlConfig-I'll have to check that
out. Doesn't look like it's in the CHM though (although it is on the
wiki).  Also, adding the reference to WixUtilExtension doesn't seem to
resolve the problem-adding an XmlConfig or XmlFile element under a
Component still comes up with the same errors.  Is it possible that
these were removed from the util DLL in the version of Votive that's up
on Sourceforge?


XmlConfig is in WiX.chm for the latest v3 release. You'll need to use
util:XmlConfig to refer to the WixUtilExtension namespace.

-- 
sig://boB
http://bobs.org

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

Re: [WiX-users] Just a question out of frustration

[Richard.Foster]

Original message from Friedrich [trimmed in places] with my comments
inline and prefixed by "RJF":

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Friedrich
Dominicus
Sent: Thursday, March 22, 2007 3:27 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Just a question out of frustration

[Snip]

1) At first I installed the difxapp tools
   - Howerver it is unclear to me if a printer falls under it's
requirements.

[Snip]

I assume Printer falls under PlugAndPlay.

RJF: That was also my assumption, but as mentioned before I have not
worked with printer drivers and so I am starting from a position of
ignorance!

2) then wix2 and wix3 (I have not idea really what one to prefer)

RJF: WiX2 is considered "Stable", i.e. it is unlikely that any updates
will require you to make significant modifications to your source files.
Rob has stated that WiX3 is getting to that point, but that there may
still be some breaking changes. If you want to ship to customers in the
next 3-6 months, I think I would choose to stay with WiX2. (According to
the documentation, the DIFxApp.wixlib is supported under WiX2 or later).

3) after that I trid my best to get the unidrv stuff compiled. In the
end that was the "easy" task"

4) no we get to deployment
   - I downloaded tons of stuff to read from 
* http://www.microsoft.com/whdc/driver/install/default.mspx
* plus everything I could get my hands on with Printer in it's
header, especially of course Printer Installation in Windows Vista

Now the first trouble has stroke:
According to the later docs I have to write an .inf file whichis
package aware. Well getting that was not really an easy
undertaking. And checking if it works with chkinf just ended in error
messages from Perl (which I had to install separatly from
ActiveState). However it seems I got that "right" at least so much
that I could use the .inf file to install the printer.

Howerver open questions still remain:
- Do I need a co-installer?

RJF: I'm not sure what a co-installer is. If you mean a separate package
to perform part of the installation, then I would certainly hope not.
You may still need a custom action after installing the driver to
actually set up a printer, and if there isn't already one available and
tested by others than I think it would be a very good thing (if
possible) to create one collaboratively for the benefit of the entire
WiX community.

- Am I expected to write any other special "setup" routine
I can't tell and that makes me aggressive. Why the hell couldn't that
be documented? No don't say check the examples. The examples do not
help the slighest. The give you some .inf file and say use this or
that for installation.

RJF: I would have to agree. From my brief look at the documentation it
isn't at all clear. Unfortunately every company (including Microsoft)
has limited resources, and I can completely understand why thy might
concentrate their documentation efforts on areas that are important to
more customers. The other possibility is that the people who wrote the
documentation create this type of installation so frequently that they
have failed to mention steps and assumptions which are "trivial" to
them, but not to us.

- the mentionin of core drivers has meant to me that I can expect that
the needed files (unidrv.dll) are installed on any Vista. So I do
not have to provide them in my installer. But that's  guess, it's not
stated anywhere I have looked explicitly. So maybe I'm wrong about
this assumption

RJF: That may be true for Vista, but unless you are creating a
constrained Vista only install it's a very bad assumption to make. The
basic rule for a robust installation should be to assume almost nothing.
With the exception of the assumption that you are running on a given
version of Microsoft Installer (or later), and that Microsoft Installer
is operating correctly you should explicitly verify other prerequisites,
and minimize dependencies on anything external to the MSI file.

However in the end it kind of works. But there is one
Problem left:
Usually you can take the Add Printer Wizard and fed him hte .inf files
used for installing the printer. Howerver during the install you get
asked if you want to replace the "existing" driver or not. Well AFAIKT
you can not say replace the existing driver. It then complains about
some missing file. But nevertheless if no printer is there at all the
stuff gets installed... 

Falling back to an .inf files for pre Vista works kind of but on fresh
install vista complains about some NT 4.x driver policy which is not
enabled on default. But if that installation works why not the stuff
with replacement even if that would a no-operation?

5) Now it's getting realyl messy. After the driver is installed I want
the setup to add a Printer symbol. As written before I can not see how
to achieve that without using a custom action. 

RJF: And it is entirely possible that a custom action is req

[WiX-users] simple custom action DLL-not being called?

[Chris Bardon]

I'm trying to create a custom DLL that sets an installer property that
the user can then modify, so I tried starting with a simple example:
 
extern "C" UINT __stdcall TestFn(MSIHANDLE hInstall)
{
MsiSetProperty(hInstall,TEXT("AGENTID"),TEXT("AgentID from
DLL"));
return ERROR_SUCCESS;
}

I can compile/link the DLL just fine, and then I refer to it in my Wix
source like so:





 


When I run the installer though, the property doesn't seem to be set by
the action, and if I check the trace, nothing in the log seems to even
indicate that the custom action ran.  Is there something else that I
need to do to get a custom DLL to be called?  

Thanks,

Chris


 


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

Re: [WiX-users] custom action to reg NET 2.0

[pobox77]

Hi Dhaval,

Does uninstall work too?
I mean will the dll also deregistered if I uninstall the package?

Thanks in advance,
Peter


Don Tasanasanta wrote:
> 
> Your solution helped me find what was wrong with mine. For some reason
> the CA didn't like what I was putting in for the Directory value. I put
> in INSTALLDIR and everything worked great.
> 
>  
> 
> Thanks!
> 
>  
> 
> 
> 
> From: Dhaval Patel [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 09, 2007 4:59 PM
> To: Don Tasanasanta
> Subject: Re: [WiX-users] custom action to reg NET 2.0
> 
>  
> 
> Here is one of my CustomAction elements that I have used in different
> projects - I don't see anything in your CA that will not allow it to
> work, but maybe you want to change the ExeCommand attribute to something
> like I have and give it a shot: 
> 
> 
> 
> NOT
> Installed 
> 
> 
> 
>  
> ExeCommand='"[WindowsFolder]Microsoft.NET\Framework\v2.0.50727\regasm.ex
> e" /codebase "[ProgramFilesFolder]MyComapny\MyProduct\MyProduct.dll"' 
> 
>   Return='check' />
> 
> This seems to work just fine (i.e. it successfully registers the .dll
> for COM Interop in the registry). I think I had the same issue that you
> are having, but I figured out the solution through trial and error, and
> then I forgot all about it :) 
> 
> The problem I think is that you may think WIX will execute the CA from
> within the "Directory" ([FRAMEWORKBASEPATH]v2.0.50727 in your case)
> attribute, but that probably is not the case. Notice in my case how I
> explicitly pass all the paths to the ExeCommand attribute directly - I
> don't even worry about the "Directory" attribute (I assume you can set
> it to any valid DirectoryId within your current WIX project, if you
> decide to use the technique I am using). This is probably the reason why
> it is working in my case, and not yours. 
> 
> Let us all know if this fixes your issue :)
> 
> 
> 
> 
> On 3/8/07, Don Tasanasanta <[EMAIL PROTECTED] > wrote:
> 
> I have been banging my head against this all day... I'm trying to get
> aspnet_regiis.exe to run and set the ASPNET version to 2.0 for my
> virtual directory. 
> 
>  
> 
> Here is my custom action...
> 
>  Directory="[FRAMEWORKBASEPATH]v2.0.50727" Execute="commit"
> ExeCommand="aspnet_regiis.exe -s W3SVC/1/ROOT/MYWebsite -norestart" />
> 
>  
> 
> Where FRAMEWORKBASEPATH is the path to Framework under Microsoft.NET in
> the WINDOWS folder. 
> 
>  
> 
> I have also tried
> 
>  
> 
>  Property="[ASPNETREGPATH]" Execute="commit" ExeCommand="-s
> W3SVC/1/ROOT/MyWebsite -norestart" />
> 
>  
> 
> Where ASPNETREGPATH is the entire path plus aspnet_regiis.exe 
> 
>  
> 
> I have also tried changing the Execute to "immediate" and sequencing the
> custom action after installfinalize.
> 
>  
> 
> Every time I run I get a 1631 return from my custom actions. 
> 
>  
> 
> The command line works just fine when run from a cmd prompt. What am I
> missing here?
> 
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your 
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users 
> 
>  
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/custom-action-to-reg-NET-2.0-tf3373202.html#a9611846
Sent from the wix-users mailing list archive at Nabble.com.


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

[WiX-users] Microsoft Setup Analysis Tool

[Michael Saupe]

Hello,

I've created an application installer with WiX toolset (v2.0).
Everything works fine during my tests.

But today I tested the installer with the Microsoft Setup Analysis Tool (SAT) 
(included in the Microsoft Application Compatibility Toolkit) and I got the 
error message "setup_installer.msi did not run successfully. ERROR: The run did 
not complete successfully.".

What could be the problem?

Btw: When I tested the samples of the WiX tutorial, I got the same error 
message.

Any input would be very helpful.

Regards,
Michael
-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

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

[WiX-users] Problems with Post Build Step and Dependencies in Votive

[Anthony Wieser]

Hi,

I'm trying to set up my project to automatically sign my msi files, so I've 
added a a post build step that looks like this:
signcode   -t 
http://timestamp.verisign.com/scripts/timstamp.dll 
$(TargetDir)AutoSharesWx.msi

and the run post build event is set to:
"When the build updates the project output
That all seems to work fine, though you get a strange error if the build 
fails:
1>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(360,7): Error 
MSB4057: The target "_TimeStampAfterCompile" does not exist in the project.

Ignoring that though, what I really want to be able to do is set 
dependencies on my Votive project to force it to recompile when my inputs 
change (say A.exe as an example).  I've tried adding A.exe as a reference, 
but that doesn't work, nor does adding it as an embedded resource in the 
project.

I must be missing something.

Anthony Wieser
Wieser Software Ltd


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

[WiX-users] RE : Conditional shortcut

[Jacquet Fabian]

I found by myself.

 

A short cut can contain a target attribute.

So you can put the shortcut in a different component (And not only as child of 
file tag) and set a condition on this component.

 

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jacquet 
Fabian
Envoyé : lundi 19 mars 2007 16:46
À : wix-users@lists.sourceforge.net
Objet : [WiX-users] Conditional shortcut


Hi,

 

I have to create a short cut to an exe file only if a text box is 
checked.

I don't see a shortcut can have a condition child tag.

 

How can I do this?

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

Re: [WiX-users] Shortcut targeting file in a different component?

[Rob Hamflett]

Stuart A. Malone wrote:
>   ICE69: Mismatched component reference. Entry 'DesktopShortcut' of  
> the Shortcut table belongs to component 'DesktopShortcut'. However,  
> the formatted string in column 'Target' references file  
> 'Life_Balance.exe' which belongs to component 'MainApplication'.  
> Components are in the same feature.
> 
> The last error seems to indicate that Light is beginning to  
> understand what I'm trying to do, but does not approve of it.  Is it  
> perhaps only legal for a shortcut in one component to refer to  
> another if the two components are in different features?  Is that  
> what it's trying to say?

No, but it's a little confusing.  If you put them in different features the 
last sentence will read 
"Components are in different features".  I think that bit is just information 
for the reader.  If 
they're in the same feature, then the problem is minimised, since you know the 
target will be there.

Rob


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

Re: [WiX-users] Registering COM object - unhandled extension element in v3

[Rob Hamflett]

Bob Arnson wrote:
> Votive doesn't support WiX v2 but you can install the v2 binaries .zip. 
> Or wait for v3 -- it should soon have the COM+ CAs.
> 

There's a download for Votive 2.0.4820 available.  I've got 2.0.4415 installed. 
 I don't use the any 
of the project stuff, but it is good for the Intellisense.

Rob


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

[WiX-users] Heat and wix 2.0

[Jacquet Fabian]

Hi, 
 
Is it dangerous to use Heat with wix 2.0 if I only use it for dll
registration?
I don't find a doc of heat. Is there a way to generate wix file only for
selfregister dll with heat (all my files are ine the same folder)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] RE : RE : Reboot to replace files

[Jacquet Fabian]

I'm sorry, the exact error message is:
"The Windows Installer service cannot update the system file 
c:\WINDOWS\System32\mfc42.dll because the file is protected by Windows. You may 
need to update your operating system for this program to work correctly"
 
When the installation was done with a vb6 program, we called a method which 
copy the file during next boot.
 
Is there similar solution with wix?

-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jacquet 
Fabian
Envoyé : jeudi 22 mars 2007 9:00
À : Rob Mensching; wix-users@lists.sourceforge.net
Objet : [WiX-users] RE : Reboot to replace files


 

Currently, I'm installing the merge module of mfc42.msm

During the installation, it says mfc42.dll is used and it can't replace 
it.

I can say cancel, ignore or retry so I don't think windows installer 
replace it during next reboot.

Is there a way to ask windows installer to do this?

-Message d'origine-
De : Rob Mensching [mailto:[EMAIL PROTECTED] 
Envoyé : mercredi 21 mars 2007 18:01
À : Jacquet Fabian; wix-users@lists.sourceforge.net
Objet : RE: Reboot to replace files



The Windows Installer will take care of that for you.

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 
Jacquet Fabian
Sent: Wednesday, March 21, 2007 2:49 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Reboot to replace files

 

Hi,

 

I need to replace some files used by the system.

To do this, I try to replace these files on reboot.

But I don't know how to do this with wix.

Can somebody help me?

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

Re: [WiX-users] Problems with custom bitmaps with wixUI

[Anthony Wieser]

- Original Message - 
Subject: Re: [WiX-users] Problems with custom bitmaps with wixUI


> Anthony Wieser wrote:
>> I checked with SPY++, and the bitmap is 493 pixels wide (at least on my
>> Vista system, the way it's set up at the moment).
>>   
> 
> That's normal for XP too and that's what's in WiX.chm.
> 
>> As the dialogs are specified in dialog units, what is the recommendation for
>> sizing bitmaps?  Build something that can be stretched without much
>> distortion?
>>   
> 
> That's about your only choice. Bitmaps don't scale well and 
> unfortunately, there's no way to "lock" the dialogs.
> 

I guess that's the problem.  I started out with the tutorial pointed to by 
wix.sourceforge.net
http://www.tramontana.co.hu/wix/lesson2.php

and the values on that page are different.

Anthony Wieser
WIeser Software Ltd


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