Re: [WiX-users] Token replacement in configuration files

[Brian Rogers]

Hey Stephen,

There is a crude version of something like this I wrote. I call it Property
Loader, I am sure you could modify it a bit and get what you want.

http://www.codeplex.com/WIXML/Release/ProjectReleases.aspx?ReleaseId=263

Thanks,
-- 
Brian Rogers
"Intelligence removes complexity." - BR
http://www.codeplex.com/wixml/
On Mon, Feb 25, 2008 at 9:21 PM, Heath Stewart <[EMAIL PROTECTED]> wrote:

> Not currently, no. If you choose to develop one, be sure to reset the
> modification timestamp back to the creation timestamp (or set the
> creation timestamp to the modification timestamp) or you will not be
> able to replace that file by default again since MSI default file
> versioning rules won't replace modified files (even if a CA modified it,
> which Windows Installer wouldn't know).
>
> Mooney, Stephen wrote:
> >
> > Hi,
> >
> > I have a configuration file in which I need to fill in some values at
> > install time. Eg:
> >
> > plugins:logging:output = "${LOGS_DIR}/log.txt";
> >
> > Is token replacement possible in WiX / msi? Is is possible to replace
> > ${LOGS_DIR} with a value natively in wix / msi?
> >
> > Thanks,
> >
> > Stephen Mooney
> >
> > 
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
> >
> > 
> >
> >
> -
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> > 
> >
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
>
> Heath Stewart
> Deployment Technology Group, Microsoft
> http://blogs.msdn.com/heaths
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Token replacement in configuration files

[Heath Stewart]

Not currently, no. If you choose to develop one, be sure to reset the 
modification timestamp back to the creation timestamp (or set the 
creation timestamp to the modification timestamp) or you will not be 
able to replace that file by default again since MSI default file 
versioning rules won't replace modified files (even if a CA modified it, 
which Windows Installer wouldn't know).

Mooney, Stephen wrote:
>
> Hi,
>
> I have a configuration file in which I need to fill in some values at 
> install time. Eg:
>
> plugins:logging:output = "${LOGS_DIR}/log.txt";
>
> Is token replacement possible in WiX / msi? Is is possible to replace 
> ${LOGS_DIR} with a value natively in wix / msi?
>
> Thanks,
>
> Stephen Mooney
>
> 
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>   
> 
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> 
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   

-- 

Heath Stewart
Deployment Technology Group, Microsoft
http://blogs.msdn.com/heaths


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] PerfCounter on NT 4.0?

[Mike Dimmick]

I'm currently trying to adapt our performance counter text string
registration from being done in our own code (picked up from Jeff Richter's
book "Programming Server-Side Applications for Windows") to use the
LoadPerfCounterTextStrings API and, ultimately, the PerfCounter element in
WiX. Something seemed to be corrupting the text strings on some systems, not
definitively linked to our code but I thought it would be better to use the
supported method.

I've just spent a day coding up LoadLibrary/GetProcAddress and falling back
on CreateProcess to run lodctr.exe if LoadLibrary or GetProcAddress fail,
then tested on NT 4.0 only to discover that the library, loadperf.dll, is
actually present and implements the API! It does appear to work, but as it's
not documented as being supported I thought I'd ask if anyone had seen any
problems.

Some of our customers are still running older versions of the product on NT
4.0 and would expect it to continue to work.

Does anyone have any experience with the PerfCounter element, or the API
that it uses, on NT 4.0?

(I think this API may have been one of the internal ones disclosed for
Windows 2000 in reaction to the anti-trust case, given that it basically
requires the lodctr.exe command line to be passed.)


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setting Estimated Size and Version

[Mike Dimmick]

I was fairly sure that if you set ARPSIZE it sets the EstimatedSize property
that Raymond talks about at
http://blogs.msdn.com/oldnewthing/archive/2004/07/09/178342.aspx, and
therefore ARP doesn't need to guess at the right thing to look at to check
the size.

Since Windows Installer knows everything that you installed, you would have
thought it would set this information itself. (Another piece of the
documentation, indexed under 'Uninstall Registry Key', states that it does,
which leads to the question, what is ARPSIZE for?)

When you set ARPSYSTEMCOMPONENT you're telling Windows Installer, 'this is a
system component, don't show it in Add/Remove Programs'. So it doesn't, and
it doesn't write any of the other information to
HKLM\Software\Microsoft\Windows\Uninstall that it normally would. (What
would be the point? You can't see it anyway.)

Using ARPSYSTEMCOMPONENT to support your own bootstrap, to prevent Windows
Installer writing its own UninstallString, is kind of a convenient accident.
I'm not sure it was originally intended. The documentation actually says
"Setting the ARPSYSTEMCOMPONENT property to 1 using the command line or a
transform prevents the application from being displayed in the Add or Remove
Programs list of Control Panel." No mention of doing it in the original
package! I think the idea was that OEMs would set it for anything they
didn't want their users to uninstall.

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: 22 February 2008 07:13
To: Ahn Ahn Liu
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Setting Estimated Size and Version

1. ARPSIZE is set magically by ARP. There is no real way to control it. 
Raymond Chen (Master of all things Shell) had a fun blog entry about how 
ARP calculated the size it displayed there. The fact that it took him a 
couple paragraphs is telling.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent registry key from being removed duringuninstall? AND Only create not existing registry entrieswhile install?

[Mike Dimmick]

1)

I'm assuming by 'registry key' you mean any value/data pair. The 'key' is
strictly a container for values (one of which can be the default value). If
the key is empty - contains no values and the default value has no data -
then Windows Installer deletes the key.

To keep values even after all products installing that value have been
uninstalled, mark the component which contains the value as Permanent. This
will have the effect of preserving the key path and all the other resources
in the component.

2)

Declare all the registry values you need. Windows Installer will write all
registry values in a Component if the key path for that component needs to
be updated. If the key path is a file, the component will be installed if
the file is missing, if the file already installed doesn't have a version
number and a version number is recorded in the File table, if the file
already installed hasn't been modified if no version number is recorded, or
if the version in the File table is newer. For registry values, if the key
or value is missing or the value data is different from the data in the
package, the component is considered out-of-date and Windows Installer will
install the whole component (files, registry values, etc, etc).

I recommend that you treat registry values that you install as being
immutable, changeable only by the next version of your installer. I believe
there's a risk that user customizations could be overwritten by repairs or
upgrades if installed registry values are edited. Stick to the bare minimum
required to allow the components to be located - do the rest in initial
program startup. 

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Beyer, Ingo
Sent: 25 February 2008 16:42
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Prevent registry key from being removed
duringuninstall? AND Only create not existing registry entrieswhile install?

Hi all,

I've two questions. I tried to solve them by myself, but I cannot find
informations in the net...

1) How can I prevent a registry key from being removed during uninstall?

2) What do I have to do, that a only not existing registry entries (some
REG_SZ's) will be create during install.

Thanks a lot for help!

Greetings
Ingo

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Failing gracefully from ServiceControl?

[Geoff Finger]

Well it took me about six hours of websearching and following false
leads to get the "pretty easy" custom action working, so just to try
and save anyone else the effort in the future...

I figured out almost immediately that you _can_ perform the action
fairly simply using the following:

net.exe







However that way you get a command line window popping up in the
background as net.exe tries to start the service. I tried fiddling
around with a lot of the properties but couldn't get it to run
quietly. I finally found there's a specific function in wixca.dll to
run command line function quietly.

First you've got to find wixca.dll so you can either reference the
location or copy it into your project. In my case it was in C:\Program
Files (x86)\Windows Installer XML\bin. You then need something similar
to the following:





(Note that it's required to have the extra set of quotes around "net"!)







Thanks to everyone who offered suggestions on how to get this worked out!

On Fri, Feb 22, 2008 at 4:03 PM, Alexander Shevchuk
<[EMAIL PROTECTED]> wrote:
> It should be pretty easy to accomplish with custom action type 34 scheduled 
> after InstallFinalize and with ExeCommand set to:
>  net start 
>
>
>  Alex
>
>
>
>
>
>  -Original Message-
>  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger
>  Sent: Friday, February 22, 2008 3:42 PM
>  To: wix-users@lists.sourceforge.net
>  Subject: Re: [WiX-users] Failing gracefully from ServiceControl?
>
>  That worked! When the service install fails the error box now has an
>  "Ignore" option. When I saw that option in the docs it never occurred
>  to me that it might also control the criticality of the item, I
>  figured turning it off would just make the installation continue on a
>  little further before it died. Thanks!
>
>  So does anyone know of a way to make it always choose "Ignore" without
>  popping up the window first?
>
>  And KStuart, when I first started looking into this problem I found a
>  couple posts from last year saying things like:
>
>  "The assemblies are not committed until successful execution of the
>  InstallFinalize Action. This means that if you author a custom action
>  or resource that relies on the assembly, it must be sequenced after
>  the InstallFinalize Action. For example, if you need to start a
>  service that depends on an assembly in the Global Assembly Cache
>  (GAC), you must schedule the starting of that service after the
>  InstallFinalize Action. This means you cannot use the ServiceControl
>  Table to start the service, instead you must use a custom action that
>  is sequenced after InstallFinalize."
>
>  That certainly seems to indicate that if I want the services to start
>  on a system where the assemblies haven't already been installed I'd
>  have to make a custom action to do it, and we probably don't have time
>  to deal with that before the release, which is why we're trying to get
>  the "fire and forget" method working.
>
>  On Fri, Feb 22, 2008 at 2:26 PM, Wilson, Phil
>  <[EMAIL PROTECTED]> wrote:
>  > It's possible that setting the ServiceControl Wait value to 0 might make a 
> difference. Generally speaking, this is the way you say you don't care if the 
> service starts properly or not.  However the documentation says that the SCM 
> needs to get the service into pending state, and I don't know off the top of 
> my head if this means the process has to at least start (and missing 
> dependencies could mean it doesn't).
>  >
>  >  Phil Wilson
>  >
>  >
>  >
>  >
>  >  -Original Message-
>  >  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KStuart
>  >  Sent: Thursday, February 21, 2008 6:18 PM
>  >  To: wix-users@lists.sourceforge.net
>  >  Subject: Re: [WiX-users] Failing gracefully from ServiceControl?
>  >
>  >
>  >  I haven't been using windows installer/wix very long so am a little 
> confused,
>  >  from what I can see the default behaviour of the install sequence is to
>  >  process all files before attempting to start any services, therefore if 
> your
>  >  product includes dependent assemblies they will already have processed
>  >  before the StartServices action, in fact starting services is close to the
>  >  last action in the install sequence, of course you can always move it
>  >  further back.
>  >
>  >  If you're installing several services are you sure you don't have any
>  >  inter-service dependencies you're not taking care of?
>  >
>  >  You can always check if the dependencies are already installed and skip
>  >  trying to start the service if they are not, but like I said, if your
>  >  product is installing those assemblies anyhow it shouldn't be an issue.
>  >
>  >
>  >  Geoff Finger-2 wrote:
>  >  >
>  >  > I've got several services I'm trying to install. If I add
>  >  > "Start='install'" to the ServiceControl element then it will try to
>  >  > start them, but it will almost always fail with a 1920 error. I'm
>  >  > pretty sur

[WiX-users] Prevent registry key from being removed during uninstall? AND Only create not existing registry entries while install?

[Beyer, Ingo]

Hi all,

I've two questions. I tried to solve them by myself, but I cannot find
informations in the net...

1) How can I prevent a registry key from being removed during uninstall?

2) What do I have to do, that a only not existing registry entries (some
REG_SZ's) will be create during install.

Thanks a lot for help!

Greetings
Ingo

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Display feature as Unavailable.

[Robert.Priest]

Which, according to the documentation can only be: Local, Source, or
Either. No "Unavailable". 

 

Ok. At least  I know now. 

 

Thanks Bob.

 

From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Saturday, February 23, 2008 12:32 PM
To: Robert Priest
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Display feature as Unavailable.

 

[EMAIL PROTECTED] wrote: 

How do I display a feature in the Selection Tree, but the display it as
Unavailable only?


The selection tree, in addition to being awkward to use, doesn't have a
lot of useful features. Like this one.




BTW - how do I set such attributes as
"msidbComponentAttributesLocalOnly" on a component anyway?


Using the Location attribute.



-- 
sig://boB
http://joyofsetup.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Name of the msi with in the install file

[Richard]

In article <[EMAIL PROTECTED]>,
"RAYMENT Tim" <[EMAIL PROTECTED]>  writes:

> Maybe you should step back and describe the fundamental problem that
> you're trying to solve.  Perhaps then someone might be able to suggest
> an alternative 'solution' that doesn't require msi name.

...or a custom action.  You don't need custom actions to write data
into the registry!
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Get ahead of the competition with this!

[Andrejs derossett]

Great nights with your woman are now possible.-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Prevent to call SqlScripts of older version when doing major upgrade

[Petr Vones]

Hi,

is there a way to prevent all SQL scripts called on product uninstall when 
doing a major upgrade to new version ? I can not change the older version 
MSI. I would like to solve it in the new version. I have tried to comment 
out Upgrade element but it results in two products with the same name 
installed.

Thanks, Petr 


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Token replacement in configuration files

[Mooney, Stephen]

Hi,
I have a configuration file in which I need to fill in some values at
install time. Eg:

plugins:logging:output = "${LOGS_DIR}/log.txt";

Is token replacement possible in WiX / msi? Is is possible to replace
${LOGS_DIR} with a value natively in wix / msi?

Thanks,
Stephen Mooney


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Name of the msi with in the install file

[RAYMENT Tim]

Maybe you should step back and describe the fundamental problem that
you're trying to solve.  Perhaps then someone might be able to suggest
an alternative 'solution' that doesn't require msi name.

Regards,

Tim

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of vishnum
Sent: 25 February 2008 04:11
To: 
Subject: Re: [WiX-users] Name of the msi with in the install file


Hello:

Thank you very much for your response.

What I am trying to do is I have a custom action (external, in a dll)
which
based on the msi name writes data to the registry. I tried using
"OriginalDatabase" property for this but it kept returning empty string.
It
returns the name of the msi only after "InstallFinalize" sequence.

Thanks,
Vishnu
-- 
View this message in context:
http://www.nabble.com/Name-of-the-msi-with-in-the-install-file-tp1558324
9p15673696.html
Sent from the wix-users mailing list archive at Nabble.com.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


+++ Virus-scanned by MailControl for Oxford Instruments +++



___ThThis
 e-mail is confidential and is for the addressee only.  Please refer to 
www.oxinst.com/email-statement for regulatory information.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Managed Custom Actions in WiX 3.0

[si]

Minor update:

saute [before] [after] [result.wxs] 

Options:
--noUninstall : do not generate uninstall create & delete commands.

Pre-process:
 Parse both "before" and "after" into xml documents. i.e. validate
they're well-formed.
 Validate any schemas.

Process (starting at root)
 1. Look for attribute and value differences in "before" and "after"
and generate XmlFile commands if found.
 2. For each child node in "before"
   Is the "after" file missing child node?
 Yes - generate delete XmlConfig command and move to next sibling.
 3. For each child node in "after"
   Is the "before" file missing child node?
 Yes - generate create XmlConfig commands recursively and move to
next sibling.
 No - Start again from 1. on each grandchild node. i.e. recurse down tree.

So far it looks like XmlFile is best for 1. and XmlConfig for 2. and 3.

-- 
It's a wild world that we live in, you step to the vibe like a new
found religion, take your position, compile your vision, futurism,
algorithm has risen up!pfm - the western

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users