Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

Okay, I'm looking at the installer in Orca.  I see that all the directories 
declared in the modules have the package guid appended to them (e.g. 
ASPdirectory0.1A39512D_87E4_4FD4_AEFC_88DE0E1C2536), but that's the same for 
those that went to the right place and those that went somewhere else.

A lot of the binary modules had a  inside the 
module's , so all those INSTALLDIRs are 
differentiated by the guid...

Thanks
Mark


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Wednesday, October 05, 2011 4:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Open the MSI up in Orca or Inst Ed and you might find that the directory IDs
in the merge modules have had Guids added to them. Ids in modules are
"modularised" to avoid name clashes.

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 04 October 2011 23:14
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Hi Peter...

It was a bit of a nuisance to get a verbose log out of the wmi
install, so I've been comparing the logs from the builds using the type 51
and type 35 work-arounds vs the builds just ignoring the error.  The
differences I see is that TARGETDIR= in the early phases of
all logs, but in the ones with the type 51 and type 35 work-arounds TARGETDIR
just doesn't appear to be used in coming up with the final destination for
some of the merge modules.  Why?  I don't know.

E.g.
Action ended 17:14:01: INSTALL. Return value 1.
Property(C): Binaries = C:\OurPath\Binaries\
Property(C): TARGETDIR = C:\OurPath\
Property(C): ASP = C:\OurPath\ASP\
Property(C): Ptt = C:\OurPath\Ptt\

In the log when I just ignore the warning compared to
Action ended 15:27:12: INSTALL. Return value 1.
Property(S): Binaries = C:\OurPath\Binaries\
Property(S): TARGETDIR = C:\OurPath\
Property(S): ASP = C:\ASP\
Property(S): Ptt = C:\OurPath\Ptt\

In the log when I'm trying one of the other approaches.  

On your other suggestions, I found a few things:
1) Can't put a type 35 anywhere before after CostFinalize.  It throws an
error at any stage before.

2) I tried putting my own directory level (e.g. ...) just inside of TARGETDIR, but using a type
51 CA Before="CostInitialize" still had the same problem of pretty random
directory placement.  Specifically, it put things in C:\Ice48 Stub\...

3) Same as #2 but going back to type 35 after CostFinalize appeared to do the
trick.  Things got installed where I expected when running the msi locally.

Thanks
Mark

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 12:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

The subtle differences between the two are a bit beyond me since I've never
needed to distinguish between them. There's a list of considerations at
http://msdn.microsoft.com/en-us/library/aa367852%28v=VS.85%29.aspx which may
answer your questions. It's worth trawling through the MSDN.

For us, setting the property before CostInitialize has always worked. We use
a setproperty action but setdirectory would work and should make slightly
more sense. It probably helps matters that we don't use merge modules nor MSI
UI so the directories are determined before the MSI even starts up and don't
change during installation. There are setproperty and setdirectory elements
in wix3.5 to more concisely express these kinds of custom action.

The remote/local difference is somewhat strange, I agree, but I'm sure
there's a good reason for it. A comparison of verbose logs may give you a
clue.


-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 04 October 2011 16:57
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Thanks, Peter...  I can give it a shot.

I was a bit perplexed when I found that the Type 51 approach worked as I
expected when it installed remotely through WMI, as opposed to being run
locally on the computer.  By and large our ops team uses a utility to manage
the farm and the installs are run remotely; the difference in behavior just
annoyed me.

Just out of curiosity, if I switch to using INSTALLDIR instead, does it make
a difference whether I use the Type 51 or the type 35 custom actions to set
it?  And at which phase?

I googled around and found a few posts advocating the type 51 approach Before
CostFinalize, now some saying type 35 after.

I'm wondering if just avoiding the specific case of TARGETDIR would push one
way or the other?

Thanks
Mark


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 11:45 AM
To: General discussion for Windows 

Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

Hi Peter...

It was a bit of a nuisance to get a verbose log out of the wmi install, 
so I've been comparing the logs from the builds using the type 51 and type 35 
work-arounds vs the builds just ignoring the error.  The differences I see is 
that TARGETDIR= in the early phases of all logs, but in the 
ones with the type 51 and type 35 work-arounds TARGETDIR just doesn't appear to 
be used in coming up with the final destination for some of the merge modules.  
Why?  I don't know.

E.g.
Action ended 17:14:01: INSTALL. Return value 1.
Property(C): Binaries = C:\OurPath\Binaries\
Property(C): TARGETDIR = C:\OurPath\
Property(C): ASP = C:\OurPath\ASP\
Property(C): Ptt = C:\OurPath\Ptt\

In the log when I just ignore the warning compared to
Action ended 15:27:12: INSTALL. Return value 1.
Property(S): Binaries = C:\OurPath\Binaries\
Property(S): TARGETDIR = C:\OurPath\
Property(S): ASP = C:\ASP\
Property(S): Ptt = C:\OurPath\Ptt\

In the log when I'm trying one of the other approaches.  

On your other suggestions, I found a few things:
1) Can't put a type 35 anywhere before after CostFinalize.  It throws an error 
at any stage before.

2) I tried putting my own directory level (e.g. ...) just inside of TARGETDIR, but using a type 
51 CA Before="CostInitialize" still had the same problem of pretty random 
directory placement.  Specifically, it put things in C:\Ice48 Stub\...

3) Same as #2 but going back to type 35 after CostFinalize appeared to do the 
trick.  Things got installed where I expected when running the msi locally.

Thanks
Mark

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 12:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

The subtle differences between the two are a bit beyond me since I've never
needed to distinguish between them. There's a list of considerations at
http://msdn.microsoft.com/en-us/library/aa367852%28v=VS.85%29.aspx which may
answer your questions. It's worth trawling through the MSDN.

For us, setting the property before CostInitialize has always worked. We use
a setproperty action but setdirectory would work and should make slightly
more sense. It probably helps matters that we don't use merge modules nor MSI
UI so the directories are determined before the MSI even starts up and don't
change during installation. There are setproperty and setdirectory elements
in wix3.5 to more concisely express these kinds of custom action.

The remote/local difference is somewhat strange, I agree, but I'm sure
there's a good reason for it. A comparison of verbose logs may give you a
clue.


-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 04 October 2011 16:57
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Thanks, Peter...  I can give it a shot.

I was a bit perplexed when I found that the Type 51 approach worked as I
expected when it installed remotely through WMI, as opposed to being run
locally on the computer.  By and large our ops team uses a utility to manage
the farm and the installs are run remotely; the difference in behavior just
annoyed me.

Just out of curiosity, if I switch to using INSTALLDIR instead, does it make
a difference whether I use the Type 51 or the type 35 custom actions to set
it?  And at which phase?

I googled around and found a few posts advocating the type 51 approach Before
CostFinalize, now some saying type 35 after.

I'm wondering if just avoiding the specific case of TARGETDIR would push one
way or the other?

Thanks
Mark


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 11:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

I've just looked back at your original post which is how to avoid ICE48
errors. The ICE48 error is issued because ...

ICE48 checks for directories that are hard-coded to local paths in the
Property table.
(From
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368977%28v=vs.85%29
.aspx)

ICE48 is objecting to the use of C:\OurPath\

TARGETDIR is by default set to the root of the drive with the most free space
(I think). Some of the other components, probably in the merge modules, might
have directory paths rooted under a well known directory property like
ProgramFilesFolder which overrides the TARGETDIR, even though they appear
underneath TARGETDIR.

I'm not entirely sure how to fix it to work exactly how you have it currently
but I can give some info that might help.

The usual pattern for having a retargetable installation is to set up the
default in the directory elements and then make the installation directory a
public directory property, in this case, "INSTALL

Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

Thanks, Peter...  I can give it a shot.

I was a bit perplexed when I found that the Type 51 approach worked as I 
expected when it installed remotely through WMI, as opposed to being run 
locally on the computer.  By and large our ops team uses a utility to manage 
the farm and the installs are run remotely; the difference in behavior just 
annoyed me.

Just out of curiosity, if I switch to using INSTALLDIR instead, does it make a 
difference whether I use the Type 51 or the type 35 custom actions to set it?  
And at which phase?

I googled around and found a few posts advocating the type 51 approach Before 
CostFinalize, now some saying type 35 after.

I'm wondering if just avoiding the specific case of TARGETDIR would push one 
way or the other?

Thanks
Mark


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 11:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

I've just looked back at your original post which is how to avoid ICE48
errors. The ICE48 error is issued because ...

ICE48 checks for directories that are hard-coded to local paths in the
Property table.
(From
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368977%28v=vs.85%29
.aspx)

ICE48 is objecting to the use of C:\OurPath\

TARGETDIR is by default set to the root of the drive with the most free space
(I think). Some of the other components, probably in the merge modules, might
have directory paths rooted under a well known directory property like
ProgramFilesFolder which overrides the TARGETDIR, even though they appear
underneath TARGETDIR.

I'm not entirely sure how to fix it to work exactly how you have it currently
but I can give some info that might help.

The usual pattern for having a retargetable installation is to set up the
default in the directory elements and then make the installation directory a
public directory property, in this case, "INSTALLDIR".

 


  
..components...
Then you can set the value of INSTALLDIR (or whatever you call it) to some
other value on the command line or leave it to get the default.

Note that the built-in directory property ProgramFilesFolder will override
whatever TARGETDIR is set to unless youre performing an admin installation.
If INSTALLDIR is defined as an absolute path, that will in turn override
[ProgramFilesFolder]\InitTech.

You might be able to get this to work with TARGETDIR but since Windows
Installer itself will set the value of it, it's easier to define your own
property and use that: in this case INSTALLDIR.


-----Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 04 October 2011 16:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

I was wondering maybe *before* CostFinalize?  I'm just grasping around
here...


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 10:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Could it be the file's encoding ? Declared as UTF-8 but written in something
else maybe ?

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 04 October 2011 15:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Thanks for the response...  I tried replacing my type 51 with



After CostFinalize, but now I get an error "The folder path '?' contains an
invalid character" when I run the installer locally.

Not sure where the ? is coming from...

Mark


-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Monday, October 03, 2011 4:48 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dealing with ICE48 warning

When you use a type 51 custom action it doesn't call MsiSetTargetPath because
you've told it you are setting a property and not a directory. Try using a
type 35 custom action (after CostFinalize) by using the Directory attribute
instead of Property.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC
E48-warning-tp6841665p6856559.html
Sent from the wix-users mailing list archive at Nabble.com.

-
-
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.

Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

I was wondering maybe *before* CostFinalize?  I'm just grasping around here...


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 10:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Could it be the file's encoding ? Declared as UTF-8 but written in something
else maybe ?

-Original Message-----
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 04 October 2011 15:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Thanks for the response...  I tried replacing my type 51 with



After CostFinalize, but now I get an error "The folder path '?' contains an
invalid character" when I run the installer locally.

Not sure where the ? is coming from...

Mark


-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Monday, October 03, 2011 4:48 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dealing with ICE48 warning

When you use a type 51 custom action it doesn't call MsiSetTargetPath because
you've told it you are setting a property and not a directory. Try using a
type 35 custom action (after CostFinalize) by using the Directory attribute
instead of Property.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC
E48-warning-tp6841665p6856559.html
Sent from the wix-users mailing list archive at Nabble.com.

-
-
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

Nope...  The actual path is just as vanilla as the example below.  Straight 
7-bit ascii...

Thanks
mark


-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Tuesday, October 04, 2011 10:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Could it be the file's encoding ? Declared as UTF-8 but written in something
else maybe ?

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 04 October 2011 15:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dealing with ICE48 warning

Thanks for the response...  I tried replacing my type 51 with



After CostFinalize, but now I get an error "The folder path '?' contains an
invalid character" when I run the installer locally.

Not sure where the ? is coming from...

Mark


-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Monday, October 03, 2011 4:48 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dealing with ICE48 warning

When you use a type 51 custom action it doesn't call MsiSetTargetPath because
you've told it you are setting a property and not a directory. Try using a
type 35 custom action (after CostFinalize) by using the Directory attribute
instead of Property.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC
E48-warning-tp6841665p6856559.html
Sent from the wix-users mailing list archive at Nabble.com.

-
-
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

Thanks for the response...  I tried replacing my type 51 with



After CostFinalize, but now I get an error "The folder path '?' contains an 
invalid character" when I run the installer locally.

Not sure where the ? is coming from...

Mark


-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Monday, October 03, 2011 4:48 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dealing with ICE48 warning

When you use a type 51 custom action it doesn't call MsiSetTargetPath because
you've told it you are setting a property and not a directory. Try using a
type 35 custom action (after CostFinalize) by using the Directory attribute
instead of Property.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-ICE48-warning-tp6841665p6856559.html
Sent from the wix-users mailing list archive at Nabble.com.

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

Okay, now this is getting strange and I hope someone can help me figure out 
what's going on here...

I just discovered that having a type 51 custom action to set TARGETDIR  puts 
half the directories in the wrong place when I copy the msi to a machine and 
run it locally.

When I copy the msi to the machine and run it remotely through WMI, the 
directories are put in the right place.  So when I *thought* I'd resolved it by 
moving the CA from Before="CostInitialize" to Before="CostFinalize" it would 
appear the bigger difference was running the msi through our little utility 
using WMI instead of running it manually on the spot.

So again, anyone have any clue why running the msi locally with TARGETDIR set 
in a custom action would result in the directories being placed in the wrong 
spots?  And why running the same msi through WMI would put them in the right 
places?

Thanks
Mark

-----Original Message-
From: Mark Modrall [mailto:mmodrall@...]
Sent: Wednesday, September 28, 2011 3:57 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Dealing with ICE48 warning
Hi...
Our installers are used internally to install to a farm, so we 
had

In our old Wix 2.0 scripts.  We recently updated to Wix 3.5, and I started 
getting ICE48 warnings.  I googled around on how to do this "properly", and I 
found some posts about moving the definition of the target directory to a 
custom action "at an early stage".

So I replaced the definition above with
  
  NOT 
Installed




That did get rid of the warning, but now when I run the 
installers produced most of the subdirectories end up at C:\ instead - except 
for a couple which end up in the right place for reasons I haven't figured out.

For example, my main msi wxs file has



...













The Component under Binaries ends up in 
C:\OurPath\Binaries\InstallConfig.exe,  but PTCore's contents end up in 
C:\Binaries.

The AspModule ends up in C:\ASP\, but PttModule ends up in 
C:\OurPath\Ptt.

So

a)  did I just pick the wrong way to deal with ICE 48?  Or more 
importantly, what did I do wrong?

b)  What's the "right" way?

c)   Any guesses why some directories would seem to work and others not?

Seems like I should just live with the warnings until I figure out how to do it 
right...

Thanks
mark




--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dealing with ICE48 warning

[Mark Modrall]

I re-read some of the posts I found on Google, and in them they say to move the 
custom action to "before CostFinalize" where I had before CostInitialize.

I made the change, and it worked.  Not clear why it seemed to work partially 
when done before CostInitialize, though.

Thanks
Mark


-Original Message-----
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Wednesday, September 28, 2011 3:57 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Dealing with ICE48 warning

Hi...

Our installers are used internally to install to a farm, so we 
had



In our old Wix 2.0 scripts.  We recently updated to Wix 3.5, and I started 
getting ICE48 warnings.  I googled around on how to do this "properly", and I 
found some posts about moving the definition of the target directory to a 
custom action "at an early stage".

So I replaced the definition above with

  
  NOT 
Installed




That did get rid of the warning, but now when I run the 
installers produced most of the subdirectories end up at C:\ instead - except 
for a couple which end up in the right place for reasons I haven't figured out.

For example, my main msi wxs file has



...













The Component under Binaries ends up in 
C:\OurPath\Binaries\InstallConfig.exe,  but PTCore's contents end up in 
C:\Binaries.

The AspModule ends up in C:\ASP\, but PttModule ends up in 
C:\OurPath\Ptt.

So

a)  did I just pick the wrong way to deal with ICE 48?  Or more 
importantly, what did I do wrong?

b)  What's the "right" way?

c)   Any guesses why some directories would seem to work and others not?

Seems like I should just live with the warnings until I figure out how to do it 
right...

Thanks
mark




--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Dealing with ICE48 warning

[Mark Modrall]

Hi...

Our installers are used internally to install to a farm, so we 
had



In our old Wix 2.0 scripts.  We recently updated to Wix 3.5, and I started 
getting ICE48 warnings.  I googled around on how to do this "properly", and I 
found some posts about moving the definition of the target directory to a 
custom action "at an early stage".

So I replaced the definition above with

  
  NOT 
Installed




That did get rid of the warning, but now when I run the 
installers produced most of the subdirectories end up at C:\ instead - except 
for a couple which end up in the right place for reasons I haven't figured out.

For example, my main msi wxs file has



...













The Component under Binaries ends up in 
C:\OurPath\Binaries\InstallConfig.exe,  but PTCore's contents end up in 
C:\Binaries.

The AspModule ends up in C:\ASP\, but PttModule ends up in 
C:\OurPath\Ptt.

So

a)  did I just pick the wrong way to deal with ICE 48?  Or more 
importantly, what did I do wrong?

b)  What's the "right" way?

c)   Any guesses why some directories would seem to work and others not?

Seems like I should just live with the warnings until I figure out how to do it 
right...

Thanks
mark




--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Strange behavior with date modifying of installed files

[Mark Modrall]

Nope, FILETIME is not timezone aware...  

Want to hear something even stranger?  When you ask for a FILETIME to be 
resolved, it uses the "is daylight savings time?" setting from *now*, not the 
date on the file to adjust the timestamp.

Want to hear something even stranger than that?  The C runtime library function 
_stat() has the same daylight savings time behavior because underneath it's all 
driven by the FILETIME behavior.

When I reported it as a bug to Microsoft, it took months to get to the bottom 
of it.  Finally got to one of the OS engineers who said #1 was because some OS 
processes were checking mod timestamps on logs a lot, and it was too much of a 
performance drag to re-calculate the DST offset every time.

On #2, they said "Well, people are depending on it working this way now"

My response was The answer to the question "When was FDR's last Fireside chat?" 
shouldn't be "Depends...  what day is it today?"

Mark


-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com] 
Sent: Wednesday, September 28, 2011 10:59 AM
To: General discussion for Windows Installer XML toolset.; General discussion 
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Strange behavior with date modifying of installed files

I did some googling but had decided not to post since I'm not an expert.  I 
found some doco in MSDN describing a structure with Date and Time fields 
and a note saying that it's generally date modified but that the meaning is 
up to the application.  Nothing in the datatype seemed to be UTC aware.


I also found some SDK doco down in DTF describing date time members for 
local and and UTC but I suspect that's just translating the time provided 
and then applying it to the CAB at which point probably becomes lossy.


An interesting thought excercise would be to use InstallShield and WiX to 
consume the same set of files and deploy them to a VM and see if they 
express differently.   Then again, I don't really find it a problem one way 
or the other as datetimes are meaningless to me.  I care about version 
numbers and file hashes.



From: "Rob Mensching" 

Sent: Wednesday, September 28, 2011 9:19 AM

To: "General discussion for Windows Installer XML toolset." 


Subject: Re: [WiX-users] Strange behavior with date modifying of installed 
files


I believe this is a limitation of .cab files that store the times as

FILETIME. Timezone is not stored. I'd be happy to be wrong if someone 
could

show otherwise.


On Wed, Sep 28, 2011 at 4:53 AM, Grigory Konovalov <

grigory.konova...@confirmit.com> wrote:


> Why WIX save local time for files, but doesn't save UTC time?

> For example, a file has 10.00 time modified in a server with UTC+01.00 
(it

> is 9.00 in UTC time).

> I create msi on this server and install it on a new server with 
UTC-01.00.

> The file have 10.00 time modified on the new server after installation, 
but

> there should be 8.00 time (real date creation 9.00 in UTC minus 1 hour 
of

> time zone).

> If we change UTC on the new server to UTC+01.00 like on the first 
server,

> modified time will change to 12.00 (it is 11.00 in UTC time).

> Therefore modified date increase on 2 hours.

> I guess, it is strange.

>

> Grigory Konovalov

> Software Engineer

> grigory.konova...@confirmit.com 
|

> Phone +7 4852 586 924 | Mobile +7 902 221 6886

>

> Confirmit(r) [everywhere]

>

> Software for Market Research and Enterprise Feedback Management

>

> Confirmit Ltd., 56 Lisizina str., Yaroslavl, Russia, 150014

> www.confirmit.com | Main/fax +7 4852 586 924; 
+7

> 4852 586 925

>

> The information contained in this email message may be privileged,

> confidential or exempt from disclosure under applicable law. If you are 
not

> the intended recipient, you are hereby notified that any use, 
dissemination,

> distribution or copying of this transmission is strictly prohibited. If 
you

> have received this communication in error, or if any problems occur with

> transmission, please notify the sender immediately.

>

>

> 

--

> All the data continuously generated in your IT infrastructure contains a

> definitive record of customers, application performance, security

> threats, fraudulent activity and more. Splunk takes this data and makes

> sense of it. Business sense. IT sense. Common sense.

> http://p.sf.net/sfu/splunk-d2dcopy1

> ___

> WiX-users mailing list

> WiX-users@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/wix-users

>

>


-- 

virtually, Rob Mensching - http://RobMensching.com LLC


--

All the data continuously generated in your IT infrastructure contains a

definitive record of customers, application perf

Re: [WiX-users] Dependency warnings I don't quite get...

[Mark Modrall]

Thanks Bill, adding the guide to the dependency id seems to have done the trick!

Mark


-Original Message-
From: bpackard [mailto:bill.pack...@kepware.com] 
Sent: Monday, September 26, 2011 9:45 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dependency warnings I don't quite get...

Mark,

When I have dependencies, I have had to include the GUID of the merge module
in the dependency declaration, in order to match the signature.


Try adding the GUID to the dependency declaration:
 

bill packard

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dependency-warnings-I-don-t-quite-get-tp6825122p6831923.html
Sent from the wix-users mailing list archive at Nabble.com.

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dependency warnings I don't quite get...

[Mark Modrall]

D'oh...  The html encoding of your example threw me...  I get it now.  Guid 
goes *in* the RequiredId...

Thanks
mark


-Original Message-
From: bpackard [mailto:bill.pack...@kepware.com] 
Sent: Monday, September 26, 2011 9:45 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dependency warnings I don't quite get...

Mark,

When I have dependencies, I have had to include the GUID of the merge module
in the dependency declaration, in order to match the signature.


Try adding the GUID to the dependency declaration:
 

bill packard

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dependency-warnings-I-don-t-quite-get-tp6825122p6831923.html
Sent from the wix-users mailing list archive at Nabble.com.

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dependency warnings I don't quite get...

[Mark Modrall]

Thanks Bill...

I just checked the man page for the Dependency element 
(http://wix.sourceforge.net/manual-wix3/wix_xsd_dependency.htm) and I don't see 
a GUID attribute on the node.  Is it just missing from the documentation?

Mark


-Original Message-
From: bpackard [mailto:bill.pack...@kepware.com] 
Sent: Monday, September 26, 2011 9:45 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dependency warnings I don't quite get...

Mark,

When I have dependencies, I have had to include the GUID of the merge module
in the dependency declaration, in order to match the signature.


Try adding the GUID to the dependency declaration:
 

bill packard

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dependency-warnings-I-don-t-quite-get-tp6825122p6831923.html
Sent from the wix-users mailing list archive at Nabble.com.

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dependency warnings I don't quite get...

[Mark Modrall]

Okay, I double-checked with Orca, and the msi has PTCoreModule with 
Language=1033, Version=1.0.0.0 in the ModuleSignature table, and all the 
references to it in the ModuleDependency table have RequiredLanguage=1033, 
RequiredVersion=1.0.0.0.

So I'm still not understanding why I'm getting the warning.

Thanks
Mark


-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Saturday, September 24, 2011 3:21 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dependency warnings I don't quite get...

On 24-Sep-11 15:06, Mark Modrall wrote:
> I know that's what the error message description says, but I'm not seeing 
> what I'm missing.

Use Orca to see if the resources in the merge module were merged in. If 
they weren't, the warning is telling you the merge module wasn't merged 
into the .msi.

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


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dependency warnings I don't quite get...

[Mark Modrall]

Thanks Bob and Ed...

Actually installing the msi on a machine, I see that the merge module did, in 
fact, get into the package.  It's there post install and nothing would run 
without it.

That's among the things that puzzles me about the warning.

Thanks
mark


From: Bob Arnson [b...@joyofsetup.com]
Sent: Saturday, September 24, 2011 3:21 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Dependency warnings I don't quite get...

On 24-Sep-11 15:06, Mark Modrall wrote:
> I know that's what the error message description says, but I'm not seeing 
> what I'm missing.

Use Orca to see if the resources in the merge module were merged in. If
they weren't, the warning is telling you the merge module wasn't merged
into the .msi.

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


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dependency warnings I don't quite get...

[Mark Modrall]

I know that's what the error message description says, but I'm not seeing what 
I'm missing.  In the example below, PTCoreModule is declared as described, and 
all 8 other modules that have a Dependency on it declare that dependency as 
below - yet all 8 are issuing the ICE25 errors.

I mean, it *looks* like PTCoreModule is declaring the same language and version 
as all the Dependencies, but the errors are coming anyway.

That's what i don't get...

Thanks
Mark


From: Rob Mensching [r...@robmensching.com]
Sent: Saturday, September 24, 2011 2:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dependency warnings I don't quite get...

The Merge Modules you're are pulling in have declared dependencies on Merge
Modules you have not added to your project.  Or the identifiers are not
matching correctly.

On Fri, Sep 23, 2011 at 10:53 AM, Mark Modrall  wrote:

> Hi...
>
>I'm getting a bunch of ICE25 warnings about dependencies
> missing, and I'm not quite getting what I'm doing wrong...
>
>To give some examples, I have a merge module with
>  
> ...
>  
>
>  There are several other merge modules that have
>  RequiredVersion="1.0.0.0" />
>
>My Product package merges a lot of these modules
>  SourceFile="..\PTCoreModule\bin\Release\PTCoreModule.msm" DiskId="1" />
>  SourceFile="..\OtherModule\bin\Release\PTCookiesModule.msm" DiskId="1" />
> ...
> 
>
> But I'm getting these warnings from every module that has a dependency on
> PTCoreModule:
> 23>light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as
> we do not find PTCoreModule@1033 v1.0.0.0 in ModuleSignature table
>
>I tried re-ordering the merge list so the main dependencies
> came first, thinking it might have been a single-pass process that hadn't
> seen it yet but that didn't help.
>
>I'm getting ~20-30 of these warnings for every package
> built.  Looks like things should be okay, so what am I missing?
>
> Thanks
> Mark
>
>
> --
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


--
virtually, Rob Mensching - http://RobMensching.com LLC
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Build vs rebuild with wix

[Mark Modrall]

We're just moving up from Wix 2.0 to wix 3.5.  In Wix 2.0, we always did a 
rebuild on the solution (I presume because the people who came before me didn't 
think wix would be able to differentiate whether anything changed and needed 
rebuilding).

Now with Wix 3.5 I thought I'd ask whether the wixproj's remembered enough 
state to make a good differentiation between build and rebuild?

Just asking because our Wix project is taking 20 minutes to run rebuild and if 
it could take a good stab  as build it might reduce the build time...

Thanks
Mark

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Dependency warnings I don't quite get...

[Mark Modrall]

Hi...

I'm getting a bunch of ICE25 warnings about dependencies 
missing, and I'm not quite getting what I'm doing wrong...

To give some examples, I have a merge module with
  
...
  

  There are several other merge modules that have


My Product package merges a lot of these modules


...


But I'm getting these warnings from every module that has a dependency on 
PTCoreModule:
23>light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we 
do not find PTCoreModule@1033 v1.0.0.0 in ModuleSignature table

I tried re-ordering the merge list so the main dependencies 
came first, thinking it might have been a single-pass process that hadn't seen 
it yet but that didn't help.

I'm getting ~20-30 of these warnings for every package built.  
Looks like things should be okay, so what am I missing?

Thanks
Mark

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] question in Wix 2.0

[Mark Modrall]

Okay, this may be my leverage to upgrade...

Account="NT Authority\NetworkService" *installed* but did not set the Log On 
account under Wix 2.0.  The other variants failed with error 1923.

But Account="NT Authority\NetworkService" installed and did set the Log On 
account using Wix 3.5.

So now I can tell the people who want this fixed that they'll need to take the 
newer Wix and I can stop pestering people here for debugging help on the Dead 
Sea Scrolls :)

Thanks
Mark


-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Tuesday, August 23, 2011 11:52 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]  question in Wix 2.0

Thanks for the reply Michael...

I tried changing it to Builtin\NetworkService and then to 
[ComputerName]\NetworkService, but then I started getting
Error 1923. Service 'Prospero Chat Service' (DChatServer) could not be 
installed.  Verify that you have sufficient privileges to install system 
services.

I'm an admin on the box so the latter portion of the message doesn't seem to 
apply, but it didn't seem to like either of the alternatives...

Thanks
mark


-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au] 
Sent: Monday, August 22, 2011 6:06 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]  question in Wix 2.0

Mark

Not 100% sure on this answer, but try BuiltIn\NetworkService or 
[ComputerName]\NetworkService

Michael

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Tuesday, 23 August 2011 8:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users]  question in Wix 2.0

Hi...

Sorry to keep asking questions about Wix 2.0, but I haven't 
gotten clearance to upgrade the tools.

I'm trying to get a windows service to install running under 
the NETWORK SERVICE account for some new dependencies.  I tried adding 
Account="NT Authority\NetworkService" to my  node, but for some 
reason it doesn't seem to be having any impact.  The installer runs, the code 
gets installed and in the end it's still running under Local System.

Here's my whole node:




Am I doing something obviously wrong?

Thanks
mark

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] question in Wix 2.0

[Mark Modrall]

Thanks for the reply Michael...

I tried changing it to Builtin\NetworkService and then to 
[ComputerName]\NetworkService, but then I started getting
Error 1923. Service 'Prospero Chat Service' (DChatServer) could not be 
installed.  Verify that you have sufficient privileges to install system 
services.

I'm an admin on the box so the latter portion of the message doesn't seem to 
apply, but it didn't seem to like either of the alternatives...

Thanks
mark


-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au] 
Sent: Monday, August 22, 2011 6:06 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]  question in Wix 2.0

Mark

Not 100% sure on this answer, but try BuiltIn\NetworkService or 
[ComputerName]\NetworkService

Michael

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Tuesday, 23 August 2011 8:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users]  question in Wix 2.0

Hi...

Sorry to keep asking questions about Wix 2.0, but I haven't 
gotten clearance to upgrade the tools.

I'm trying to get a windows service to install running under 
the NETWORK SERVICE account for some new dependencies.  I tried adding 
Account="NT Authority\NetworkService" to my  node, but for some 
reason it doesn't seem to be having any impact.  The installer runs, the code 
gets installed and in the end it's still running under Local System.

Here's my whole node:




Am I doing something obviously wrong?

Thanks
mark

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] question in Wix 2.0

[Mark Modrall]

Hi...

Sorry to keep asking questions about Wix 2.0, but I haven't 
gotten clearance to upgrade the tools.

I'm trying to get a windows service to install running under 
the NETWORK SERVICE account for some new dependencies.  I tried adding 
Account="NT Authority\NetworkService" to my  node, but for some 
reason it doesn't seem to be having any impact.  The installer runs, the code 
gets installed and in the end it's still running under Local System.

Here's my whole node:




Am I doing something obviously wrong?

Thanks
mark

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Installers on the newer, fussier OS'es

[Mark Modrall]

Hi All...

We're in the process of moving up from Windows 2003 to 2008.  
As such, we're running into all those extra fussy security features - such as 
the distinction between being in the Administrator group and *running as 
administrator*, and all of the additional "Do you really want to do this?" 
dialogs.

We have our own home-brew system for remote managing systems 
with WMI and psexec.

Are there options one can specify in Wix to get past all the 
extra security dialogs on 2008, or do you have to change policies on the box or 
something?

Thanks
Mark

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Okay, I'm sure this is going to sound like a dumb question, but...

In these old Wix 2.0 projects I'm upgrading, we generate a bunch of msms that 
get pulled into the several product msis.  In the module projects there was 
something like the following:
  

...

  

Then the  references would be included in the product directory tree.  

Chalk it up to my ignorance, but I thought the  in 
the modules seemed superfluous, so trying to clean things up while I did the 
upgrade, I removed them - thinking that the  element in the desired 
 of the Product was sufficient to say where I wanted the result put.

The msis all build but when I went to install one, all of the msm output gets 
dumped in the Product INSTALLDIR, not in the subdirectory defined in the 
Product setup.

Below are some examples of what I mean, and I was just wondering why the 
modules had to have that extra directory declaration?  Obviously there's 
something I'm missing.

Thanks
Mark



  
  

   
  
  
 
   
 
  
   


  


Included in

  http://www.prospero.com"; InstallerVersion="300" 
InstallScope="perMachine" Compressed="yes"/>
  
  
  



  
  





  
  

  




--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Okay, I compared the output of the msbuild log and the devenv log.  When it 
comes to this one project, the only difference in the candle command arguments 
was

-d"DevEnvDir=*Undefined if not building from within Visual Studio*"

And the light arguments were the same.

But for some result the outputs are not the same.

It does work if I use devenv.exe from the command line so I guess I'll stick 
with that...

Thanks
Mark

-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com] 
Sent: Wednesday, July 20, 2011 11:37 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

VS2010 includes the same MSBuild concept than building within MSBuild
directly. Try to build it within VS2010 and then copy the commands
from build output and maybe remove the product.generated.* stuff and
try it that way.

What's the output when building it in visual studio Command Prompt ?
Mean there "msbuild mySolution.sln" ?

2011/7/20 Mark Modrall :
> Thanks for the link, Bob; I'll give it a read.
>
> By the by, are there known quirks when running a Wix solution via msbuild?  
> My build works just fine when I'm in VS 2010, but when I use msbuild to 
> launch it there's one module that doesn't build and doesn't give any errors.
>
> In the build log, I see candle and light getting run, but in obj\Release I 
> only see Product.Generated.wxs and nothing in bin\Release (no merge module).
>
> What's in the log is below.  The other wix projects are producing msm and msi 
> but for some reason this one quirks out.  Should I be using devenv.exe on the 
> command line instead?
>
> Thanks
> Mark
>
> Compile:
>  C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe 
> -d"DevEnvDir=*Undefined if not building from within Visual Studio*" 
> -dSolutionDir=C:\svn\trunk\Installation\Wix\ -dSolutionExt=.sln 
> -dSolutionFileName=AllProducts.sln -dSolutionName=AllProducts 
> -dSolutionPath=C:\svn\trunk\Installation\Wix\AllProducts.sln 
> -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 
> -dProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ -dProjectExt=.wixproj 
> -dProjectFileName=PttModule.wixproj -dProjectName=PttModule 
> -dProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj 
> -dTargetDir=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\ 
> -dTargetExt=.msm -dTargetFileName=PttModule.msm -dTargetName=PttModule 
> -dTargetPath=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm
>  -dPttPreBuild.Configuration=Release 
> -d"PttPreBuild.FullConfiguration=Release|Win32" -dPttPreBuild.Platform=Win32 
> -dPttPreBuild.ProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ 
> -dPttPreBuild.ProjectExt=.vcxproj 
> -dPttPreBuild.ProjectFileName=PttPreBuild.vcxproj 
> -dPttPreBuild.ProjectName=PttPreBuild 
> -dPttPreBuild.ProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttPreBuild.vcxproj
>  -dPttPreBuild.TargetDir=C:\svn\trunk\Installation\Wix\PttModule\ 
> -dPttPreBuild.TargetExt=.wxi -dPttPreBuild.TargetFileName=Ptt.wxi 
> -dPttPreBuild.TargetName=Ptt 
> -dPttPreBuild.TargetPath=C:\svn\trunk\Installation\Wix\PttModule\Ptt.wxi -out 
> obj\Release\ -arch x86 PttModule.wxs obj\Release\Product.Generated.wxs
>  Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0
>  Copyright (C) Microsoft Corporation. All rights reserved.
>
>  PttModule.wxs
>  Product.Generated.wxs
> Link:
>  C:\Program Files (x86)\Windows Installer XML v3.5\bin\Light.exe 
> -cultures:null -out 
> C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm -pdbout 
> C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.wixpdb 
> obj\Release\PttModule.wixobj obj\Release\Product.Generated.wixobj
>  Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0
>  Copyright (C) Microsoft Corporation. All rights reserved.
>
> Done Building Project 
> "C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj" (default targets).
>
> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: Wednesday, July 20, 2011 12:45 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 
> to 2010
>
> On 19-Jul-11 12:25, Mark Modrall wrote:
>> For #2, we have some installation stuff we only want done once (the stuff 
>> that the custom action does).  So the first thing the custom action exe does 
>> is try to check the registry setting to see if it's been done (that's what's 
>> failing now).  When the custom action code is done, it sets that registry 
>> flag to show it's been done.
> See http:/

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Thanks for the link, Bob; I'll give it a read.

By the by, are there known quirks when running a Wix solution via msbuild?  My 
build works just fine when I'm in VS 2010, but when I use msbuild to launch it 
there's one module that doesn't build and doesn't give any errors.

In the build log, I see candle and light getting run, but in obj\Release I only 
see Product.Generated.wxs and nothing in bin\Release (no merge module).

What's in the log is below.  The other wix projects are producing msm and msi 
but for some reason this one quirks out.  Should I be using devenv.exe on the 
command line instead?

Thanks
Mark

Compile:
  C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe 
-d"DevEnvDir=*Undefined if not building from within Visual Studio*" 
-dSolutionDir=C:\svn\trunk\Installation\Wix\ -dSolutionExt=.sln 
-dSolutionFileName=AllProducts.sln -dSolutionName=AllProducts 
-dSolutionPath=C:\svn\trunk\Installation\Wix\AllProducts.sln 
-dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 
-dProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ -dProjectExt=.wixproj 
-dProjectFileName=PttModule.wixproj -dProjectName=PttModule 
-dProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj 
-dTargetDir=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\ 
-dTargetExt=.msm -dTargetFileName=PttModule.msm -dTargetName=PttModule 
-dTargetPath=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm 
-dPttPreBuild.Configuration=Release 
-d"PttPreBuild.FullConfiguration=Release|Win32" -dPttPreBuild.Platform=Win32 
-dPttPreBuild.ProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ 
-dPttPreBuild.ProjectExt=.vcxproj 
-dPttPreBuild.ProjectFileName=PttPreBuild.vcxproj 
-dPttPreBuild.ProjectName=PttPreBuild 
-dPttPreBuild.ProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttPreBuild.vcxproj
 -dPttPreBuild.TargetDir=C:\svn\trunk\Installation\Wix\PttModule\ 
-dPttPreBuild.TargetExt=.wxi -dPttPreBuild.TargetFileName=Ptt.wxi 
-dPttPreBuild.TargetName=Ptt 
-dPttPreBuild.TargetPath=C:\svn\trunk\Installation\Wix\PttModule\Ptt.wxi -out 
obj\Release\ -arch x86 PttModule.wxs obj\Release\Product.Generated.wxs
  Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0
  Copyright (C) Microsoft Corporation. All rights reserved.
  
  PttModule.wxs
  Product.Generated.wxs
Link:
  C:\Program Files (x86)\Windows Installer XML v3.5\bin\Light.exe 
-cultures:null -out 
C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm -pdbout 
C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.wixpdb 
obj\Release\PttModule.wixobj obj\Release\Product.Generated.wixobj
  Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0
  Copyright (C) Microsoft Corporation. All rights reserved.
  
Done Building Project 
"C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj" (default targets).

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Wednesday, July 20, 2011 12:45 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

On 19-Jul-11 12:25, Mark Modrall wrote:
> For #2, we have some installation stuff we only want done once (the stuff 
> that the custom action does).  So the first thing the custom action exe does 
> is try to check the registry setting to see if it's been done (that's what's 
> failing now).  When the custom action code is done, it sets that registry 
> flag to show it's been done.
See http://www.joyofsetup.com/2007/07/01/semi-custom-actions/.

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


--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Hi Bob...

For #2, we have some installation stuff we only want done once (the stuff that 
the custom action does).  So the first thing the custom action exe does is try 
to check the registry setting to see if it's been done (that's what's failing 
now).  When the custom action code is done, it sets that registry flag to show 
it's been done.  As I said a lot that stuff just used to slide by in Windows 
Server 2003 when running as an administrator...

Thanks
Mark


-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Tuesday, July 19, 2011 11:45 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

On 19-Jul-11 11:10, Mark Modrall wrote:
> 1) Looking at the installer log, it's unpacking into a directory other than 
> the INSTALLDIR; throughout I've been a little confused going to 3.5 about the 
> relation of INSTALLDIR and TARGETDIR; did TARGETDIR supplant/replace 
> INSTALLDIR?  As noted before, I used to have my root Id="INSTALLDIR">  and 3.5 said it had to be TARGETDIR; was I to take from 
> that it should be TARGETDIR throughout?

WiX v2 and v3 have the same requirements about TARGETDIR, because that's 
what MSI requires. INSTALLDIR is just a convention.

> 2) I have a custom action in my installer, and that needs to look at/tweak 
> registry settings.

Custom actions should be avoided for things like registry that MSI 
already handles. What do you need to do that you can't do in MSI?

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


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Thanks Bob, that got the content into the installer package - which got me to 
the point of trying to run it.

I ran into a couple of new issues
1) Looking at the installer log, it's unpacking into a directory other than the 
INSTALLDIR; throughout I've been a little confused going to 3.5 about the 
relation of INSTALLDIR and TARGETDIR; did TARGETDIR supplant/replace 
INSTALLDIR?  As noted before, I used to have my root  and 3.5 said it had to be TARGETDIR; was I to take from that 
it should be TARGETDIR throughout?

2) I have a custom action in my installer, and that needs to look at/tweak 
registry settings.  On top of moving from VS 2005 to VS 2010, we're also trying 
to move from Server 2003 to Server 2008, and like Windows 7, etc it's a lot 
more snarky about execution permissions.  I saw this in the 3.5 manual for the 
 element:

Impersonate YesNoType This attribute specifies whether the Windows Installer, 
which executes as LocalSystem, should impersonate the user context of the 
installing user when executing this custom action. Typically the value should 
be 'yes', except when the custom action needs elevated privileges to apply 
changes to the machine.

To run things that need more serious access, I take it I should have an 
attribute Impersonate="no"?

Thanks
mark


-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Tuesday, July 19, 2011 10:33 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

On 19-Jul-11 10:20, Mark Modrall wrote:
>Comments="bar" InstallerVersion="300" Platform="$(var.PPlat)"/>

Try Compressed="yes".

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


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Hi...

I'm trying to upgrade my Wix 2.0 installer scripts to Wix 3.5, and at 
the moment I'm stuck on the fact that my product msi's are coming out 
essentially empty and I don't see why.  The individual merge modules look like 
they're about the right size but none of the content is ending up in the msi.  
I'm seeing the empty shell of the directory structures in .\bin\Release\ for 
the product installer but none of the files are in there either.

The project below used to work in 2.0; essentially all I tweaked so far 
was the InstallerVersion and the root Directory Id="TARGETDIR" instead of 
INSTALLDIR.

I've found some 3.5 sample projects, and the biggest difference I can 
see is a lot more use of DirectoryRef and ComponentRef in .

Does anyone see if I'm doing something obviously wrong in a 3.5 sense?

Thanks
Mark

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

  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  







... bunch more merges















... bunch more mergerefs



2
3



--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

I guess I spoke too soon...  Early in the Wix 2.0 => 3.5 upgrade, I was seeing 
the error:
Error   54  The Directory with Id 'INSTALLDIR' is not a valid root 
directory.  There may only be a single root directory per product or module and 
its Id attribute value must be 'TARGETDIR' and its Name attribute value must be 
'SourceDir'. 

So I switched the root Directory Id="TARGETDIR" and the error stopped happening 
- *but* when I looked more closely at the output, my .msi was nearly empty and 
all the subdirectories that were supposed to be *in* the msi are instead peer 
directories to it in MyProduct\bin\Release\.

Seems like there's some 2.0/3.5 incompatibility speed bump I haven't 
internalized yet...

Any tips?

Thanks
Mark

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Monday, July 18, 2011 5:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

Thanks for your response, Pally...

I've got things converted over for the most part but am still puzzled by a few 
new warnings.

One is this one:
Warning 58  ICE25: Possible dependency failure as we do not find 
@1033 v in ModuleSignature table   light.exe   0   1   
MyProduct

All my modules have Language="1033" in them, so I'm puzzled what the warning is 
about.

The other is that when I have:


In my build projects, I get the warning
The cabinet 'Product.cab' does not contain any files.  If this 
installation contains no files, this warning can likely be safely ignored.  
Otherwise, please add files to the cabinet or remove it.

But if I don't have it, I get a lot of errors about having an undefined media 
reference with the DiskId="1" attributes on file and module refs.  If I take 
the DiskId="1" off, it says it's required.

Warnings are better than errors, but I'm trying to understand what's driving 
them.

Thanks
Mark

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Monday, July 18, 2011 7:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

I don't think there is an upgrade from v2.0 .wixproj to v3.x. Votive was very 
much experimental & unsupported in WiX v2.0.

You're probably better off creating new .wixproj files in v3.5 as it's pretty 
quick to do.

Palbinder Sandher 
Software Deployment Engineer
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer
-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 17 July 2011 15:16
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

I had been running msbuild to product my msis and it wasn't throwing any 
errors, but now I went into my solution using the IDE (both 2005 and 2010).  In 
both I get the error that I have to use the IDE to upgrade my .wixproj  (2.0) 
files but in the IDE it just says all the projects are (unavailable).  I'm not 
prompted for upgrade nor does VS appear to do them.

It 2.0 => 3.5 just too big a jump for automated upgrade?

Thanks
Mark


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Saturday, July 16, 2011 1:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

The Windows Installer Error Message
http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says:


2756

The property '[2]' was used as a directory property in one or more tables,
but no value was ever assigned.


That suggest something is wrong in your MSI. A verbose log file will
probalby tell you more.



On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall  wrote:

> Hi everybody...
>
>I imagine I'll take some flak for this, but we still have
> installers being cobbled together by Wix 2.0.
>
> Recently I was tasked with upgrading our product builds from VS 2005 to VS
> 2010 (and moving our production environment from Windows Server 2003 to
> 2008).  I just got all the product build converted and running under VS 2010
> (with a side nightmare thanks to Sourcegear Vault).  My Wix project cranked
> out .msis without complaint.
>
>But when I went to install the msi on Windows 2008, it threw
> an exception 2765.  Not a lot of information on what the problem is.  Not
> sure if it's s

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Thanks for your response, Pally...

I've got things converted over for the most part but am still puzzled by a few 
new warnings.

One is this one:
Warning 58  ICE25: Possible dependency failure as we do not find 
@1033 v in ModuleSignature table   light.exe   0   1   
MyProduct

All my modules have Language="1033" in them, so I'm puzzled what the warning is 
about.

The other is that when I have:


In my build projects, I get the warning
The cabinet 'Product.cab' does not contain any files.  If this 
installation contains no files, this warning can likely be safely ignored.  
Otherwise, please add files to the cabinet or remove it.

But if I don't have it, I get a lot of errors about having an undefined media 
reference with the DiskId="1" attributes on file and module refs.  If I take 
the DiskId="1" off, it says it's required.

Warnings are better than errors, but I'm trying to understand what's driving 
them.

Thanks
Mark

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Monday, July 18, 2011 7:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

I don't think there is an upgrade from v2.0 .wixproj to v3.x. Votive was very 
much experimental & unsupported in WiX v2.0.

You're probably better off creating new .wixproj files in v3.5 as it's pretty 
quick to do.

Palbinder Sandher 
Software Deployment Engineer
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer
-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: 17 July 2011 15:16
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

I had been running msbuild to product my msis and it wasn't throwing any 
errors, but now I went into my solution using the IDE (both 2005 and 2010).  In 
both I get the error that I have to use the IDE to upgrade my .wixproj  (2.0) 
files but in the IDE it just says all the projects are (unavailable).  I'm not 
prompted for upgrade nor does VS appear to do them.

It 2.0 => 3.5 just too big a jump for automated upgrade?

Thanks
Mark


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Saturday, July 16, 2011 1:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

The Windows Installer Error Message
http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says:


2756

The property '[2]' was used as a directory property in one or more tables,
but no value was ever assigned.


That suggest something is wrong in your MSI. A verbose log file will
probalby tell you more.



On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall  wrote:

> Hi everybody...
>
>I imagine I'll take some flak for this, but we still have
> installers being cobbled together by Wix 2.0.
>
> Recently I was tasked with upgrading our product builds from VS 2005 to VS
> 2010 (and moving our production environment from Windows Server 2003 to
> 2008).  I just got all the product build converted and running under VS 2010
> (with a side nightmare thanks to Sourcegear Vault).  My Wix project cranked
> out .msis without complaint.
>
>But when I went to install the msi on Windows 2008, it threw
> an exception 2765.  Not a lot of information on what the problem is.  Not
> sure if it's some kind of difference between W2003 and 2008, the version of
> the msi installer on the os or what.  It did say there was one specific
> merge module at the time, a .net assembly that was going to be put in the
> gac.
>
>I'd run Wix under VS 2005 figuring that the bundling of the
> build product didn't need to be upgraded, but to start eliminating variables
> I upgraded the Wix solution to VS 2010 and tried the msi outcome of that.
>  Same error.
>
>I went to install Wix 3 (baby steps), but that installer
> still only offered VS 2005 integration.
>
>I haven't worked with Windows Server 2008 much and I haven't
> seen this installer error before.  Is this a Wix compatibility issue or an
> OS issue?
>
> Thanks
> Mark
>
>
> --
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

I had been running msbuild to product my msis and it wasn't throwing any 
errors, but now I went into my solution using the IDE (both 2005 and 2010).  In 
both I get the error that I have to use the IDE to upgrade my .wixproj  (2.0) 
files but in the IDE it just says all the projects are (unavailable).  I'm not 
prompted for upgrade nor does VS appear to do them.

It 2.0 => 3.5 just too big a jump for automated upgrade?

Thanks
Mark


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Saturday, July 16, 2011 1:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

The Windows Installer Error Message
http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says:


2756

The property '[2]' was used as a directory property in one or more tables,
but no value was ever assigned.


That suggest something is wrong in your MSI. A verbose log file will
probalby tell you more.



On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall  wrote:

> Hi everybody...
>
>I imagine I'll take some flak for this, but we still have
> installers being cobbled together by Wix 2.0.
>
> Recently I was tasked with upgrading our product builds from VS 2005 to VS
> 2010 (and moving our production environment from Windows Server 2003 to
> 2008).  I just got all the product build converted and running under VS 2010
> (with a side nightmare thanks to Sourcegear Vault).  My Wix project cranked
> out .msis without complaint.
>
>But when I went to install the msi on Windows 2008, it threw
> an exception 2765.  Not a lot of information on what the problem is.  Not
> sure if it's some kind of difference between W2003 and 2008, the version of
> the msi installer on the os or what.  It did say there was one specific
> merge module at the time, a .net assembly that was going to be put in the
> gac.
>
>I'd run Wix under VS 2005 figuring that the bundling of the
> build product didn't need to be upgraded, but to start eliminating variables
> I upgraded the Wix solution to VS 2010 and tried the msi outcome of that.
>  Same error.
>
>I went to install Wix 3 (baby steps), but that installer
> still only offered VS 2005 integration.
>
>I haven't worked with Windows Server 2008 much and I haven't
> seen this installer error before.  Is this a Wix compatibility issue or an
> OS issue?
>
> Thanks
> Mark
>
>
> --
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Hi Rob...

I enabled verbose logging and I didn't really see any more explanation 
in the log file.

I did find this old thread:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-NET-4-assemblies-into-the-GAC-using-WiX-2-td4443469.html

Which seemed to be pertinent, so I upgraded to Wix 3.5 (though I didn't 
do anything particular to change my wix projects), but no luck.  Still have the 
same error.

I found another thread where you advised someone to add a 
 entry to the light config, but I checked and light already 
had it in there.

I know this is an ignorant question, but what's the relation between 
Tallow and light?

Thanks
Mark


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Saturday, July 16, 2011 1:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 
2010

The Windows Installer Error Message
http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says:


2756

The property '[2]' was used as a directory property in one or more tables,
but no value was ever assigned.


That suggest something is wrong in your MSI. A verbose log file will
probalby tell you more.



On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall  wrote:

> Hi everybody...
>
>I imagine I'll take some flak for this, but we still have
> installers being cobbled together by Wix 2.0.
>
> Recently I was tasked with upgrading our product builds from VS 2005 to VS
> 2010 (and moving our production environment from Windows Server 2003 to
> 2008).  I just got all the product build converted and running under VS 2010
> (with a side nightmare thanks to Sourcegear Vault).  My Wix project cranked
> out .msis without complaint.
>
>But when I went to install the msi on Windows 2008, it threw
> an exception 2765.  Not a lot of information on what the problem is.  Not
> sure if it's some kind of difference between W2003 and 2008, the version of
> the msi installer on the os or what.  It did say there was one specific
> merge module at the time, a .net assembly that was going to be put in the
> gac.
>
>I'd run Wix under VS 2005 figuring that the bundling of the
> build product didn't need to be upgraded, but to start eliminating variables
> I upgraded the Wix solution to VS 2010 and tried the msi outcome of that.
>  Same error.
>
>I went to install Wix 3 (baby steps), but that installer
> still only offered VS 2005 integration.
>
>I haven't worked with Windows Server 2008 much and I haven't
> seen this installer error before.  Is this a Wix compatibility issue or an
> OS issue?
>
> Thanks
> Mark
>
>
> --
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010

[Mark Modrall]

Hi everybody...

I imagine I'll take some flak for this, but we still have 
installers being cobbled together by Wix 2.0.

Recently I was tasked with upgrading our product builds from VS 2005 to VS 2010 
(and moving our production environment from Windows Server 2003 to 2008).  I 
just got all the product build converted and running under VS 2010 (with a side 
nightmare thanks to Sourcegear Vault).  My Wix project cranked out .msis 
without complaint.

But when I went to install the msi on Windows 2008, it threw an 
exception 2765.  Not a lot of information on what the problem is.  Not sure if 
it's some kind of difference between W2003 and 2008, the version of the msi 
installer on the os or what.  It did say there was one specific merge module at 
the time, a .net assembly that was going to be put in the gac.

I'd run Wix under VS 2005 figuring that the bundling of the 
build product didn't need to be upgraded, but to start eliminating variables I 
upgraded the Wix solution to VS 2010 and tried the msi outcome of that.  Same 
error.

I went to install Wix 3 (baby steps), but that installer still 
only offered VS 2005 integration.

I haven't worked with Windows Server 2008 much and I haven't 
seen this installer error before.  Is this a Wix compatibility issue or an OS 
issue?

Thanks
Mark

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix and "tricky" environment variables

[Mark Modrall]

That's a very good question, Ed.  I've only tested it on our boxes, and we only 
ever have 1 rev of our code there at a time.

Don't know what would happen if we started installing multiple versions, but 
thanks for making that point.

Mark


-Original Message-
From: Maillet, Ed [mailto:email...@unum.com] 
Sent: Friday, February 11, 2011 8:06 AM
To: General discussion for Windows Installer XML toolset.; John Robbins
Subject: Re: [WiX-users] Wix and "tricky" environment variables

Doesn't that only work if you have one version of an assembly?

Two Acme.dlls (v1 and v2) in the gac present a problem, doesn't it?


-----Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Friday, February 11, 2011 7:19 AM
To: John Robbins; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and "tricky" environment variables

Hi John...

Actually, putting your .net pdbs in _NT_SYMBOL_PATH *does* work; that's 
why I'm trying to do it.

http://blog.softwareishardwork.com/2010/02/enable-stack-trace-line-numbers-in.html

I came to adding it to my installers after proving that it worked by 
doing it manually.

Your note about keeping the pdbs in reserve for performance reasons is 
a good one, and I'll keep that in mind.

Thanks
Mark


-Original Message-
From: John Robbins [mailto:j...@wintellect.com] 
Sent: Thursday, February 10, 2011 10:33 PM
To: General discussion for Windows Installer XML toolset.; Mark Modrall
Subject: RE: [WiX-users] Wix and "tricky" environment variables

Mark,

As someone who's concentrated on debugging and debuggers his whole career, it 
warms my heart to hear people talking about _NT_SYMBOL_PATH. :)

However, _NT_SYMBOL_PATH is only used by debuggers. The .NET StackTrace class, 
which is generating the call stacks in your exceptions, will only look for the 
PDB files in the same directory as the .EXE. So even if you add this to your 
installer, you still won't get source and line information on any exception 
stack trace.

Also, I recommend that you keep the PDB file installer separate from the main 
installer. As there's extra file I/O and overhead for reading the PDB files 
when the exceptions are thrown, you only want to install the PDB files when you 
are certain you've got a problem and need that information.

Hope it helps!

John
Wintellect
http://www.wintellect.com
+1-877-968-5528

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Thursday, February 10, 2011 6:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and "tricky" environment variables

Well, you caught me flat footed with the App Path stuff, so I could be 
misunderstanding the Symbol Server stuff :)  But here's my understanding of 
what that's about:

1) Microsoft has a public service that will vend .pdb files for Microsoft 
components and you can set _NT_SYMBOL_PATH to pull from there
1a) You can set your _NT_SYMBOL_PATH to cache the results from Symbol Server 
locally if you want with a special syntax

2) If you're using a debugger and interactively watching something, you can use 
Symbol Server directly without _NT_SYMBOL_PATH

3) For your own symbols you're on your own.  Though I gather from your question 
(SDK vs internal process), there may be a way to register your symbols in the 
Microsoft Symbol Server.

I might be missing something, but it doesn't seem like you can get away from 
_NT_SYMBOL_PATH entirely.  At the least you have to register your symbols with 
Microsoft and set _NT_SYMBOL_PATH to point at the server.

Our use is for logging exception stack traces in a database, not hands-on 
interactive debugging.  The problem is that when you put things in the GAC it's 
considered bad form (and somewhat convoluted) to put the .pdbs in the GAC too.  
If the pdbs are lying right next to the .exes and .dbgs, you don't need to use 
_NT_SYMBOL_PATH because the default behavior checks the immediate environs 
before looking in the paths defined in _NT_SYMBOL_PATH.  Alas the GAC messes 
that up.  

We've always been dumping the .pdbs in our install directory but the stack 
traces that get logged blank out on anything that's gone through the GAC 
because the executables aren't located there.  Another frustrating thing about 
the gac is that even if you have a copy of the executable, say, in the /bin 
directory of your ASP.Net application it's going to use the GAC version instead 
and not infer anything about where your symbols might be from the one in your 
/bin directory.

So we're down to getting _NT_SYMBOL_PATH set properly in our installer.  But 
not wanting the installer to keep accreting our directory on the front/back 
every time we install.  And not destroying an environment variable that's a 
shared 

Re: [WiX-users] Wix and "tricky" environment variables

[Mark Modrall]

Hi John...

Actually, putting your .net pdbs in _NT_SYMBOL_PATH *does* work; that's 
why I'm trying to do it.

http://blog.softwareishardwork.com/2010/02/enable-stack-trace-line-numbers-in.html

I came to adding it to my installers after proving that it worked by 
doing it manually.

Your note about keeping the pdbs in reserve for performance reasons is 
a good one, and I'll keep that in mind.

Thanks
Mark


-Original Message-
From: John Robbins [mailto:j...@wintellect.com] 
Sent: Thursday, February 10, 2011 10:33 PM
To: General discussion for Windows Installer XML toolset.; Mark Modrall
Subject: RE: [WiX-users] Wix and "tricky" environment variables

Mark,

As someone who's concentrated on debugging and debuggers his whole career, it 
warms my heart to hear people talking about _NT_SYMBOL_PATH. :)

However, _NT_SYMBOL_PATH is only used by debuggers. The .NET StackTrace class, 
which is generating the call stacks in your exceptions, will only look for the 
PDB files in the same directory as the .EXE. So even if you add this to your 
installer, you still won't get source and line information on any exception 
stack trace.

Also, I recommend that you keep the PDB file installer separate from the main 
installer. As there's extra file I/O and overhead for reading the PDB files 
when the exceptions are thrown, you only want to install the PDB files when you 
are certain you've got a problem and need that information.

Hope it helps!

John
Wintellect
http://www.wintellect.com
+1-877-968-5528

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Thursday, February 10, 2011 6:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and "tricky" environment variables

Well, you caught me flat footed with the App Path stuff, so I could be 
misunderstanding the Symbol Server stuff :)  But here's my understanding of 
what that's about:

1) Microsoft has a public service that will vend .pdb files for Microsoft 
components and you can set _NT_SYMBOL_PATH to pull from there
1a) You can set your _NT_SYMBOL_PATH to cache the results from Symbol Server 
locally if you want with a special syntax

2) If you're using a debugger and interactively watching something, you can use 
Symbol Server directly without _NT_SYMBOL_PATH

3) For your own symbols you're on your own.  Though I gather from your question 
(SDK vs internal process), there may be a way to register your symbols in the 
Microsoft Symbol Server.

I might be missing something, but it doesn't seem like you can get away from 
_NT_SYMBOL_PATH entirely.  At the least you have to register your symbols with 
Microsoft and set _NT_SYMBOL_PATH to point at the server.

Our use is for logging exception stack traces in a database, not hands-on 
interactive debugging.  The problem is that when you put things in the GAC it's 
considered bad form (and somewhat convoluted) to put the .pdbs in the GAC too.  
If the pdbs are lying right next to the .exes and .dbgs, you don't need to use 
_NT_SYMBOL_PATH because the default behavior checks the immediate environs 
before looking in the paths defined in _NT_SYMBOL_PATH.  Alas the GAC messes 
that up.  

We've always been dumping the .pdbs in our install directory but the stack 
traces that get logged blank out on anything that's gone through the GAC 
because the executables aren't located there.  Another frustrating thing about 
the gac is that even if you have a copy of the executable, say, in the /bin 
directory of your ASP.Net application it's going to use the GAC version instead 
and not infer anything about where your symbols might be from the one in your 
/bin directory.

So we're down to getting _NT_SYMBOL_PATH set properly in our installer.  But 
not wanting the installer to keep accreting our directory on the front/back 
every time we install.  And not destroying an environment variable that's a 
shared resource in the process, which is why I'm trying to form the right test 
in Wix to see if we're already in there.

In our case, we're a saas provider, installing our stuff across a farm of ~100 
of our servers.  We're not a re-seller or SDK vendor.  We're just trying to 
manage our farm.

Thanks
Mark


-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, February 10, 2011 8:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and "tricky" environment variables

I'm no expert wrt to symbols so treat this advice as an old drunk sailor 
sitting at the bar telling a story. :-)

I did a google search and a lot of people seem to not like _NT_SYMBOL_PATH. 
There seems to be some good things to be said about Symbol Server.   Can I 
assume that your installer is some sort of SDK? 

Re: [WiX-users] Wix and "tricky" environment variables

[Mark Modrall]

Well, you caught me flat footed with the App Path stuff, so I could be 
misunderstanding the Symbol Server stuff :)  But here's my understanding of 
what that's about:

1) Microsoft has a public service that will vend .pdb files for Microsoft 
components and you can set _NT_SYMBOL_PATH to pull from there
1a) You can set your _NT_SYMBOL_PATH to cache the results from Symbol Server 
locally if you want with a special syntax

2) If you're using a debugger and interactively watching something, you can use 
Symbol Server directly without _NT_SYMBOL_PATH

3) For your own symbols you're on your own.  Though I gather from your question 
(SDK vs internal process), there may be a way to register your symbols in the 
Microsoft Symbol Server.

I might be missing something, but it doesn't seem like you can get away from 
_NT_SYMBOL_PATH entirely.  At the least you have to register your symbols with 
Microsoft and set _NT_SYMBOL_PATH to point at the server.

Our use is for logging exception stack traces in a database, not hands-on 
interactive debugging.  The problem is that when you put things in the GAC it's 
considered bad form (and somewhat convoluted) to put the .pdbs in the GAC too.  
If the pdbs are lying right next to the .exes and .dbgs, you don't need to use 
_NT_SYMBOL_PATH because the default behavior checks the immediate environs 
before looking in the paths defined in _NT_SYMBOL_PATH.  Alas the GAC messes 
that up.  

We've always been dumping the .pdbs in our install directory but the stack 
traces that get logged blank out on anything that's gone through the GAC 
because the executables aren't located there.  Another frustrating thing about 
the gac is that even if you have a copy of the executable, say, in the /bin 
directory of your ASP.Net application it's going to use the GAC version instead 
and not infer anything about where your symbols might be from the one in your 
/bin directory.

So we're down to getting _NT_SYMBOL_PATH set properly in our installer.  But 
not wanting the installer to keep accreting our directory on the front/back 
every time we install.  And not destroying an environment variable that's a 
shared resource in the process, which is why I'm trying to form the right test 
in Wix to see if we're already in there.

In our case, we're a saas provider, installing our stuff across a farm of ~100 
of our servers.  We're not a re-seller or SDK vendor.  We're just trying to 
manage our farm.

Thanks
Mark


-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Thursday, February 10, 2011 8:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and "tricky" environment variables

I'm no expert wrt to symbols so treat this advice as an old drunk sailor 
sitting 
at the bar telling a story. :-)

I did a google search and a lot of people seem to not like _NT_SYMBOL_PATH.   
There seems to be some good things to be said about Symbol Server.   Can I 
assume that your installer is some sort of SDK?  Or are you perhaps automating 
an internal process?    Any advice given would depend on the answer to that 
question (e.g. does the end user want to contol his own destiny or is it a 
captive audience ).

However, I'm not going to go there anyways because I'm just an old drunk old 
sailor today.

(PS- No offense meant for any squids that might be out there.  Oorah  )

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



- Original Message 
From: Mark Modrall 
To: General discussion for Windows Installer XML toolset. 

Sent: Thu, February 10, 2011 7:39:08 AM
Subject: Re: [WiX-users] Wix and "tricky" environment variables

Hi Chris...

    Thanks for the tip on App Path; I didn't know about that one.

    Unfortunately, I used PATH as an example because I thought that's the one 
people would be most familiar with, but there are a number of environment 
variables that function similarly.  My own fault for not being more direct.

    What I'm actually trying to maintain is _NT_SYMBOL_PATH.  I'm trying to add 
the directory where my .pdbs live so that my GAC'ed components can still get 
symbol info in stack traces.

    _NT_SYMBOL_PATH works similarly to PATH in terms of syntax and function and 
Wix would act on them pretty much the same way.

Mark


-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Thursday, February 10, 2011 6:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and "tricky" environment variables

I'll be honest,  it's 2011 and I'm hard pressed to understand why software 
applications still cling to the need to be 

Re: [WiX-users] Wix and "tricky" environment variables

[Mark Modrall]

Hi Chris...

Thanks for the tip on App Path; I didn't know about that one.

Unfortunately, I used PATH as an example because I thought that's the 
one people would be most familiar with, but there are a number of environment 
variables that function similarly.  My own fault for not being more direct.

What I'm actually trying to maintain is _NT_SYMBOL_PATH.  I'm trying to 
add the directory where my .pdbs live so that my GAC'ed components can still 
get symbol info in stack traces.

_NT_SYMBOL_PATH works similarly to PATH in terms of syntax and function 
and Wix would act on them pretty much the same way.

Mark


-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
Sent: Thursday, February 10, 2011 6:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and "tricky" environment variables

I'll be honest,  it's 2011 and I'm hard pressed to understand why software 
applications still cling to the need to be in the "PATH"... a concept that 
originated some 30 years earlier.

Can you redesign your application to not need to be in the path?  Or, can you 
use AppPaths to make certain executables and 


http://www.sepago.de/d/helge/2010/08/26/how-the-app-paths-registry-key-makes-windows-both-faster-and-safer


Otherwise, I'd suggest that if the built in Env@Part First|Last  isn't working 
that you could change it to All and then use a custom action to do your own 
parsing ( dedupication, sorting, appending and so on. )  I'd test it really 
good 
though because I've never done this and I'm not sure what the gotchas would be.

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



- Original Message 
From: Mark Modrall 
To: General discussion for Windows Installer XML toolset. 

Sent: Wed, February 9, 2011 2:58:40 PM
Subject: [WiX-users] Wix and "tricky" environment variables

Hi...

                I'm looking to get my installer to appropriately set an entry 
in 
one of those "tricky" environment variables, like %PATH%.  By "tricky" I mean 
shared and accretive - it's a multi-value crossroads that everybody and their 
brother will be mucking with.  I want to make sure our addition gets in there 
but don't want to just keep appending our root every time the installer is 
run.  
In the same vein, I can't just blank the variable when our product is 
uninstalled.

                So I was thinking I'd add a custom action type 51 to get the 
value into a property and a conditionalized component with a test on the value, 
but I'm not quite clear on how all the pieces would fit together...  Something 
like





...



                Problem is that all the examples I'm cribbing from are using 
ellipsis too, so I'm not sure if I have to declare what phase the custom action 
will be executed in, etc.

                Am I on the right track?

Thanks
Mark

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Wix and "tricky" environment variables

[Mark Modrall]

Hi...

I'm looking to get my installer to appropriately set an entry 
in one of those "tricky" environment variables, like %PATH%.  By "tricky" I 
mean shared and accretive - it's a multi-value crossroads that everybody and 
their brother will be mucking with.  I want to make sure our addition gets in 
there but don't want to just keep appending our root every time the installer 
is run.  In the same vein, I can't just blank the variable when our product is 
uninstalled.

So I was thinking I'd add a custom action type 51 to get the 
value into a property and a conditionalized component with a test on the value, 
but I'm not quite clear on how all the pieces would fit together...  Something 
like





...



Problem is that all the examples I'm cribbing from are using 
ellipsis too, so I'm not sure if I have to declare what phase the custom action 
will be executed in, etc.

Am I on the right track?

Thanks
Mark

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Include question.

[Mark Modrall]

Thanks Blair...

Interestingly, Wix isn't complaining about  as a child of include... 
 As a test, I tweaked the little mini version of Tallow my predecessor left to 
take the  wrapper off the top level files, so it was
http://schemas.microsoft.com/wix/2003/01/wi";>
  
  
  
  

  
...

  


Going into 





And then Candle really did throw a nutter.  As you predicted,  was 
treated as a direct insertion, so  wasn't a legal child of , 
and that was the exception Candle threw.

So it seems that in Wix 2, it won't throw an error with  as 
a child of  but it won't include it either...

I may just have to upgrade as you say...

Probably long overdue...

Thanks
Mark


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, October 20, 2010 8:00 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Include question.

I took a quick glance in the XSD for WiX 2.0 and Component isn't allowed as
a child of Include. It is, however, allowed in WiX 3.0.

-----Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Wednesday, October 20, 2010 4:31 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Include question.

I did find another example in our old wix code in a different merge module.
It uses the same syntax as before for the include file(s) but there's a
slight twist:


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







  


The first  file has only subdirectories in it.  The 2nd one, like
my original problem has root files and subdirs - but wrapping it in an
explicit subdirectory seems to avoid the problem.

So it looks like it's only a problem to include




Directly under


I did make sure that the msi wix file did actually have a 
and  for the modules being produced...

Thanks
Mark


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Tuesday, October 19, 2010 1:21 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Include question.

That suggestion doesn't make sense to me.  doesn't incorporate
the included file as a different fragment, it "imports" the file at the
location of the processing instruction in building the DOM actually
presented to the compiler proper, making it lay in the same fragment.

Also, merge modules don't include features, so there's no Feature under
which to place the ComponentRef. And, in when building MSIs instead of MSMs,
if you miss the ComponentRef under some Feature, your component is still
included  in the MSI (assuming the fragment the component is in was
otherwise included by the linker) but you get an error indicating that the
component won't be installed because it isn't included in any components.

It may possibly be a bug. If you migrate your solution to WiX 3.whatever,
does it still happen? I don't know if 2.0 would be fixed or not for
something like this since 3.0 has been RTM for quite some time now.

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Monday, October 18, 2010 6:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Include question.

Thanks for the reply...

I'm not adding any ComponentRef, so that's probably it.  Just out of
curiosity, adding a  under a  is automatically
included but file references (bundled under a ) won't?

Thanks
Mark


-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Friday, October 15, 2010 7:52 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Include question.


Are you adding a ComponentRef for ASPcomponent0 under a feature? If not it
will not be included in the MSI.
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-questi
on-tp5631284p5638617.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of ri

Re: [WiX-users] Include question.

[Mark Modrall]

I did find another example in our old wix code in a different merge module.  It 
uses the same syntax as before for the include file(s) but there's a slight 
twist:


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







  


The first  file has only subdirectories in it.  The 2nd one, like my 
original problem has root files and subdirs - but wrapping it in an explicit 
subdirectory seems to avoid the problem.

So it looks like it's only a problem to include




Directly under


I did make sure that the msi wix file did actually have a  and 
 for the modules being produced...

Thanks
Mark


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Tuesday, October 19, 2010 1:21 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Include question.

That suggestion doesn't make sense to me.  doesn't incorporate
the included file as a different fragment, it "imports" the file at the
location of the processing instruction in building the DOM actually
presented to the compiler proper, making it lay in the same fragment.

Also, merge modules don't include features, so there's no Feature under
which to place the ComponentRef. And, in when building MSIs instead of MSMs,
if you miss the ComponentRef under some Feature, your component is still
included  in the MSI (assuming the fragment the component is in was
otherwise included by the linker) but you get an error indicating that the
component won't be installed because it isn't included in any components.

It may possibly be a bug. If you migrate your solution to WiX 3.whatever,
does it still happen? I don't know if 2.0 would be fixed or not for
something like this since 3.0 has been RTM for quite some time now.

-Original Message-
From: Mark Modrall [mailto:mmodr...@mzinga.com] 
Sent: Monday, October 18, 2010 6:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Include question.

Thanks for the reply...

I'm not adding any ComponentRef, so that's probably it.  Just out of
curiosity, adding a  under a  is automatically
included but file references (bundled under a ) won't?

Thanks
Mark


-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Friday, October 15, 2010 7:52 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Include question.


Are you adding a ComponentRef for ASPcomponent0 under a feature? If not it
will not be included in the MSI.
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-questi
on-tp5631284p5638617.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Include question.

[Mark Modrall]

Thanks for the reply...

I'm not adding any ComponentRef, so that's probably it.  Just out of curiosity, 
adding a  under a  is automatically included but file 
references (bundled under a ) won't?

Thanks
Mark


-Original Message-
From: jhennessey [mailto:jack.hennes...@hyland.com] 
Sent: Friday, October 15, 2010 7:52 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Include question.


Are you adding a ComponentRef for ASPcomponent0 under a feature? If not it
will not be included in the MSI.
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-question-tp5631284p5638617.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Include question.

[Mark Modrall]

Just stumbled across an odd artifact left behind by my predecessor's use of 
Wix.  He built a system that generates a wix include file by crawling various 
directories.  He also built his own version of Tallow because he rather liked 
negative filters than positive ones I gather (i.e. his command line options 
were -xf and -xd for patterns to exclude).

It looks like this:

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




  
  

...
  
  
...

  
...


It's included into the Wix project like this:

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




  


The odd artifact mentioned above is that the files specified in 
the first naked  don't get included in the install, and I'm 
wondering why?   The included form would resolve to something like

 

 
 
 




Why wouldn't Web.config, etc get installed as a result?  There 
are no errors in the msi build...

Thanks
Mark

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] running ngen from an msi?

[Mark Modrall]

 I know there's a chicken/egg issue with running anything to work on the files 
you're installing during the installation process, but I  was wondering what 
people usually do around ngen?   I mean you install a bunch of .net assemblies 
and I know the way to deal with GACing them is to essentially set your wix file 
to install directly in the gac rather than use  gacutil.

 If you have a bunch of msil assemblies and you want them to "go native" on 
whatever machine you install them to, you have to use ngen  on that machine.

 Do you schedule it to run after next reboot or something?

Thanks
Mark


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Newbie x64 msi question

[Mark Modrall]

Hi...

I've got some old wix scripts installing msil .net assemblies 
in the gac and adding registry entries for com interop.  These things will work 
x64 as is, so I tried the installer without making any particular changes to 
the old scripts.

What I found, though, was that

...


...

All the class id registry settings ended up in the \Wow6432Node\ subtree while 
all the class names ended up in the top HKCR root.

What do I need to set in the wix script to tell it to put the 
entries in the 64-bit hive?  I mean, theoretically I could make all the entries 
in both since the msil code could run in either circumstance...

Thanks
Mark

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ServiceInstall/ServiceDependency

[Mark Modrall]

Hi...

I've been slapping together an installer for a window service, 
and I added
  


To the .wxs file.  When I ran the resulting msi on my dev box, the service was 
installed but not all the dependencies applied.  Specifically, I have 
SqlExpress on my dev box, but not the full Sql Server.  When I looked at the 
properties of the installed service, it had the MSMQ dependency, but the Sql 
Server one was simply dropped.

So

a)  Is there any way to get it to put the dependency in even when the 
dependency isn't there? (i.e. it won't run until the other dependency is 
installed) or

b)  Is there any way to make the msi conditional (i.e. either Sql Server 
*or* SqlExpress are there)?

Thanks
Mark


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows 7 x64: Windows application x64 is looking for MSVCR71.dll

[Mark Modrall]

We recently ran into something very similar...  We build our .net assemblies 
MSIL, but a 3rd party assembly (dtSearch) was built platform-specific because 
it had a dependency on an unmanaged dll.

We didn't find any MSVCR71 for x64, but the vendor did supply an x64 build of 
their code (both .net and unmanaged).  Their unmanaged dll didn't depend on 
msvcr71 (though I forget which rev the x64 build was on).

Same thing with the Oracle drivers (and the .Net wrapper).

Thanks
Mark


-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com] 
Sent: Tuesday, April 27, 2010 3:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Windows 7 x64: Windows application x64 is looking for 
MSVCR71.dll

Forget the build, the issue is the binary that needs msvcr71.dll. As far as I 
know, there is no native x64 version of the Microsoft VS 2003 C++ runtime 
support library msvcr71.dll. If someone has built a native x64 binary that 
requires a native x64 msvcr71.dll then I have no idea what you can do. Because 
this seems to be a situation that a reasonable person would not get into, I'm 
suggesting that you verify that it really is a native x64 binary, because 
people can get very loose in their descriptions, and it's still extremely 
common to run x86 code on 64-bit systems. 

Phil Wilson 

-Original Message-
From: jeff00seattle [mailto:jeff_tan...@earthlink.net] 
Sent: Tuesday, April 27, 2010 11:53 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows 7 x64: Windows application x64 is looking for 
MSVCR71.dll


Thanks for the reply,

I do not have control of the build; in other words, I am provided with an
x64 build and I do not have the sources. This x64 binary is from the open
source community.

Thereby I must merge msvcr71.dll with install upon a Windows 7 x64, or a
getting "missing" error dialog at runtime.

-
Thanks
Jeff in Seattle
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-7-x64-Windows-application-x64-is-looking-for-MSVCR71-dll-tp4970053p4970279.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at Portland House, Bressenden Place, London, 
SW1E 5BF (Registered number 166023). For a list of European legal entities 
within the Invensys Group, please go to 
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77. 
You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail 
inet.hqhelpd...@invensys.com. This e-mail!
  and any attachments thereto may be subject to the terms of any agreements 
between Invensys (and/or its subsidiaries and affiliates) and the recipient 
(and/or its subsidiaries and affiliates).



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] A couple of Wix 2.0 questions

[Mark Modrall]

Another thing I just noticed...  In Wix 2.0,  doesn't seem to work 
on env variables...

I have things like






When I ran the Wix project when $(env.TheBuildFolder) was defined, it still 
went to the else...

Is there a way to really test for env variable definitions?

Thanks
Mark

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Tuesday, April 20, 2010 1:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] A couple of Wix 2.0 questions

0. Nothing wrong with WiX v2.0. Now InstallUtil, that's a big problem.


1. Assemblies are not committed to the GAC until InstallFinalize. Thus, you
cannot depend on them during your install.

2. Nothing built into the Preprocessor about MSBuild or VS. You need to push
the values down from VS or MSBuild into candle.exe. My MSBuild-fu isn't that
strong so others may be of more use yere.

On Tue, Apr 20, 2010 at 9:56 AM, Mark Modrall  wrote:

> I know I know...  I shouldn't even be using it...  But I inherited this old
> hairball when I got here and no one has wanted to spend the time to upgrade.
>
> I tried to make a quick new installer using our already-written merge
> modules but I ran into a couple of odd quirks...
>
>
> 1)  One merge module installs a few .net assemblies in the GAC.  The
> last, custom step of the new installer is to run InstallUtil.exe on an
> assembly *using* one of the gac components.  But InstallUtil fails because
> trying to run up the assembly - bind failures, saying the gac components
> aren't there.  I've tried a number of things  (declaring InstallFiles
> explicitly, trying to explicitly set the sequence numbers, moving all the
> actions to AdminExecuteSequence) and nothing has worked.  Oddly, moving
> everything to AdminExecuteSequence ran to completion just fine - it just
> didn't execute the  custom actions.  Anyone out there contended with this?
>  Trying to put some pieces in the gac with the installer yet still have them
> available to run InstallUtil.exe on something consuming them?
>
> 2)  In my wxs, I tried to default the platform to the setting from the
> VS Configuration Manager, but none of the methods I found with Google
> appeared to work.  None of the supposed pre-defined variables existed, and I
> couldn't put a  group in a 2.0 wix project.  Are there any
> preprocessor variables in 2.0 that will tell you what configuration you're
> running in?
>
> Thanks
> mark
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] A couple of Wix 2.0 questions

[Mark Modrall]

I noticed that it's legal to have  and  as a 
child of any of the sequences...  Can you put InstallFiles and InstallFinalize 
in one sequence (say the AdminExecuteSequence) and run InstallUtil from 
another?  And which order do the Sequences get run in?

Thanks
Mark


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Tuesday, April 20, 2010 1:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] A couple of Wix 2.0 questions

0. Nothing wrong with WiX v2.0. Now InstallUtil, that's a big problem.


1. Assemblies are not committed to the GAC until InstallFinalize. Thus, you
cannot depend on them during your install.

2. Nothing built into the Preprocessor about MSBuild or VS. You need to push
the values down from VS or MSBuild into candle.exe. My MSBuild-fu isn't that
strong so others may be of more use yere.

On Tue, Apr 20, 2010 at 9:56 AM, Mark Modrall  wrote:

> I know I know...  I shouldn't even be using it...  But I inherited this old
> hairball when I got here and no one has wanted to spend the time to upgrade.
>
> I tried to make a quick new installer using our already-written merge
> modules but I ran into a couple of odd quirks...
>
>
> 1)  One merge module installs a few .net assemblies in the GAC.  The
> last, custom step of the new installer is to run InstallUtil.exe on an
> assembly *using* one of the gac components.  But InstallUtil fails because
> trying to run up the assembly - bind failures, saying the gac components
> aren't there.  I've tried a number of things  (declaring InstallFiles
> explicitly, trying to explicitly set the sequence numbers, moving all the
> actions to AdminExecuteSequence) and nothing has worked.  Oddly, moving
> everything to AdminExecuteSequence ran to completion just fine - it just
> didn't execute the  custom actions.  Anyone out there contended with this?
>  Trying to put some pieces in the gac with the installer yet still have them
> available to run InstallUtil.exe on something consuming them?
>
> 2)  In my wxs, I tried to default the platform to the setting from the
> VS Configuration Manager, but none of the methods I found with Google
> appeared to work.  None of the supposed pre-defined variables existed, and I
> couldn't put a  group in a 2.0 wix project.  Are there any
> preprocessor variables in 2.0 that will tell you what configuration you're
> running in?
>
> Thanks
> mark
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] A couple of Wix 2.0 questions

[Mark Modrall]

I know I know...  I shouldn't even be using it...  But I inherited this old 
hairball when I got here and no one has wanted to spend the time to upgrade.

I tried to make a quick new installer using our already-written merge modules 
but I ran into a couple of odd quirks...


1)  One merge module installs a few .net assemblies in the GAC.  The last, 
custom step of the new installer is to run InstallUtil.exe on an assembly 
*using* one of the gac components.  But InstallUtil fails because trying to run 
up the assembly - bind failures, saying the gac components aren't there.  I've 
tried a number of things  (declaring InstallFiles explicitly, trying to 
explicitly set the sequence numbers, moving all the actions to 
AdminExecuteSequence) and nothing has worked.  Oddly, moving everything to 
AdminExecuteSequence ran to completion just fine - it just didn't execute the  
custom actions.  Anyone out there contended with this?  Trying to put some 
pieces in the gac with the installer yet still have them available to run 
InstallUtil.exe on something consuming them?

2)  In my wxs, I tried to default the platform to the setting from the VS 
Configuration Manager, but none of the methods I found with Google appeared to 
work.  None of the supposed pre-defined variables existed, and I couldn't put a 
 group in a 2.0 wix project.  Are there any preprocessor 
variables in 2.0 that will tell you what configuration you're running in?

Thanks
mark

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problems with XmlConfig

[Mark Modrall]

But msxml can be told to preserve whitespace when parsing...  In all likelihood 
Wix isn't doing that, but it is conceivably possible...

Mark


-Original Message-
From: Michael Owings [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 14, 2008 4:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Problems with XmlConfig

If you're trying to format the xml itself, you may be out of luck -- msxml 
(which I believe wix is using) will do the formatting however it feels like 
doing it. This is true of most programmatic xml access.

If the text in question is in a CDATA section, however, I'd think that should 
work, assuming #xA is really the right escape.

Pierson Lee (PIE) wrote:
> I was attempting to insert #xA; into my web configs to specify a
> carriage return for some lines of text I'm adding into the config, but
> it seems like during the process, those characters are getting
> stripped. Anyone have any idea how to do this? Thanks :)
>
> --
> --- This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK &
> win great prizes Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>


--
Teleoperate a roving mobile robot from the web:
http://www.swampgas.com/robotics/rover.html

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] preprocessor and environment variables?

[Mark Modrall]

Sorry, I should have included that in the first place... V2.0.5325.0...

Thanks
Mark

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 6:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] preprocessor and environment variables?

What version of the WiX toolset are you using?

-Original Message-
From: Mark Modrall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 14:38
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] preprocessor and environment variables?

Hi...

I recently ran into a number of problems trying to change wix project 
behavior based on environment variable settings.  A number of the things that 
sounded intuitive to me didn't work.

For example





didn't work because ifdef returns false for all environment variables always 
whether they are set or not.





works as long as $(env.A) is defined, but if it's not, Candle generates an 
exception.

Is there any way to test for environment variable existence before you try 
to use it in Wix?

Thanks
Mark

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] testing for environment variable definition in Wix

[Mark Modrall]

Hi...

I recently ran into a number of problems trying to change wix project 
behavior based on environment variable settings.  A number of the things that 
sounded intuitive to me didn't work.

For example





didn't work because ifdef returns false for all environment variables always 
whether they are set or not.





works as long as $(env.A) is defined, but if it's not, Candle generates an 
exception.

Is there any way to test for environment variable existence before you try 
to use it in Wix?

Thanks
Mark

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] preprocessor and environment variables?

[Mark Modrall]

Sorry...  Should have included that to begin with - v2.0.5325.0

Thanks
Mark

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 6:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] preprocessor and environment variables?

What version of the WiX toolset are you using?

-Original Message-
From: Mark Modrall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 14:38
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] preprocessor and environment variables?

Hi...

I recently ran into a number of problems trying to change wix project 
behavior based on environment variable settings.  A number of the things that 
sounded intuitive to me didn't work.

For example





didn't work because ifdef returns false for all environment variables always 
whether they are set or not.





works as long as $(env.A) is defined, but if it's not, Candle generates an 
exception.

Is there any way to test for environment variable existence before you try 
to use it in Wix?

Thanks
Mark

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge 
Build the coolest Linux based applications with Moblin SDK & win great prizes 
Grand prize is a trip for two to an Open Source event anywhere in the world 
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] preprocessor and environment variables?

[Mark Modrall]

Hi...

I recently ran into a number of problems trying to change wix project 
behavior based on environment variable settings.  A number of the things that 
sounded intuitive to me didn't work.

For example





didn't work because ifdef returns false for all environment variables always 
whether they are set or not.





works as long as $(env.A) is defined, but if it's not, Candle generates an 
exception.

Is there any way to test for environment variable existence before you try 
to use it in Wix?

Thanks
Mark

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users