Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Thomas S. Trias]

Perhaps it depends upon the version of the code?  I am developing on top 
of 3.0.4923.0.  I wouldn't be so adamant, except that I have just 
recently been working with the IIS code, and that is the EXACT behavior 
I was looking for for the installations and upgrades of our sites, and I 
haven't made any such modification.

Looking back through the local SubVersion repository that I use for my 
local changes (and to track the changes from each time I upgrade from 
the CVS repository), I see that the functionality was added somewhere 
between 3.0.4624.0 and 3.0.4923.  This is also where "*" was added as a 
valid choice for SiteId.

Traipsing through CVS, (rev 1.65 is 3.0.4624.0 for wixver.h; is there a 
tag structure in the CVS repository to find files by WiX version?  It's 
been so long since I've had to maintain a CVS repository), I tracked 
down the change in rev 1.17 of scaweb.cpp.  Judging by the dates, this 
corresponds to 3.0.4805.  As I said, I can only really give advice 
regarding the version I'm using.  I do, however, make sure that the 
behavior is within the official WiX code-base and not part of my 
modifications (at least until I'm done with the current deployment and 
have time to clean up the code and submit it for inclusion).

Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/


 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate 
presence of existing website using just the Name -> Description 
attribute value versus port settings?
From: Neil Sleightholm 
To: tomtr...@artizan.com, General discussion for Windows Installer XML 
toolset. 
Date: 4/9/2009 4:41 PM
> I will have to test this because looking at the code I can't see how.
> Also, the other poster has suggested that referencing "Default Web Site"
> with SiteId="*" didn't work.
>
> Neil
>
> -Original Message-
> From: Thomas S. Trias [mailto:tomtr...@artizan.com] 
> Sent: 09 April 2009 22:25
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate
> presence of existing website using just the Name -> Description
> attribute value versus port settings?
>
> Hopefully my earlier response will post shortly; this is absolutely
> correct for adding new sites, but does not take into account the fact
> that SiteId = "*" does, in fact, trigger a search for the existing site
> by description.
>
> Thanks,
>
> Thomas S. Trias
> Senior Developer
> Artizan Internet Services
> http://www.artizan.com/
>
>
> P.S.  Sorry for not trimming down the previous emails; since my mail
> client turns nested replies into a tree with all but the topmost node
> collapsed, I tend to forget to trim them down.
>
>
>
>   


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Neil Sleightholm]

I will have to test this because looking at the code I can't see how.
Also, the other poster has suggested that referencing "Default Web Site"
with SiteId="*" didn't work.

Neil

-Original Message-
From: Thomas S. Trias [mailto:tomtr...@artizan.com] 
Sent: 09 April 2009 22:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate
presence of existing website using just the Name -> Description
attribute value versus port settings?

Hopefully my earlier response will post shortly; this is absolutely
correct for adding new sites, but does not take into account the fact
that SiteId = "*" does, in fact, trigger a search for the existing site
by description.

Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/


P.S.  Sorry for not trimming down the previous emails; since my mail
client turns nested replies into a tree with all but the topmost node
collapsed, I tend to forget to trim them down.

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Thomas S. Trias]

Hopefully my earlier response will post shortly; this is absolutely
correct for adding new sites, but does not take into account the fact
that SiteId = "*" does, in fact, trigger a search for the existing site
by description.

Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/


P.S.  Sorry for not trimming down the previous emails; since my mail
client turns nested replies into a tree with all but the topmost node
collapsed, I tend to forget to trim them down.

 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate
presence of existing website using just the Name ->Description
attribute value versus port settings?
From: Neil Sleightholm 
To: General discussion for Windows Installer XML toolset.

Date: 4/9/2009 3:56 PM
> That is correct. Although I would add that is it possible (although fairly 
> unlikely) on different machines to get different site ids for the same site 
> name if the "add 1" part of the iis algorithm kicked in. Also, if you deleted 
> "Default Web Site" and recreated it it wouldn't be site id 1 unless you 
> created it as such.
>
> (Don't blame WiX for this, it is the bizarre way iis works.)
>
> Neil
>
> -Original Message-
> From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
> Sent: 09 April 2009 18:26
> To: General discussion for Windows Installer XML toolset.
> Cc: Dmitry Frenkel
> Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
> of existing website using just the Name -> Description attribute value versus 
> port settings?
>
> So it sounds like you are saying the following would not in fact work because 
> the hashing of the Description attribute value would not come out to 1.
> 
> 
> 
>
> Therefore the caveat your are trying to clarify is that for sites where you 
> know the siteid was not produced using the iis6 published hash algorithm of 
> the site name in those cases you'd need to be explicit with the SiteId value 
> for the search for the existing web site (not involving use of iis:WebAddress 
> settings) to get you the desired result, e.g. specifically in case of Default 
> Web Site we had better use SiteId=" and not SiteId="*".
> 
> 
> 
>
>
> -Original Message-
> From: Neil Sleightholm [mailto:n...@x2systems.com]
> Sent: Thursday, April 09, 2009 10:13 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
> of existing website using just the Name -> Description attribute value versus 
> port settings?
>
> I mentioned this because it may catch you out and SiteId=" would fail. For 
> example, if you created a site that set the site id to a fixed value, 
> something that is perfectly valid to do (adsutil.vbs does this), the hash 
> matching wouldn't would. You have found this I believe when trying to find 
> the "Default Web Site" and find its site id is 1. This also explains why the 
> name is case sensitive, the hash algorithm generates a different site id 
> depending on the case. By setting SiteId="*" you are not searching for a name 
> you are searching for the site id based on the hash of the name. Looking at 
> the code in scaweb.cpp function ScaWebFindBase() I think site id takes 
> precedence over name, so you could set the name to anything but as long as 
> the site id is set correctly it will find the site.
>
> I hope this helps.
>
> Neil
>
> -Original Message-
> From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
> Sent: 09 April 2009 17:50
> To: 'General discussion for Windows Installer XML toolset.'; 
> 'tomtr...@artizan.com'; Neil Sleightholm
> Cc: Dmitry Frenkel; Kiran Challa
> Subject: RE: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
> of existing website using just the Name -> Description attribute value versus 
> port settings?
>
> In our case we are not so concerned about what SiteId=" will result in wrt 
> the actual SiteId value that gets generated and used when the msi determines 
> its necessary to create the iis:WebSite.
>
> What we are really interested in is the fact that including the SiteId=" 
> attribute, based on discussions in this thread and our test results over the 
> course of the past day, results in the iis extension searching the host for 
> whether or not the web site already exists using a case sensitive name that 
> matches the Description attribute value specified.
>
> This is important behavior to us because w/o SiteId=" attribute value in 
> place what we found is that the iis extension would search the host for 
> whether or not the web site already exists using the iis:WebAddress settings 
> and this was undersirable because this is something that is not always 
> predictable ad design time for all environments.  Example being cases where 
> ops creates/configures the web site in advance of the msi having every been 
> run.   Or w

Re: [WiX-users] Calling a external setup package

[Bob Arnson]

Madden, William wrote:
> "A custom action can't run another installer."
>
> This is only partially true, a custom action can run another installer if run 
> from the UI sequence not the Execute sequence, only one install at a time can 
> be within a execute sequence.
>   

True. But not supporting silent/passive installs is a non-starter.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] binary dependencies in binary stream

[Leo ...]

Hi all,

 

How could I include two binaries where one references the other in the binary 
stream for use as custom actions?

 

For example:

file binary1.exe references dll binary2.dll when it gets executed.

 

Will including both of these binaries in the binary streams as follows work?  
Or is there something else I need to do?

 



 



 

Thanks,

---Leo

 
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Quiet Execution of built-in Custom Actions

[Bob Arnson]

Vuchuru, Surekha (SBT US EXT) wrote:
> I have noticed that few installations go smoothly without any such
> flashy windows...It would be of a great help to know if there is any
> indirect way atleast to control those command or batch files
> execution(while a Standard Action executes)...
>   

WriteRegistryValues will never cause console windows to open.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Neil Sleightholm]

That is correct. Although I would add that is it possible (although fairly 
unlikely) on different machines to get different site ids for the same site 
name if the "add 1" part of the iis algorithm kicked in. Also, if you deleted 
"Default Web Site" and recreated it it wouldn't be site id 1 unless you created 
it as such.

(Don't blame WiX for this, it is the bizarre way iis works.)

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
Sent: 09 April 2009 18:26
To: General discussion for Windows Installer XML toolset.
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

So it sounds like you are saying the following would not in fact work because 
the hashing of the Description attribute value would not come out to 1.




Therefore the caveat your are trying to clarify is that for sites where you 
know the siteid was not produced using the iis6 published hash algorithm of the 
site name in those cases you'd need to be explicit with the SiteId value for 
the search for the existing web site (not involving use of iis:WebAddress 
settings) to get you the desired result, e.g. specifically in case of Default 
Web Site we had better use SiteId="1" and not SiteId="*".





-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 10:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I mentioned this because it may catch you out and SiteId="*" would fail. For 
example, if you created a site that set the site id to a fixed value, something 
that is perfectly valid to do (adsutil.vbs does this), the hash matching 
wouldn't would. You have found this I believe when trying to find the "Default 
Web Site" and find its site id is 1. This also explains why the name is case 
sensitive, the hash algorithm generates a different site id depending on the 
case. By setting SiteId="*" you are not searching for a name you are searching 
for the site id based on the hash of the name. Looking at the code in 
scaweb.cpp function ScaWebFindBase() I think site id takes precedence over 
name, so you could set the name to anything but as long as the site id is set 
correctly it will find the site.

I hope this helps.

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 17:50
To: 'General discussion for Windows Installer XML toolset.'; 
'tomtr...@artizan.com'; Neil Sleightholm
Cc: Dmitry Frenkel; Kiran Challa
Subject: RE: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

In our case we are not so concerned about what SiteId="*" will result in wrt 
the actual SiteId value that gets generated and used when the msi determines 
its necessary to create the iis:WebSite.

What we are really interested in is the fact that including the SiteId="*" 
attribute, based on discussions in this thread and our test results over the 
course of the past day, results in the iis extension searching the host for 
whether or not the web site already exists using a case sensitive name that 
matches the Description attribute value specified.

This is important behavior to us because w/o SiteId="*" attribute value in 
place what we found is that the iis extension would search the host for whether 
or not the web site already exists using the iis:WebAddress settings and this 
was undersirable because this is something that is not always predictable ad 
design time for all environments.  Example being cases where ops 
creates/configures the web site in advance of the msi having every been run.   
Or we have cases where ops configures the web site left behind after an 
uninstall where iis:WebSite associated component has Permanent="yes" and then 
on next install we want to be able to find that site by name because the port 
settings lookup won't produce an accurate result.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 9:21 AM
To: General discussion for Windows Installer XML toolset.; tomtr...@artizan.com
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I think this thread may be misunderstanding what SiteId="*" means. I means use 
the IIS6 default of setting the site id to the hash of the name, I don't 
believe it is triggering a search of the description. A site id of 1 is the 
default of the "Default Web Site" created when IIS is installed. The hashin

Re: [WiX-users] Quiet Execution of built-in Custom Actions

[Vuchuru, Surekha (SBT US EXT)]

Thank you for your reply...So, It is a Standard Action...Thank you for
correcting that...

I have noticed that few installations go smoothly without any such
flashy windows...It would be of a great help to know if there is any
indirect way atleast to control those command or batch files
execution(while a Standard Action executes)...

Thanks and Regards,
Surekha Vuchuru



-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Wednesday, April 08, 2009 11:09 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Quiet Execution of built-in Custom Actions

WriteRegistryValues isn't a Custom Action
http://msdn.microsoft.com/en-us/library/aa372891(VS.85).aspx 

The answer in that case would be no, if indeed WriteRegistryValues does
open command prompts (which I'd be very surprised if it does).

Palbinder Sandher 
Software Deployment & IT Administrator
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: Vuchuru, Surekha (SBT US EXT)
[mailto:surekha.vuchuru@siemens.com] 
Sent: 08 April 2009 16:09
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Quiet Execution of built-in Custom Actions

Hello All,
 
I have a CA that executes a batch file silently using CAQuietExec. I
managed to get rid of many such flashing windows that occur due to the
execution of batch files during installation process.
But, there are few built-in CustomActions like WriteRegistryValues that
opens few batch / command windows automatically. Please let me know if
there is a way to avoid those flashy windows when built-in Custom Action
get executed...
 
Thanks and Regards,
Surekha Vuchuru

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix and Crystal Reports

[Don Benson]

On Thu, Apr 9, 2009 at 12:54 PM, MacDiarmid, James D <
james.macdiar...@eds.com> wrote:

>
> Where would I normally find a merge module like this, or is this
> something I would need to create myself?


http://tinyurl.com/cmbtql

- Don Benson -
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSI language problem

[Heath Stewart]

If you installed the German transform initially with the product as a secure
transform, it is cached with the product and always used by default. You'll
have to uninstall the product and reinstall without the transform.

PatchPackage is a table that patches use. Patches (MSPs) contain transforms,
so when MSI is applying transforms part of the code path assumes it might
be a patch and, so, checks for patch tables. It's not a problem here - just
an informational message.

On Wed, Apr 8, 2009 at 2:53 AM, Andy2k8  wrote:

>
> I have checked that and its correct.
>
> Here are the debug log snippet:
>
> MSI (c) (7C:0C) [15:08:32:611]: Looking for storage transform: DE_de.mst
> MSI (c) (7C:0C) [15:08:32:611]: Validating transform 'DE_de.mst' with
> validation bits 0
> MSI (c) (7C:0C) [15:08:32:611]: Transform 'DE_de.mst' is valid.
> MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2205 2:  3: Patch
> MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2205 2:  3: PatchPackage
> MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: _Tables 3: -2147287038
> MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: _Columns 3: -2147287038
> MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: Media 3: -2147287038
> MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: File 3: -2147287038
> MSI (c) (7C:0C) [15:08:32:611]: TRANSFORM: 'PatchPackage' table is missing
> or empty.  No pre-transform fixup necessary.
> MSI (c) (7C:0C) [15:08:32:611]: TRANSFORM: Applying regular transform to
> database.
>
>
> It looks like the MSI applies the german transform during the runtime even
> when i do not try to apply using the TRANSFORMS public property during the
> MSI runtime.What does "PatchPackage" has got to do with the transforms??
>
> I have also tried applying an english transform to the same MSI.Even then i
> see that the MSI is getting launched in German..Somebody is overwriting the
> TRANSFORMS property..
>
> from the debug logs::
>
> MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding
> RestrictedUserControl property. Its value is '1'.
> MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Modifying TRANSFORMS
> property. Its current value is ':DE_de.mst'. Its new value: 'EN_en.mst'.
> MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding CURRENTDIRECTORY
> property. Its value is 'D:\'.
> MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding CLIENTUILEVEL
> property. Its value is '0'.
> MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding CLIENTPROCESSID
> property. Its value is '1916'.
> MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Modifying TRANSFORMS
> property. Its current value is 'EN_en.mst'. Its new value: ':DE_de.mst'.
> MSI (c) (7C:0C) [15:08:32:627]: TRANSFORMS property is now: :DE_de.mst
> MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding PRODUCTLANGUAGE
> property. Its value is '1033'.
>
> Any idea why is the german transforms always getting dominated here theough
> i try to apply the english transform???
>
>
>
>
> Check your Product/@Language and Package/@Language (if specified).
>
> Andy2k8 wrote:
> > I see that the default UI language of the MSI got changed from English to
> German after I have fiddled with the German transforms.Now whenever I run
> any of my application MSI which is not embedded with any language
> transforms, it gets launched in the German language.The system locale is set
> to English - United States.
> >
> > What is going wrong here?? How do I get the MSIs run in the default
> English language?
> >
> > -
> > Andy
> > MSI Developer
> > Schneider Electric:working:
> > --
> > View this message in context:
> http://n2.nabble.com/MSI-language-problem-tp2591550p2591550.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
> >
>
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> -
> Andy
> MSI Developer
> Schneider Electric:working:
> --
> View this message in context:
> http://n2.nabble.com/MSI-language-problem-tp2591550p2604263.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
>
> --
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
>  ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
-

Re: [WiX-users] Multiple instance installations and patches

[Heath Stewart]

/p and some APIs care about the target ProductCodes and will actually
modified the resulting PATCH property if a ProductCode is not targetted. You
should use the TargetProductCodes element in that case. I have a blog post
coming about that (hopefully) soon at http://blogs.msdn.com.

On Wed, Apr 8, 2009 at 12:47 AM, Yan Sklyarenko  wrote:

> Thanks a lot for the hint, Heath!
> That's fantastic I can achieve the same without "shaman dancing"
> dismembering msp file!
> WiX rules!! :)
>
> One small question: is there any reason why this command format works:
>   msiexec /i {42A33A91-36B0-4700-A6F5-1289D22F358C}
> PATCH=*path\to\patch.msp*
>
> but this doesn't (throwing that "The upgrade patch cannot be installed
> ..." error):
>   msiexec /p *path\to\patch.msp* /n
> {42A33A91-36B0-4700-A6F5-1289D22F358C}
>
> ?
> This is reproduced without "TargetProductCode" elements.
>
> -- Yan
>
> -Original Message-
> From: Heath Stewart [mailto:clubs...@gmail.com]
> Sent: Friday, April 03, 2009 9:46 AM
> To: General discussion for Windows Installer XML toolset.
>  Subject: Re: [WiX-users] Multiple instance installations and patches
>
> Actually, WiX supports this already without having to execute code.
> Under
> your PatchBaseline element add the Validation element and set
> ProductCode="no". The "double-click" scenario for the resulting MSP will
> only apply to the default instance (the instance you created the patch
> from)
> but it will apply explicitly to any instance even if the ProductCode is
> the
> same (assuming your instance transforms aren't changing the
> ProductVersion,
> ProductLanguage, or UpgradeCode). So they'd apply like so:
>
> msiexec /i {42A33A91-36B0-4700-A6F5-1289D22F358C}
> PATCH=*path\to\patch.msp*
>
> If you want to enable the double-click scenario while only building the
> patch against the default instance (which makes sense - it's all the
> same
> differences and files) use the new TargetProductCodes element added to
> WiX
> 3.0.5106.0. Under your Patch element, add;
>
> 
>  
>  
> 
>
> Now when the MSP is double-clicked it will apply to any and all
> instances
> installed.
>
>
> On Tue, Dec 30, 2008 at 4:48 AM, Yan Sklyarenko  wrote:
>
> > Hello,
> >
> > Well, I managed to overcome this myself. For those who interested in
> > details, please visit my blog:
> >
> http://ysdevlog.blogspot.com/2008/12/multiple-instance-installations-and
> >
> .html ns-and%0A.html>
>  >
> > I would appreciate any comments.
> >
> > -- Yan
> >
> > -Original Message-
> > From: Yan Sklyarenko [mailto:y...@sitecore.net]
> > Sent: Wednesday, December 24, 2008 4:44 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] Multiple instance installations and patches
> >
> > Hello WiX community,
> >
> >
> >
> > I'm just stuck with this scenario and I'd appreciate any hint.
> >
> > I have a product which supports multiple instance installations with
> the
> > help of instance transforms. In order to make the components data
> > isolated, it is installed to different folders (like best practice
> guide
> > suggests), and also I apply another transform to change component
> GUIDs
> > for each instance. Hence, in order to install instance 1 I use the
> > following command line:
> >
> >   Msiexec /i MyPackage.msi MSINEWINSTANCE=1
> > TRANSFORMS=:InstanceId1;:ComponentGUIDTransform1.mst
> INSTALLLOCATION=...
> >
> > And for instance 2:
> >
> >   Msiexec /i MyPackage.msi MSINEWINSTANCE=1
> > TRANSFORMS=:InstanceId2;:ComponentGUIDTransform2.mst
> INSTALLLOCATION=...
> >
> > Etc.
> >
> >
> >
> > This works perfectly.
> >
> > Now I'd like to build a patch which then can be applied to any of the
> > instance. I use the "pure-WiX" way of building the .msp:
> >
> > candle Patch.wxs
> >
> > light Patch.wixobj -out Patch.wixmsp
> >
> > torch -p -xi v100\MyPackage.wixpdb v101\ MyPackage.wixpdb -out
> > diff.wixmst
> >
> > pyro Patch.wixmsp -out Patch.msp -t UpdatePatch diff.wixmst
> >
> >
> >
> > The output patch.msp can successfully patch the default instance only.
> > Now, again following the guide, I'm going to populate the Targets
> > property of the patch SummaryInfo stream with the product codes of
> other
> > instances. Something like this:
> >
> >
> >
> >  static void SetTargetProductGUIDs(string mspPath, List
> > productCodes)
> >
> >  {
> >
> > using (Database patchDatabase = new Database(mspPath,
> > DatabaseOpenMode.Transact))
> >
> > {
> >
> >StringBuilder targetsBuilder = new StringBuilder();
> >
> >foreach (string productCode in productCodes)
> >
> >{
> >
> >   targetsBuilder.Append(targetsBuilder.Length == 0 ?
> > productCode : string.Format(";{0}", productCode));
> >
> >}
> >
> >patchDatabase.SummaryInfo.Template =
> > targetsBuilder.ToString();
> >
> >patchDatabase.Commit();
> >
> > }
> >
> > 

Re: [WiX-users] uninstalling second patch does not remove patched files

[Heath Stewart]

If patch 2 supersedes patch 1, it MUST include all the same content. If
you're noticing that files are not removed, changes are that your features
you've modified are now advertised:
http://blogs.msdn.com/heaths/archive/2006/01/23/516457.aspx. But without
logs it's hard to say. Can you update a verbose log from when you installed
patch 2 after 1?

If patch 2 does not supersede 1, both will show up in ARP. If it does
supersede 1, only patch 2 should show up but it also depends if you set
ARPSYSTEMCOMPONENT property or not. A log can help me help you diagnose it.

On Thu, Apr 9, 2009 at 3:37 AM, shibo  wrote:

>
> More info: If I install patch 2 only, then uninstall it, files are removed.
> --
> View this message in context:
> http://n2.nabble.com/uninstalling-second-patch-does-not-remove-patched-files-tp2610228p2610381.html
>  Sent from the wix-users mailing list archive at Nabble.com.
>
>
>
> --
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Reinstalling a Feature on Change option.

[Heath Stewart]

The property name you set has to be in the product's SecureCustomProperties,
so you'll need to anticipate what the property name is and add that to our
product's SecureCustomProperties before you ship or it will not be passed
from the UI to the service.

On Wed, Apr 8, 2009 at 9:09 PM, Sachin Dubey (Tata Consultancy Services) <
v-sad...@microsoft.com> wrote:

> Hi All,
> This problem has made me stuck with no way out.
>
> I have created MSI using Wix 3.0. have one component that creates the
> registry key on install and writes a value. The value is being set from UI.
> I want to enable the "Change" option that should Reinstall the component
> that creates the registry (write) but the with modified value (value again
> set from UI).
>
> I got some guidance from "
> http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg23903.html";
> and wrote the code like:
>
> 1. Added the component to separate Feature (Feature1) with level 1.
> a. Creates registry Key1, with Value = "[VALUE]". Set VALUE = " "
> b. Set VALUE = Test_Install from UI during install.
> 2. The feature gets installed properly, registry key is created with
> desired value.
> 3. On change option, set the REINSTALL = "Feature1" and VALUE =
> "Test_Reinstall".
> 4. The Feature gets Reinstalled properly on Windows 2003 and XP (Vista with
> UAC disables). And the registry value is updated with "Test_Reinstall"
>
> The problem is on Vista with UAC enables, the Feature gets installed, and
> the registry key gets updated but with " " (Default value set in Wix file)
> not with the VALUE set from UI.
>
> Second observation - Reinstall (Change) doesn't prompt for credentials,
> unlike Install or Remove.
> >From log file on Reinstall:
>
> MSI (s) (6C:C0) [19:44:39:276]: Product
> {39EB52BC-295A-4813-B85C-55FCEF59257C} is managed.
> MSI (s) (6C:C0) [19:44:39:276]: Machine policy value
> 'AlwaysInstallElevated' is 0
> MSI (s) (6C:C0) [19:44:39:276]: User policy value 'AlwaysInstallElevated'
> is 0
> MSI (s) (6C:C0) [19:44:39:276]: MSI_LUA: Credential prompt is not required
> at this point, product is managed and deployment compliant
> MSI (s) (6C:C0) [19:44:39:276]: Note: 1: 2205 2:  3: MsiPackageCertificate
> MSI (s) (6C:C0) [19:44:39:276]: Note: 1: 2205 2:  3: MsiDigitalCertificate
> MSI (s) (6C:C0) [19:44:39:277]: PROPERTY CHANGE: Adding ProductState
> property. Its value is '5'.
> MSI (s) (6C:C0) [19:44:39:277]: PROPERTY CHANGE: Adding
> ProductToBeRegistered property. Its value is '1'.
> MSI (s) (6C:C0) [19:44:39:278]: Entering
> CMsiConfigurationManager::SetLastUsedSource.
> MSI (s) (6C:C0) [19:44:39:278]: Specifed source is already in a list.
> MSI (s) (6C:C0) [19:44:39:278]: User policy value 'SearchOrder' is 'nmu'
> MSI (s) (6C:C0) [19:44:39:278]: Machine policy value 'DisableBrowse' is 0
> MSI (s) (6C:C0) [19:44:39:278]: Machine policy value 'AllowLockdownBrowse'
> is 0
> MSI (s) (6C:C0) [19:44:39:279]: Machine policy value
> 'AlwaysInstallElevated' is 0
> MSI (s) (6C:C0) [19:44:39:279]: User policy value 'AlwaysInstallElevated'
> is 0
> MSI (s) (6C:C0) [19:44:39:279]: Product
> {39EB52BC-295A-4813-B85C-55FCEF59257C} is admin assigned: LocalSystem owns
> the publish key.
> MSI (s) (6C:C0) [19:44:39:279]: Product
> {39EB52BC-295A-4813-B85C-55FCEF59257C} is managed.
> MSI (s) (6C:C0) [19:44:39:279]: Running product
> '{39EB52BC-295A-4813-B85C-55FCEF59257C}' with elevated privileges: Product
> is assigned.
> MSI (s) (6C:C0) [19:44:39:279]: Adding new sources is not allowed.
> MSI (s) (6C:C0) [19:44:39:279]: Package name retrieved from configuration
> data: Test.msi'
> MSI (s) (6C:C0) [19:44:39:279]: Determined that existing product (either
> this product or the product being upgraded with a patch) is installed
> per-machine.
> MSI (s) (6C:C0) [19:44:39:279]: Note: 1: 2205 2:  3: Error
> MSI (s) (6C:C0) [19:44:39:281]: Note: 1: 2262 2: AdminProperties 3:
> -2147287038
> MSI (s) (6C:C0) [19:44:39:281]: Machine policy value
> 'AlwaysInstallElevated' is 0
> MSI (s) (6C:C0) [19:44:39:281]: User policy value 'AlwaysInstallElevated'
> is 0
> MSI (s) (6C:C0) [19:44:39:281]: Product
> {39EB52BC-295A-4813-B85C-55FCEF59257C} is admin assigned: LocalSystem owns
> the publish key.
> MSI (s) (6C:C0) [19:44:39:281]: Product
> {39EB52BC-295A-4813-B85C-55FCEF59257C} is managed.
> MSI (s) (6C:C0) [19:44:39:281]: Running product
> '{39EB52BC-295A-4813-B85C-55FCEF59257C}' with elevated privileges: Product
> is assigned.
> MSI (s) (6C:C0) [19:44:39:281]: Machine policy value 'EnableUserControl' is
> 0
> MSI (s) (6C:C0) [19:44:39:281]: PROPERTY CHANGE: Adding
> RestrictedUserControl property. Its value is '1'.
> MSI (s) (6C:C0) [19:44:39:281]: Ignoring disallowed property INSTALLDIR
> MSI (s) (6C:C0) [19:44:39:281]: Ignoring disallowed property TARGETDIR
> MSI (s) (6C:C0) [19:44:39:281]: Ignoring disallowed property VALUE
>
>
>
> It shows the VALUE is set properly but while writing the registry passes it
> as " ".
>
>
> Any help would be greatly appreciated in this 

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Thomas S. Trias]

Neil,

Based upon the source code, SiteId="*" causes two things to occur:

1) A search by Description instead of WebAddress for the existing site 
in ScaWebFindBase; if it is found, step 2 is skipped

2) If a new site is to be created, the starting site id is computed by 
hashing the description, otherwise the search for a free spot starts at 
1; ScaWebFindFreeBase performs a linear search through the sorted list 
of site ids to find the first free site id that is greater than or equal 
to the starting site id.

So, the documentation really only applies to how a free site id is 
computed in the case of an add; it's probably time to fix the documentation.

Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/


 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate   
 presence of existing website using just the Name ->Description 
attribute value versus port settings?
From: Neil Sleightholm 
To: General discussion for Windows Installer XML toolset.   
 , 
Cc: Dmitry Frenkel 
Date: 4/9/2009 11:21 AM
> I think this thread may be misunderstanding what SiteId="*" means. I means 
> use the IIS6 default of setting the site id to the hash of the name, I don't 
> believe it is triggering a search of the description. A site id of 1 is the 
> default of the "Default Web Site" created when IIS is installed. The hashing 
> algorithm can generate a duplicate site id in which case IIS adds one until 
> it finds a free number. See here for more details: 
> http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx 
>
> Neil
>
> -Original Message-
> From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
> Sent: 09 April 2009 16:51
> To: 'tomtr...@artizan.com'
> Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
> of existing website using just the Name -> Description attribute value versus 
> port settings?
>
> Thanks for the additional details and answers to questions.
>
> I think given iis supports to two web sites using the same name and differing 
> only in case then it's the right thing to do to have SiteId=" triggered 
> searching for Description attribute value matches to also be case sensitive.
>
> Wrt our properties.wix entries to create references to existing web sites 
> like the "Default Web Site" I think even there we will use SiteId=" vs 
> SiteId="1" because we really don't care what site id its living on (given 
> that could change if you deleted it, added a different non default web site, 
> and then recreated the default web site manually).   We really just care 
> about being able to get a reference to the well known and understood "Default 
> Web Site" for things that we'd like the installer to stick under it versus 
> our things we want going under our " Web Site".
>
> We tested in our properties.wix using the following so that we'd setup our 
> reference to the Default Web Site w/o any suggestion of us caring what 
> iis:WebAddress settings it had in place and got a compiler error as it seems 
> it is a requirement to a sub-element to a iis:WebSite element.
>  />
>
> Switching it to the following works but then we have the iis:WebAddress port 
> 80 setting/expectation.
> 
> 
> 
>
> q1 - is the above iis:WebSite sub-elemented requirement expected?
>
> q2 - if so in this particular case since we have SiteId=" in place to trigger 
> the metabase search using the Description attribute value AND the fact that 
> it's an iis:WebSite reference vs being part of a component can we expect that 
> the iis:WebAddress element requirement in order to compile will really have 
> no effect, e.g. it shouldn't matter whether or not at install time the 
> default web site is configured with a port 80 binding.
>
>
> From: Thomas S. Trias [mailto:tomtr...@artizan.com]
> Sent: Wednesday, April 08, 2009 6:33 PM
> To: Robert O'Brien
> Cc: 'General discussion for Windows Installer XML toolset.'; Dmitry Frenkel; 
> Kiran Challa
> Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
> of existing website using just the Name -> Description attribute value versus 
> port settings?
>
> I was pretty surprised to see the lstrcmpW there myself; however, it is 
> entirely possible to have two sites where the MD_SERVER_COMMENT values differ 
> only by case (or are even the same; hopefully the IIS Manager is keying sites 
> by SiteId / metabase path and not by description).  Providing more control 
> over the comparison would require either overloading the SiteId further or 
> introducing additional attributes.  Of course, the default should be to 
> behave as WiX does currently.  Note that host header comparisons are also 
> case sensitive, so an additional attribute sounds like the most feasible 
> solution.
>
> 1.  Correct
>
> 2.  Correct.  It's also nice if you configure the Si

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Robert O'Brien]

So it sounds like you are saying the following would not in fact work because 
the hashing of the Description attribute value would not come out to 1.




Therefore the caveat your are trying to clarify is that for sites where you 
know the siteid was not produced using the iis6 published hash algorithm of the 
site name in those cases you'd need to be explicit with the SiteId value for 
the search for the existing web site (not involving use of iis:WebAddress 
settings) to get you the desired result, e.g. specifically in case of Default 
Web Site we had better use SiteId="1" and not SiteId="*".





-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 10:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I mentioned this because it may catch you out and SiteId="*" would fail. For 
example, if you created a site that set the site id to a fixed value, something 
that is perfectly valid to do (adsutil.vbs does this), the hash matching 
wouldn't would. You have found this I believe when trying to find the "Default 
Web Site" and find its site id is 1. This also explains why the name is case 
sensitive, the hash algorithm generates a different site id depending on the 
case. By setting SiteId="*" you are not searching for a name you are searching 
for the site id based on the hash of the name. Looking at the code in 
scaweb.cpp function ScaWebFindBase() I think site id takes precedence over 
name, so you could set the name to anything but as long as the site id is set 
correctly it will find the site.

I hope this helps.

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 17:50
To: 'General discussion for Windows Installer XML toolset.'; 
'tomtr...@artizan.com'; Neil Sleightholm
Cc: Dmitry Frenkel; Kiran Challa
Subject: RE: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

In our case we are not so concerned about what SiteId="*" will result in wrt 
the actual SiteId value that gets generated and used when the msi determines 
its necessary to create the iis:WebSite.

What we are really interested in is the fact that including the SiteId="*" 
attribute, based on discussions in this thread and our test results over the 
course of the past day, results in the iis extension searching the host for 
whether or not the web site already exists using a case sensitive name that 
matches the Description attribute value specified.

This is important behavior to us because w/o SiteId="*" attribute value in 
place what we found is that the iis extension would search the host for whether 
or not the web site already exists using the iis:WebAddress settings and this 
was undersirable because this is something that is not always predictable ad 
design time for all environments.  Example being cases where ops 
creates/configures the web site in advance of the msi having every been run.   
Or we have cases where ops configures the web site left behind after an 
uninstall where iis:WebSite associated component has Permanent="yes" and then 
on next install we want to be able to find that site by name because the port 
settings lookup won't produce an accurate result.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 9:21 AM
To: General discussion for Windows Installer XML toolset.; tomtr...@artizan.com
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I think this thread may be misunderstanding what SiteId="*" means. I means use 
the IIS6 default of setting the site id to the hash of the name, I don't 
believe it is triggering a search of the description. A site id of 1 is the 
default of the "Default Web Site" created when IIS is installed. The hashing 
algorithm can generate a duplicate site id in which case IIS adds one until it 
finds a free number. See here for more details: 
http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 16:51
To: 'tomtr...@artizan.com'
Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

Thanks for the additional details and answers to questions.

I think given iis supports to two web sites using the same name and differing 
only in case then it's the r

Re: [WiX-users] Calling a external setup package

[Thomas S. Trias]

Still probably safer to use a bootstrapper rather than a pseudo-nested 
install.

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/



 Original Message  
Subject: Re: [WiX-users] Calling a external setup package
From: Madden, William 
To: General discussion for Windows Installer XML toolset.   
 
Date: 4/9/2009 10:45 AM
> "A custom action can't run another installer."
>
> This is only partially true, a custom action can run another installer if run 
> from the UI sequence not the Execute sequence, only one install at a time can 
> be within a execute sequence.
>
>
> Bill
>
> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com] 
> Sent: Thursday, April 09, 2009 7:17 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Calling a external setup package
>
> Yu, Brian wrote:
>   
>> Is it still the case where WIX don't really support it? Even with using
>> custom action? 
>>   
>> 
>
> A custom action can't run another installer.
>
>   

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Neil Sleightholm]

I mentioned this because it may catch you out and SiteId="*" would fail. For 
example, if you created a site that set the site id to a fixed value, something 
that is perfectly valid to do (adsutil.vbs does this), the hash matching 
wouldn't would. You have found this I believe when trying to find the "Default 
Web Site" and find its site id is 1. This also explains why the name is case 
sensitive, the hash algorithm generates a different site id depending on the 
case. By setting SiteId="*" you are not searching for a name you are searching 
for the site id based on the hash of the name. Looking at the code in 
scaweb.cpp function ScaWebFindBase() I think site id takes precedence over 
name, so you could set the name to anything but as long as the site id is set 
correctly it will find the site.

I hope this helps.

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
Sent: 09 April 2009 17:50
To: 'General discussion for Windows Installer XML toolset.'; 
'tomtr...@artizan.com'; Neil Sleightholm
Cc: Dmitry Frenkel; Kiran Challa
Subject: RE: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

In our case we are not so concerned about what SiteId="*" will result in wrt 
the actual SiteId value that gets generated and used when the msi determines 
its necessary to create the iis:WebSite.

What we are really interested in is the fact that including the SiteId="*" 
attribute, based on discussions in this thread and our test results over the 
course of the past day, results in the iis extension searching the host for 
whether or not the web site already exists using a case sensitive name that 
matches the Description attribute value specified.

This is important behavior to us because w/o SiteId="*" attribute value in 
place what we found is that the iis extension would search the host for whether 
or not the web site already exists using the iis:WebAddress settings and this 
was undersirable because this is something that is not always predictable ad 
design time for all environments.  Example being cases where ops 
creates/configures the web site in advance of the msi having every been run.   
Or we have cases where ops configures the web site left behind after an 
uninstall where iis:WebSite associated component has Permanent="yes" and then 
on next install we want to be able to find that site by name because the port 
settings lookup won't produce an accurate result.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 9:21 AM
To: General discussion for Windows Installer XML toolset.; tomtr...@artizan.com
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I think this thread may be misunderstanding what SiteId="*" means. I means use 
the IIS6 default of setting the site id to the hash of the name, I don't 
believe it is triggering a search of the description. A site id of 1 is the 
default of the "Default Web Site" created when IIS is installed. The hashing 
algorithm can generate a duplicate site id in which case IIS adds one until it 
finds a free number. See here for more details: 
http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 16:51
To: 'tomtr...@artizan.com'
Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

Thanks for the additional details and answers to questions.

I think given iis supports to two web sites using the same name and differing 
only in case then it's the right thing to do to have SiteId="*" triggered 
searching for Description attribute value matches to also be case sensitive.

Wrt our properties.wix entries to create references to existing web sites like 
the "Default Web Site" I think even there we will use SiteId="*" vs SiteId="1" 
because we really don't care what site id its living on (given that could 
change if you deleted it, added a different non default web site, and then 
recreated the default web site manually).   We really just care about being 
able to get a reference to the well known and understood "Default Web Site" for 
things that we'd like the installer to stick under it versus our things we want 
going under our " Web Site".

We tested in our properties.wix using the following so that we'd setup our 
reference to the Default Web Site w/o any suggestion of us caring what 
iis:WebAddress settings it had in place and got a compiler error as it seems it 
is a requirement to a sub-element to a iis:WebSite elem

Re: [WiX-users] Wix and Crystal Reports

[MacDiarmid, James D]

Where would I normally find a merge module like this, or is this
something I would need to create myself? 

-Original Message-
From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
Sent: Thursday, April 09, 2009 12:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and Crystal Reports

There are usually merge modules for everything Crystal related. I'm
pretty sure there are Crystal Report Viewer merge modules if that's the
same thing. 

Phil Wilson 

-Original Message-
From: MacDiarmid, James D [mailto:james.macdiar...@eds.com]
Sent: Thursday, April 09, 2009 9:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Wix and Crystal Reports


Is anyone installing the Crystal Viewer as well as Crystal Report .rpt
files in their install?  Should I be installing each one as an
individual component or all of them together as one component?  How
should I handle the Crystal Viewer which is an OCX file?



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Thomas S. Trias]

a1 - The iis:WebAddress is required because it is joined to the 
iis:WebSite record when the MSI database is queried.  WiX does not 
currently support a "default" iis:WebAddress; to be honest, adding one 
is simple enough, and would be required if the web site were not found 
and you wanted to create it.  The iis:WebAddress specified below 
contains the bare minimum attributes, and will specify HTTP port 80 on 
all unassigned IP addresses with no host header.  I believe that mimics 
the default settings for "Default Web Site".

a2 - Yes, that is correct, since installation will neither configure nor 
add the web site, and the address will not be used during search.  The 
results of the search (the base metabase path) do get cached along with 
the web site and address information.  If the web site id is found in 
the cache, a sanity check is made against the web address.  I'm not sure 
about the reasoning behind the sanity check (I would need to traipse 
back through the CVS log), but if it is necessary then perhaps the 
condition should bifurcate based upon the SiteId and  check the 
Description instead if the SiteId is -1.

Making the iis:WebAddress element optional based upon ancestry cannot be 
enforced strictly by XSD; it would introduce yet another case where 
validation would require either votive within the IDE or a compile time 
error.  Perhaps there will come a day when XSD supports XPath for 
complex constraints; of course, when XML Schema 1.1 does finally 
surface, we will also have to wait for tools to support it.  RELAX NG 
doesn't even cover this case (is it still supported?).

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/


 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate 
presence of existing website using just the Name -> Description 
attribute value versus port settings?
From: Robert O'Brien 
To: 'tomtr...@artizan.com' 
Cc: "'General discussion for Windows Installer XML toolset.'" 
, Dmitry Frenkel 
, Kiran Challa 
Date: 4/9/2009 10:50 AM
>
> Thanks for the additional details and answers to questions.
>
>  
>
> I think given iis supports to two web sites using the same name and 
> differing only in case then it's the right thing to do to have 
> SiteId="*" triggered searching for Description attribute value matches 
> to also be case sensitive.
>
>  
>
> Wrt our properties.wix entries to create references to existing web 
> sites like the "Default Web Site" I think even there we will use 
> SiteId="*" vs SiteId="1" because we really don't care what site id its 
> living on (given that could change if you deleted it, added a 
> different non default web site, and then recreated the default web 
> site manually).   We really just care about being able to get a 
> reference to the well known and understood "Default Web Site" for 
> things that we'd like the installer to stick under it versus our 
> things we want going under our " Web Site".
>
>  
>
> We tested in our properties.wix using the following so that we'd setup 
> our reference to the Default Web Site w/o any suggestion of us caring 
> what iis:WebAddress settings it had in place and got a compiler error 
> as it seems it is a requirement to a sub-element to a iis:WebSite element.
>
> 
>
>  
>
> Switching it to the following works but then we have the 
> iis:WebAddress port 80 setting/expectation.  
>
> 
>
> 
>
> 
>
>  
>
> q1 - is the above iis:WebSite sub-elemented requirement expected?
>
>  
>
> q2 - if so in this particular case since we have SiteId="*" in place 
> to trigger the metabase search using the Description attribute value 
> AND the fact that it's an iis:WebSite reference vs being part of a 
> component can we expect that the iis:WebAddress element requirement in 
> order to compile will really have no effect, e.g. it shouldn't matter 
> whether or not at install time the default web site is configured with 
> a port 80 binding.
>
>  
>
>  
>
> *From:* Thomas S. Trias [mailto:tomtr...@artizan.com]
> *Sent:* Wednesday, April 08, 2009 6:33 PM
> *To:* Robert O'Brien
> *Cc:* 'General discussion for Windows Installer XML toolset.'; Dmitry 
> Frenkel; Kiran Challa
> *Subject:* Re: [WiX-users] is it a bug that iis:WebSite doesn't locate 
> presence of existing website using just the Name -> Description 
> attribute value versus port settings?
>
>  
>
> I was pretty surprised to see the lstrcmpW there myself; however, it 
> is entirely possible to have two sites where the MD_SERVER_COMMENT 
> values differ only by case (or are even the same; hopefully the IIS 
> Manager is keying sites by SiteId / metabase path and not by 
> description).  Providing more control over the comparison would 
> require either overloading the SiteId further or introducing 
> additional attributes.  Of course, the default should be to behave as 
> WiX does currently.  Note that host header comparisons are also case 
> sensitive, so an a

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Robert O'Brien]

In our case we are not so concerned about what SiteId="*" will result in wrt 
the actual SiteId value that gets generated and used when the msi determines 
its necessary to create the iis:WebSite.

What we are really interested in is the fact that including the SiteId="*" 
attribute, based on discussions in this thread and our test results over the 
course of the past day, results in the iis extension searching the host for 
whether or not the web site already exists using a case sensitive name that 
matches the Description attribute value specified.

This is important behavior to us because w/o SiteId="*" attribute value in 
place what we found is that the iis extension would search the host for whether 
or not the web site already exists using the iis:WebAddress settings and this 
was undersirable because this is something that is not always predictable ad 
design time for all environments.  Example being cases where ops 
creates/configures the web site in advance of the msi having every been run.   
Or we have cases where ops configures the web site left behind after an 
uninstall where iis:WebSite associated component has Permanent="yes" and then 
on next install we want to be able to find that site by name because the port 
settings lookup won't produce an accurate result.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, April 09, 2009 9:21 AM
To: General discussion for Windows Installer XML toolset.; tomtr...@artizan.com
Cc: Dmitry Frenkel
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I think this thread may be misunderstanding what SiteId="*" means. I means use 
the IIS6 default of setting the site id to the hash of the name, I don't 
believe it is triggering a search of the description. A site id of 1 is the 
default of the "Default Web Site" created when IIS is installed. The hashing 
algorithm can generate a duplicate site id in which case IIS adds one until it 
finds a free number. See here for more details: 
http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com]
Sent: 09 April 2009 16:51
To: 'tomtr...@artizan.com'
Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

Thanks for the additional details and answers to questions.

I think given iis supports to two web sites using the same name and differing 
only in case then it's the right thing to do to have SiteId="*" triggered 
searching for Description attribute value matches to also be case sensitive.

Wrt our properties.wix entries to create references to existing web sites like 
the "Default Web Site" I think even there we will use SiteId="*" vs SiteId="1" 
because we really don't care what site id its living on (given that could 
change if you deleted it, added a different non default web site, and then 
recreated the default web site manually).   We really just care about being 
able to get a reference to the well known and understood "Default Web Site" for 
things that we'd like the installer to stick under it versus our things we want 
going under our " Web Site".

We tested in our properties.wix using the following so that we'd setup our 
reference to the Default Web Site w/o any suggestion of us caring what 
iis:WebAddress settings it had in place and got a compiler error as it seems it 
is a requirement to a sub-element to a iis:WebSite element.


Switching it to the following works but then we have the iis:WebAddress port 80 
setting/expectation.




q1 - is the above iis:WebSite sub-elemented requirement expected?

q2 - if so in this particular case since we have SiteId="*" in place to trigger 
the metabase search using the Description attribute value AND the fact that 
it's an iis:WebSite reference vs being part of a component can we expect that 
the iis:WebAddress element requirement in order to compile will really have no 
effect, e.g. it shouldn't matter whether or not at install time the default web 
site is configured with a port 80 binding.


From: Thomas S. Trias [mailto:tomtr...@artizan.com]
Sent: Wednesday, April 08, 2009 6:33 PM
To: Robert O'Brien
Cc: 'General discussion for Windows Installer XML toolset.'; Dmitry Frenkel; 
Kiran Challa
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I was pretty surprised to see the lstrcmpW there myself; however, it is 
entirely possible to have two sites where the MD_SERVER_COMMENT values differ 
only by case (or are even the same; hopefully the IIS Manager is keying sites 
by Site

Re: [WiX-users] Wix and Crystal Reports

[Don Benson]

On Thu, Apr 9, 2009 at 12:06 PM, MacDiarmid, James D <
james.macdiar...@eds.com> wrote:

>
> Is anyone installing the Crystal Viewer as well as Crystal Report .rpt
> files in their install?  Should I be installing each one as an
> individual component or all of them together as one component?  How
> should I handle the Crystal Viewer which is an OCX file?
>

We deliver a few hundred RPT files with our product. We chose to make each
file its own component. We made this decision so an accidentally deleted
report file can be automatically repaired.

What version of Crystal are you using? For the redistributable components,
we used to use a merge module that was supplied by Crystal. This merge
module was not updated with service packs, though, so we ended up making the
Crystal DLLs and OCXs integral components within our installation. They are
all marked as permanent, so we don't remove them and break another
application that might also be depending on them.

- Don Benson -
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix and Crystal Reports

[Wilson, Phil]

There are usually merge modules for everything Crystal related. I'm pretty sure 
there are Crystal Report Viewer merge modules if that's the same thing. 

Phil Wilson 

-Original Message-
From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] 
Sent: Thursday, April 09, 2009 9:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Wix and Crystal Reports


Is anyone installing the Crystal Viewer as well as Crystal Report .rpt
files in their install?  Should I be installing each one as an
individual component or all of them together as one component?  How
should I handle the Crystal Viewer which is an OCX file?


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Neil Sleightholm]

I think this thread may be misunderstanding what SiteId="*" means. I means use 
the IIS6 default of setting the site id to the hash of the name, I don't 
believe it is triggering a search of the description. A site id of 1 is the 
default of the "Default Web Site" created when IIS is installed. The hashing 
algorithm can generate a duplicate site id in which case IIS adds one until it 
finds a free number. See here for more details: 
http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx 

Neil

-Original Message-
From: Robert O'Brien [mailto:robert.obr...@microsoft.com] 
Sent: 09 April 2009 16:51
To: 'tomtr...@artizan.com'
Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

Thanks for the additional details and answers to questions.

I think given iis supports to two web sites using the same name and differing 
only in case then it's the right thing to do to have SiteId="*" triggered 
searching for Description attribute value matches to also be case sensitive.

Wrt our properties.wix entries to create references to existing web sites like 
the "Default Web Site" I think even there we will use SiteId="*" vs SiteId="1" 
because we really don't care what site id its living on (given that could 
change if you deleted it, added a different non default web site, and then 
recreated the default web site manually).   We really just care about being 
able to get a reference to the well known and understood "Default Web Site" for 
things that we'd like the installer to stick under it versus our things we want 
going under our " Web Site".

We tested in our properties.wix using the following so that we'd setup our 
reference to the Default Web Site w/o any suggestion of us caring what 
iis:WebAddress settings it had in place and got a compiler error as it seems it 
is a requirement to a sub-element to a iis:WebSite element.


Switching it to the following works but then we have the iis:WebAddress port 80 
setting/expectation.




q1 - is the above iis:WebSite sub-elemented requirement expected?

q2 - if so in this particular case since we have SiteId="*" in place to trigger 
the metabase search using the Description attribute value AND the fact that 
it's an iis:WebSite reference vs being part of a component can we expect that 
the iis:WebAddress element requirement in order to compile will really have no 
effect, e.g. it shouldn't matter whether or not at install time the default web 
site is configured with a port 80 binding.


From: Thomas S. Trias [mailto:tomtr...@artizan.com]
Sent: Wednesday, April 08, 2009 6:33 PM
To: Robert O'Brien
Cc: 'General discussion for Windows Installer XML toolset.'; Dmitry Frenkel; 
Kiran Challa
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I was pretty surprised to see the lstrcmpW there myself; however, it is 
entirely possible to have two sites where the MD_SERVER_COMMENT values differ 
only by case (or are even the same; hopefully the IIS Manager is keying sites 
by SiteId / metabase path and not by description).  Providing more control over 
the comparison would require either overloading the SiteId further or 
introducing additional attributes.  Of course, the default should be to behave 
as WiX does currently.  Note that host header comparisons are also case 
sensitive, so an additional attribute sounds like the most feasible solution.

1.  Correct

2.  Correct.  It's also nice if you configure the SiteId at installation time 
(perhaps by letting someone pick an existing site, or if you are upgrading an 
existing site.

3.  What can I say; for my particular needs, I'm living as close to the 
bleeding edge as I can.


Thomas S. Trias

Senior Developer

Artizan Internet Services

http://www.artizan.com/


 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?
From: Robert O'Brien 

To: 'tomtr...@artizan.com' 
, 'General discussion for 
Windows Installer XML toolset.' 

Cc: Dmitry Frenkel 
, Kiran 
Challa 
Date: 4/8/2009 8:15 PM


Thanks for the additional clarification.  This is pretty much exactly what we 
want and need. The case sensitive Description attribute search would preferably 
be case insensitive but this we can live with or file a bug or feature request 
against to have changed to be case insensitive



To playback what I'm hearing and what Kiran is finding in test

Re: [WiX-users] Registering votive in build\debug\x86 with VS 2005

[Thomas S. Trias]

Looking at the MSBuild output for the votive2005.csproj, I see that the 
zips were already being copied to the appropriate places, so I guess 
that wasn't the issue.  I'm stumped.  FYI, I am developing changes on 
top of version 3.0.4923.0; if there is a known issue with votive for 
that build, I will go ahead and update, but I'd rather avoid it if I 
can.  We are performing QA runs of our installation packages (with some 
custom changes to the IIS and Util extensions), so I'd rather not 
introduce too many unknown quantities.

I did peruse the bug tracker, and found the following bugs that relate 
to the issues I am experiencing:

No WiX project templates in VS 2005 - ID: 2586446
Visual Studio 2005 Solution Explorer-Project Missing (Vista) - ID: 
2368345 (although I am on XP SP3 x86)
Wix projects fail to appear in Solution Explorer - ID: 2051681

I looked at 
http://blogs.msdn.com/jasongin/archive/2008/07/09/votive-project-platform-configurations.aspx
 
but it does not seem to apply, since I am not opening any existing 
projects or solutions.

As a side note, does anyone know of documentation for the visual studio 
project file formats (and perhaps how they translate to built-in MSBuild 
actions)?  Trying to determine where the files are going just by looking 
at the project files is quite difficult; hopefully I'm missing something 
easy.

Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/



 Original Message  
Subject: Registering votive in build\debug\x86 with VS 2005
From: Thomas S. Trias 
To: 'General discussion for Windows Installer XML toolset.' 

Date: 4/6/2009 6:26 PM
> I got past the first two hurdles, getting votive2005 to build, 
> modifying RegisterVotive.bat to use the build\debug\x86 directory, but 
> when I go to add a .WIX project, the solution explorer goes blank 
> (although it says Project1 created successfully).
>
> Here is my modified RegisterVotive.bat:
>
> --- SNIP ---
> 
>  
>
> :: RegisterVotive.bat
> :: ---
> :: Preprocesses all of the various support files for working with 
> Votive in a development
> :: environment and then registers Votive with Visual Studio 2005.
> 
>  
>
>
> @echo off
> setlocal
>
> :: When running under 64-bit Windows, the registry key is stored under 
> the Wow6432Node.
> set 
> VS_REGKEYROOT=HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0Exp
> if /i [%PROCESSOR_ARCHITECTURE%]==[AMD64] set 
> VS_REGKEYROOT=HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\8.0Exp
>  
>
>
> :: Make sure the SDK is installed (the experimental hive is registered).
> reg query %VS_REGKEYROOT%\Setup\VS /v EnvironmentPath > NUL 2> NUL
> if not %errorlevel% == 0 (
>echo VS SDK for Visual Studio 2005 is not installed. Skipping 
> registration.
>goto End
> )
>
> :: Try to get the paths to Visual Studio
> for /f "tokens=3*" %%a in ('reg query %VS_REGKEYROOT%\Setup\VS /v 
> EnvironmentPath ^| find "EnvironmentPath"') do set DEVENVPATH_2005=%%a 
> %%b
> for /f "tokens=3*" %%a in ('reg query %VS_REGKEYROOT%\Setup\VS /v 
> EnvironmentDirectory ^| find "EnvironmentDirectory"') do set 
> DEVENVDIR_2005=%%a %%b
> :: GUIDs
> set PACKAGE_GUID={E0EE8E7D-F498-459E-9E90-2B3D73124AD5}
> set PROJECT_GUID={930C7802-8A8C-48F9-8165-68863BCCD9DD}
> set XML_EDITOR_GUID_2005={FA3CD31E-987B-443A-9B81-186104E8DAC1}
>
> :: Toools declarations
> :: set VOTIVE_PREPROCESSOR=%~dp0..\..\..\Release\debug\VotivePP.exe
> set VOTIVE_PREPROCESSOR=%WIX_ROOT%\build\debug\x86\VotivePP.exe
>
> :: Directories
> :: set SCONCE_TARGETDIR=%TARGETROOT%\wix\x86\debug\lang-neutral\
> set SCONCE_TARGETDIR=%WIX_ROOT%\build\debug\x86\
> set SCONCE_TARGETPATH=%SCONCE_TARGETDIR%sconce2005.dll
> :: set VOTIVE_TARGETDIR=%TARGETROOT%\wix\x86\debug\lang-neutral\
> set VOTIVE_TARGETDIR=%WIX_ROOT%\build\debug\x86\
> set VOTIVE_TARGETPATH=%VOTIVE_TARGETDIR%votive2005.dll
> :: set WIXTOOLSDIR=%TARGETROOT%\wix\x86\debug\lang-neutral\
> set WIXTOOLSDIR=%WIX_ROOT%\build\debug\x86\
> set ITEMTEMPLATESDIR=%DEVENVDIR_2005%ItemTemplatesExp\WiX\
> set PROJECTTEMPLATESDIR=%DEVENVDIR_2005%ProjectTemplatesExp\WiX\
>
> :: Write the .reg files and use reg.exe to import the files
> set REG_FILE=%~dp0Register.reg
> echo Writing package registry settings for Visual Studio 2005...
> "%VOTIVE_PREPROCESSOR%" -bs "%~dp0Register.reg.pp" "%REG_FILE%" 
> VS_REGKEYROOT="%VS_REGKEYROOT%" DLLPATH="%VOTIVE_TARGETPATH%" 
> DLLDIR="%VOTIVE_TARGETDIR%\" SCONCEPATH="%SCONCE_TARGETPATH%" 
> ITEMTEMPLATESDIR="%ITEMTEMPLATESDIR%\" 
> PROJECTTEMPLATESDIR="%PROJECTTEMPLATESDIR%\" 
> WIXTOOLSDIR="%WIXTOOLSDIR%\" DEVENVPATH="%DEVENVPATH_2005%" 
> PACKAGE_GUID=%PACKAGE_GUID% PROJECT_GUID=%PROJECT_GUID% 
> XML_EDITOR_GUID=%XML_EDITOR_GUID_2005% VS_VERSION=8.0 
> VS_VERSION_YE

[WiX-users] Wix and Crystal Reports

[MacDiarmid, James D]

Is anyone installing the Crystal Viewer as well as Crystal Report .rpt
files in their install?  Should I be installing each one as an
individual component or all of them together as one component?  How
should I handle the Crystal Viewer which is an OCX file?


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings?

[Robert O'Brien]

Thanks for the additional details and answers to questions.

I think given iis supports to two web sites using the same name and differing 
only in case then it's the right thing to do to have SiteId="*" triggered 
searching for Description attribute value matches to also be case sensitive.

Wrt our properties.wix entries to create references to existing web sites like 
the "Default Web Site" I think even there we will use SiteId="*" vs SiteId="1" 
because we really don't care what site id its living on (given that could 
change if you deleted it, added a different non default web site, and then 
recreated the default web site manually).   We really just care about being 
able to get a reference to the well known and understood "Default Web Site" for 
things that we'd like the installer to stick under it versus our things we want 
going under our " Web Site".

We tested in our properties.wix using the following so that we'd setup our 
reference to the Default Web Site w/o any suggestion of us caring what 
iis:WebAddress settings it had in place and got a compiler error as it seems it 
is a requirement to a sub-element to a iis:WebSite element.


Switching it to the following works but then we have the iis:WebAddress port 80 
setting/expectation.




q1 - is the above iis:WebSite sub-elemented requirement expected?

q2 - if so in this particular case since we have SiteId="*" in place to trigger 
the metabase search using the Description attribute value AND the fact that 
it's an iis:WebSite reference vs being part of a component can we expect that 
the iis:WebAddress element requirement in order to compile will really have no 
effect, e.g. it shouldn't matter whether or not at install time the default web 
site is configured with a port 80 binding.


From: Thomas S. Trias [mailto:tomtr...@artizan.com]
Sent: Wednesday, April 08, 2009 6:33 PM
To: Robert O'Brien
Cc: 'General discussion for Windows Installer XML toolset.'; Dmitry Frenkel; 
Kiran Challa
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?

I was pretty surprised to see the lstrcmpW there myself; however, it is 
entirely possible to have two sites where the MD_SERVER_COMMENT values differ 
only by case (or are even the same; hopefully the IIS Manager is keying sites 
by SiteId / metabase path and not by description).  Providing more control over 
the comparison would require either overloading the SiteId further or 
introducing additional attributes.  Of course, the default should be to behave 
as WiX does currently.  Note that host header comparisons are also case 
sensitive, so an additional attribute sounds like the most feasible solution.

1.  Correct

2.  Correct.  It's also nice if you configure the SiteId at installation time 
(perhaps by letting someone pick an existing site, or if you are upgrading an 
existing site.

3.  What can I say; for my particular needs, I'm living as close to the 
bleeding edge as I can.


Thomas S. Trias

Senior Developer

Artizan Internet Services

http://www.artizan.com/


 Original Message  
Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence 
of existing website using just the Name -> Description attribute value versus 
port settings?
From: Robert O'Brien 

To: 'tomtr...@artizan.com' 
, 'General discussion for 
Windows Installer XML toolset.' 

Cc: Dmitry Frenkel 
, Kiran 
Challa 
Date: 4/8/2009 8:15 PM


Thanks for the additional clarification.  This is pretty much exactly what we 
want and need. The case sensitive Description attribute search would preferably 
be case insensitive but this we can live with or file a bug or feature request 
against to have changed to be case insensitive



To playback what I'm hearing and what Kiran is finding in tests so far using 
this information:

1. if we specify a SiteId="*" then the iis:WebSite Description attribute value 
gets used in a case sensitive search to see if a match exists before deciding 
to create a the site.  Any child iis:WebAddress settings of iis:WebSite entries 
where SiteId="*" attribute is included will not affect the search to see if an 
existing instance of the web site is present before deciding to create a the 
site.



2. if we specify a SiteId="#" then the iis:WebSite syntax will look for 
explicitly for that SiteId to see if a match exists before deciding to create a 
new site.  This is particularly useful in case where you'd like to creating 
iis:WebSite references to well known "Default Web Site" where SiteId="1" 
attribute setting can be used so that in the case of a w08 or w08r2 default web 
server role installation you end up referencing the "Default Web Site

Re: [WiX-users] Calling a external setup package

[Madden, William]

"A custom action can't run another installer."

This is only partially true, a custom action can run another installer if run 
from the UI sequence not the Execute sequence, only one install at a time can 
be within a execute sequence.


Bill

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Thursday, April 09, 2009 7:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Calling a external setup package

Yu, Brian wrote:
> Is it still the case where WIX don't really support it? Even with using
> custom action? 
>   

A custom action can't run another installer.

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





--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Start Menu Shortcut Problem

[Stryder Crown]

ok, so, what's the difference between including the shortcut as a child
element to the File node, or creating an entire component around the
shortcut?  And do we really need registry writes for a shortcut element?
What does that achieve?  Link to an article?

*curious*

Stryder

On Wed, Apr 8, 2009 at 9:26 AM, Pally Sandher wrote:

> The WiX.chm file has a section in the How To Guides on Shortcuts. It
> explains all this in detail.
>
>
> Palbinder Sandher
> Software Deployment & IT Administrator
> 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: Madden, William [mailto:william.mad...@sage.com]
> Sent: 08 April 2009 16:35
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Start Menu Shortcut Problem
>
> I just went through this myself use AllUsersProgramMenuFolder as the
> parent this is "perMachine" where ProgramMenuFolder is "perUser".
>
> I did have to create a RemoveFolder entry for my subfolder and set
> On="Uninstall"
>
> William Madden
> T:  480.368.3736 (x7679)
>
> -Original Message-
> From: Lanteigne, Alan [mailto:alan.lantei...@inin.com]
> Sent: Wednesday, April 08, 2009 7:59 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Start Menu Shortcut Problem
>
> Hello Wix World:
>
> While trying to setup a shortcut to an EXE, I'm getting this error:
>
> ICE64: The directory ProgramMenuDir is in the user profile but is not
> listed in the RemoveFile table.
>
> I thought I had done everything correctly but apparently I'm missing
> something.  Googling shows something about ProgramMenuFolder being
> specific to a user's profile, but I'm trying to setup this shortcut for
> "All Users"... not just one user.  For one thing, I want newly created
> users (after the app is installed) to have the shortcut appear.  Also,
> the "My App Folder" is used by other programs so I don't want to remove
> it if this MSI is uninstalled.
>
> Here's what I'm doing:
>
>
>
>   Guid="193119C5-AF4B-4432-9406-FFF1C34DE71D">
> Source="BuildFiles\System32\ myTest.exe" Vital="yes" KeyPath="yes"
> DiskId="1" />
> Name="Run myTest " Icon="myTestIcon" IconIndex="0" Show="normal"
> WorkingDirectory="sys32Folder" />
>  
>
>  
>
>  
>
>  
>  
>
>
>
> I later define the Icon and set the ALLUSERS property to 1.
>
> What am I missing or not understanding?
>
> Thanks,
>
> Alan
>
> -Original Message-
> From: wix-users-requ...@lists.sourceforge.net
> [mailto:wix-users-requ...@lists.sourceforge.net]
> Sent: Tuesday, April 07, 2009 3:02 PM
> To: wix-users@lists.sourceforge.net
> Subject: WiX-users Digest, Vol 35, Issue 30
>
> Send WiX-users mailing list submissions to
>wix-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.sourceforge.net/lists/listinfo/wix-users
> or, via email, send a message with subject or body 'help' to
>wix-users-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
>wix-users-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of WiX-users digest..."
>
>
> Today's Topics:
>
>   1. Re: Votive not working in build 3.0.5207 (Neil Sleightholm)
>   2. Re: ICE64: The directory ProgramMenuDir is in the user
>  profile but is not listed in the RemoveFile table. (Rob Mensching)
>   3. Re: Check for IIS application pools (Rob Mensching)
>   4.  DTF build issue (mcheshier)
>   5. Re: how to change an installed package? (Alan Sinclair)
>   6. Re: Check for IIS application pools (mcheshier)
>   7. Re: how to change an installed package? (Karl Denning)
>
>
> --
>
> Message: 1
> Date: Tue, 7 Apr 2009 18:04:10 +0100
> From: "Neil Sleightholm" 
> Subject: Re: [WiX-users] Votive not working in build 3.0.5207
> To: "General discussion for Windows Installer XML toolset."
>
> Message-ID:
>
> Content-Type: text/plain;   charset="us-ascii"
>
> I have just confirmed this on another PC. Create a new WiX project,
> right click on project and select "Add | New folder" and you get an
> error "The operation cannot be completed".
>
> Bug raised:
> https://sourceforge.net/tracker/?func=detail&aid=2741235&group_id=105970
> &atid=642714
>
> Neil
>
> -Original Message-
> From: Neil Sleightholm [mailto:n...@x2systems.com]
> Sent: 07 April 2009 17:09
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] V

Re: [WiX-users] x-project references in votive?

[Stryder Crown]

yep!  I totally figured it out.  I was told/taught to compile seperate
projects as merge modules...which didn't make any sense, well, some sense.
Just gets unweildy after awhile.  yay for wixlib!  Though, not so yay for
the confusion about relative paths and including binaries in the
wixlib...but it's all good now.  Thanks for the help!

Stryder

On Thu, Apr 9, 2009 at 7:28 AM, Bob Arnson  wrote:

> Stryder Crown wrote:
> > Is there any way to reference a component defined in another project
> using
> > Votive and Visual Studio 2008?
> >
>
> It works as you've described. You then have to set up project
> dependencies so project #2 is dependent on #1. #1 should product a .wixlib.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
>
> --
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to install a shortcut conditionally?

[Bob Arnson]

Sebastian Brand wrote:
> I tried the same thing and it does work. But ironically it's producing an
> ICE30 error now:
> ICE30: The target file 'file.exe' is installed in '[TARGETDIR]\' by two
> different components on an SFN system: 'shortcut_to_file.exe1' and
> 'file.exe1'. This breaks component reference counting.
>   

That error should only happen if there are no conditions on the components.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to get result from application?

[Yan Sklyarenko]

Hey Taras,

Check out the DTF API - the perfect way to write managed-code custom
actions. It is delivered together with WiX toolset.

P.S. BTW, the world is really small, I couldn't imagine I meet you here.
;)

-- Yan

-Original Message-
From: Taras Ko [mailto:hector_the_h...@list.ru] 
Sent: Thursday, April 09, 2009 4:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to get result from application?


Hi!

How can I get a result from application running?
Or any link how to create C# custom actions?

Regards,
Taras
-- 
View this message in context:
http://n2.nabble.com/How-to-get-result-from-application--tp2610951p26109
51.html
Sent from the wix-users mailing list archive at Nabble.com.



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] mergemod CAs not getting into InstallExecuteSequence

[Bob Arnson]

Alan Sinclair wrote:
> I've got a merge module that's used successfully in dozens of packages. BUT 
> ... in a new MSI the mergemod's custom actions are missing from the 
> InstallExecuteSequence although they are getting into the CustomAction table. 
>  What might cause this?
>   

Missing ModuleInstallExecuteSequence rows.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Unexpected behaviour in PerformanceCounter uninstall rollback

[Bob Arnson]

Paul Nearney wrote:
> When an uninstall fails and rolls back, I would expect the performance 
> counters to stay registered on the system, the same way the service does for 
> example. However, the performance counters get removed.
>   

Definitely sounds like a bug. Please open a bug on SF and attach verbose 
install and uninstall logs.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] x-project references in votive?

[Bob Arnson]

Stryder Crown wrote:
> Is there any way to reference a component defined in another project using
> Votive and Visual Studio 2008?
>   

It works as you've described. You then have to set up project 
dependencies so project #2 is dependent on #1. #1 should product a .wixlib.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Reboot based on application exit code?

[Bob Arnson]

Taras Ko wrote:
> I have .NET application installing/uninstalling driver. 

The WixDifxAppExtension installs drivers and handles reboots as needed.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem with my Custom UI in Wix v3

[Bob Arnson]

Ben Charlton wrote:
> 
>   

You need to replace the stock dialog set you're using (WixUI_Mondo in 
this case), not just add to it. What's happening is that your Publish 
values are mixing in with those in WixUI_Mondo.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CreateFolder/RemoveFolder with Empty Component Guid

[Bob Arnson]

Dominik Guder wrote:
> My very first question is: Is it valid to use an empty Component/@Guid for 
> CreateFolder (and RemoveFolder as I use this too)
>   

No. If you omit the component guid, MSI "forgets" about the component 
and will never uninstall it.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Calling a external setup package

[Bob Arnson]

Yu, Brian wrote:
> Is it still the case where WIX don't really support it? Even with using
> custom action? 
>   

A custom action can't run another installer.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent Cancel and Ignore in FileInUse Dialog

[Bob Arnson]

Weber Stefan (IT) wrote:
> is there a way to hide/remove those two buttons in the fileinuse dialog ?
>   

You can't prevent cancellation, since closing the dialog will have that 
effect. Otherwise, you need to remove the buttons from a custom 
FilesInUse dialog; there's no option to remove them from the WixUI dialog.

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



--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to get result from application?

[Taras Ko]

Hi!

How can I get a result from application running?
Or any link how to create C# custom actions?

Regards,
Taras
-- 
View this message in context: 
http://n2.nabble.com/How-to-get-result-from-application--tp2610951p2610951.html
Sent from the wix-users mailing list archive at Nabble.com.


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CreateFolder/RemoveFolder with Empty Component Guid

[Dominik Guder]

Hey Dominik,

The Component/@Guid="*" is the valid way to auto generate GUIDs. There is
another switch -gg that generates GUIDs for you. What issue are using seeing
using the "*"?



Hi Brian,

sorry for mixing Component/@Guid and Heat issue in my first message

yes but not if only a  Element is places in Component:






I'll get following error:
"The Component/@Guid attribute's value '*' is not valid for this component 
because it does not meet the some of the criteria for having an automatically 
generated guid.  Only components with no ODBCDataSource child elements and 
either exactly one file which is the key path or no files and a registry with 
no Property substitutions as the key path may use an automatically generated 
guid."

So my solution is to remove the asterisk from Component/@Guid




My very first question is: Is it valid to use an empty Component/@Guid for 
CreateFolder (and RemoveFolder as I use this too)

Side Note: I also tried -gg switch on Heat, but then I always get different 
guids on each run. Where Guid="*" is supposed to created stable Guids as long 
as the path remains stable.

Best Regards
Dominik
-- 
View this message in context: 
http://n2.nabble.com/CreateFolder-RemoveFolder-with-Empty-Component-Guid-tp2593449p2610435.html
Sent from the wix-users mailing list archive at Nabble.com.


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] uninstalling second patch does not remove patched files

[shibo]

More info: If I install patch 2 only, then uninstall it, files are removed.
-- 
View this message in context: 
http://n2.nabble.com/uninstalling-second-patch-does-not-remove-patched-files-tp2610228p2610381.html
Sent from the wix-users mailing list archive at Nabble.com.


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WebAppPool/@QueueLimit limited to 32767

[Alex Cater]

It appears that the range of legal values for WebAppPool/@QueueLimit are from 0 
to 32767. However, the range, certainly in IIS6, appears to be that of an 
unsigned short. I needed to disable 'Limit the kernel request queue', which can 
be achieved by setting QueueLimit (MD_APPPOOL_UL_APPPOOL_QUEUE_LENGTH) to 
65535. This is not currently possible via the WebAppPool element, unless I am 
missing something, and as a result I have had to set the aforementioned 
property via a deferred CA.

Does anyone know whether this is a known issue? If not I will raise it as a bug.

-- 
View this message in context: 
http://n2.nabble.com/WebAppPool-%40QueueLimit-limited-to-32767-tp2610297p2610297.html
Sent from the wix-users mailing list archive at Nabble.com.


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] uninstalling second patch does not remove patched files

[shibo]

After using WiX 2.0 for half year, I need to create  pacthes now, and encounter 
a problem, uninstalling patch does not remove patched files:

1. Create a baseline installer, then installing is OK.

2. Create an upgrade 1 installer with new files added, create patch 1 between 
baseline and upgrade 1, installing patch 1 and remove patch 1 are both OK, new 
files are removed after un-installation.

3. Create an upgrade 2 installer with more new files added, create patch 2 
between baseline and upgrade 2. Patch 2 wxs file has a line indicating to 
replace pacth 1. Installing patch 1 and patch 2, then un-install  patch 2, new 
files added by patch 2 are NOT removed, even though these files are marked to 
be removed in the log file.  Un-installing patch 1 and baseline do not remove 
them either.

Could you please help:
1. When patch 2 is set to replace patch 1, shall "Add/Remove programs" only 
show patch 2 after patch 2 installed?
2. Please advise why files from patch 2 are not removed after patch 2 
uninstalled?



-- 
View this message in context: 
http://n2.nabble.com/uninstalling-second-patch-does-not-remove-patched-files-tp2610228p2610228.html
Sent from the wix-users mailing list archive at Nabble.com.


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Calling a external setup package

[Yu, Brian]

Hi there

I am trying to get my installer to run dotnet2.exe and others as
pre-requisites before running my msi.
After some googling, the term I was looking for was bootstrapper /
chaininstaller

Is it still the case where WIX don't really support it? Even with using
custom action? 

If so I'll try and learn how to use dotnetinstaller

Brian


-Original Message-
From: dB. [mailto:dbl...@dblock.org] 
Sent: 19 March 2009 12:18
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Calling a external setup package

On an even more positive note this is fully supported by
http://dotnetinstaller.codeplex.com/. You will soon need something that
checks whether your .exe needs to be run, dotnetinstaller will do it for
you.

-Original Message-
From: Brian Rogers [mailto:rogers.br...@gmail.com] 
Sent: Thursday, March 19, 2009 2:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Calling a external setup package

Hey Jim,

There is not an "official" way to do this at the time. You could develop
your own "bootstrapper" that would launch the sequence. It is highly
recommend that you don't use a custom action to launch a secondary
process
while installing.

On a positive note, WIX is currently in the process of developing Burn
(a
bootstrapper). No official release date is set at this time.

Thanks,

Brian Rogers
"Intelligence removes complexity." - Me
http://icumove.spaces.live.com


On Fri, Mar 6, 2009 at 11:50 AM, MacDiarmid, James D <
james.macdiar...@eds.com> wrote:

>
> If I want to call a setup package such as a third-party exe, would I
> need to include it in the install, or can I just include it on the
> install media?
>
> Jim MacDiarmid
> EDS, an HP company
> U.S. Public Sector
> Department of Homeland Security Segment
> 703-236-3821(office)
> 571-247-2343(cell)
>
>
>
>

--
> Open Source Business Conference (OSBC), March 24-25, 2009, San
Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source
code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based
development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

_
This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are 
incorporated under the laws of England and Wales (company no. 05677531 and VAT 
registration no. 872810613). Our registered office is at 155 Bishopsgate, 
London EC2M 3TQ. This e-mail and/or any attached documents may contain 
privileged and confidential information and should only be read by those 
persons to whom this e-mail is addressed. Use by other than intended recipients 
is prohibited. If you are not the addressee, you must not copy, distribute, 
disclose or use any of the information in it. If you have received it in error, 
please delete it and immediately notify the sender. EASYSCREEN reserves the 
right to monitor all e-mail messages passing through its network. As we cannot 
guarantee the genuineness, accuracy or completeness of the information 
contained in this message, the statements set forth are not legally binding.

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-us

Re: [WiX-users] How to install a shortcut conditionally?

[Sebastian Brand]

Hello,

Bob Arnson wrote:
> Advertised shortcuts require the component to include the target program. 
> So either include it in both components (relying on WiX smart cabbing to 
> not bloat the size of your .msi package) or you need to make the shortcut 
> non-advertised and fix the ICE43 and ICE57 errors with additional registry
entries.

I tried the same thing and it does work. But ironically it's producing an
ICE30 error now:
ICE30: The target file 'file.exe' is installed in '[TARGETDIR]\' by two
different components on an SFN system: 'shortcut_to_file.exe1' and
'file.exe1'. This breaks component reference counting.

Does anyone have an idea how to fix this without loosing conditions for
advertised shortcuts?


Best regards,
Sebastian Brand

Instyler Software - http://www.instyler.com




--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Problem with my Custom UI in Wix v3

[Ben Charlton]

Here is my Ui text from my wix installer...(see bottom)

I am trying to add a custom dialog after the license and before the 
SetupTypedlg - compiles fine no errors but the MSI doesn’t do as intended
Jumps from Licence to setup?

Any tips on how to get this working...I tried including DialogRefs like
 
But no difference





  



 
 1
 

  Enter the Encrypted Password.  This is a series of 8 
hexadecimal numbers

  
  LicenseAccepted = "1"
  1
  1
  1



Ph: 32682688
Fax: 38681488
The views expressed in this email are those of the sender and may not equate to 
the views of the
Ascot Veterinary Surgery. 


--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Unabled to open / create Wix projects in Visual Studio 2008

[Hiko Hiko]

Hello,
we want to use Wix to create setups in our software development 
process. I have to test if Wix matches our requirements. Unfortunately,
 for some days I canŽt open or create any Wix project in Visual 
Studio 2008 (the days before it was possible).
I changed my wix projects to "check for .NET Framework Versions" and 
to "install the .NET Framework Using a Bootstrapper" according to the 
Wix documentation. I had to unload and reload files of my Wix-
projects. I might also have changed something in the temp folder 
accidentally. After these changes, I was no longer abled to open or 
create any Wix project in Visual Studio 2008.
I deinstalled and reinstalled Visual Studio 2008 and Wix but that 
didnŽt solve the problem.
Every time I try to open or create a wix project in Visual Studio 
2008, I get the following error message:"... cannot be opened because 
its project type (.wixproj) is not supported by this version of the 
application. To open it, please use a version that supports this type 
of project."
I use Visual Studio 2008 and Wix 3.0.4805.0
What might I do wrong?
I searched the Internet but I couldnŽt find an answer to my question.

Thanks for your help

Hiko

__
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele 
ausländische Netze zum gleichen Preis! 
https://produkte.web.de/webde_sms/sms




--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX MSBuild. WixLibrary HintPath

[Murray Hipper]

Hi All,

Why does user reference paths not update wix library locations and still
enforces the use of the hint path? Is there any way around it?

To give some Context, We have a scenario where we need to change the
projects reference locations per user at different times in development.
What usually happens is they will have a different copy of a dll that
they are trying to integrate so they update the 'Reference Paths'
sections in the projects properties such that it now points to their
development directory on their local machine. This is fine because this
setting change will be made to a new custom file
(ProjectName.vbproj.user) which isn't checked into source control
(important) with the following code.

http://schemas.microsoft.com/developer/msbuild/2003";>
  
D:\MyDevArea\
  


This works well as it updates the projects references ignoring the
hintpath when the same dll is found in that directory.

Now onto Wix, I was most pleased when I saw the Paths tab in the
properties page. Updating 'Reference Paths' also made this .user file
even though the method of adding them is different. 

What is my problem is that it does not update the path used for the
WixLibrary. The code for the .wixproj is as follows:

  

  L:\BuildDrop\Version\Etc\Core.wixlib

  

So I was hopeful that the Hintpath would be overridden by the user
reference path, but it is not the case.
So sadly the developers need to modify the .wixproj file when they are
doing development which is a bit more complicated and requires the file
to be checked out.
Is there any way to fix this, know any other way to do it or is it a
known bug?


Thanks,
Murray



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


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users