Re: [WiX-users] User changes to public properties lost during repair

[Krause, Henning]

Hi Thomas,

> I have an install file that presents a configuration dialog where users
> can enter database connection string information, which is used to
> update a connection string in a .config file.
> 
> 
> 
> It works quite well during the initial install. But during a repair
> install the data the user originally entered is lost, the corresponding
> public properties revert back to their default values (as specified in
> the original  tags), and those are written into the .config
> file.
> 
> The configuration dialog is never displayed during the repair.

MSI does not support this. You'll have to use a custom action to read the
values from the config file during maintenance. 

Kind regards,
Henning Krause


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

[WiX-users] User changes to public properties lost during repair

[Thomas Mulgrew]

Hello,

 

I'm new to WiX (and Windows Installer in general). I've hit an issue
that I cannot seem to solve with Google or help documents...

 

I have an install file that presents a configuration dialog where users
can enter database connection string information, which is used to
update a connection string in a .config file.

 

It works quite well during the initial install. But during a repair
install the data the user originally entered is lost, the corresponding
public properties revert back to their default values (as specified in
the original  tags), and those are written into the .config
file.

The configuration dialog is never displayed during the repair.

 

The relevant WiX looks like this:

 



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

 
xmlns:iis="http://schemas.microsoft.com/wix/IIsExtension";

 
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>

...

  

...



  



 

If I generate a log file, it simply lists the property as being equal to
its default value ("Property(S): DATABASEPORT = 1234).



Is there a way to get Windows Installer to remember what the user
entered from the original install?

 

-Tom Mulgrew



Attention:
This communication is confidential and may be legally privileged.  If you are 
not the intended recipient, please do not use, disclose, copy or distribute it, 
other than to return it to us with your confirmation that it has been deleted 
from your system.
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [OT] yep - back to being 100% frustrated

[Ian Thomas]

Since this conversation is going nowhere (perhaps because WiX is dependent
on MSI, and MSI seems to predicate most of the limitations) I would like to
introduce a tangent: whether other install / deployment / packaging
technologies have made an impact. 

How about Altiris Software Delivery Solution (now owned by Symantec)? 

I don't think it has changed since mid-2005, so I'm assuming it's had almost
no beneficial effect. 

 

  _  

Ian Thomas - Perth, Australia

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Josh Rowe
Sent: Wednesday, May 14, 2008 3:59 AM
Cc: WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated

 

Scott,

 

I actually agree with you.  Deployment SHOULD be trivial.  It's usually
risky and non-trivial because people tend to write programs that require
special steps during deployment.  By understanding the desired deployment
model up-front you reduce the tendency to write software that operates with
complex deployment models.  If you want a deployment model that is a simple
file copy, make sure your software doesn't require any more "registration"
and "deployment" activities than simple file copies.  Then, your WiX file
becomes a simple list of components and files, maybe a feature or two.  On
the other hand, if your deployment steps require a lot of registration,
feature choices, etc., those facts will be apparent from the increased
complexity of the source code that represents those deployment steps.  As
people modify the software, they are responsible for understanding how they
are changing the deployment model.

 

Every piece of software has a deployment model.  Somewhere, someone had to
decide how software should be structured, how third party products integrate
with a parent product, etc.  When the base platform you are installing onto
requires complicated deployment steps, I guess you're just screwed.
Especially when things come up like:

 

Icon files that are associated strictly with file extensions or CLSIDs can
have any extension, such as .ico. However, Icon files that are associated
with shortcuts must be in the EXE binary format and must be named such that
their extension matches the extension of the target. The shortcut will not
work if this rule is not followed. For example, if a shortcut is to point to
a resource having the key file Red.bar, then the icon file must also have
the extension .bar. Multiple icons can be stuffed into the same icon file as
long as all of the target files have the same extension.

 

I assume this is the madness you were referring to.  Probably, this has more
to do with how explorer works than with how MSI works, I don't really know.


 

I do think that it is pathetic to not consider a technology for the
development of an application because you can't write the installer for it.
But instead of blaming WiX or MSI, I blame the author of the technology.  If
the developer of that technology made good decisions about how to deploy
software that uses that technology, you wouldn't be forced into making those
hard choices.  For example, if COM+ registration was as simple as copying a
.xml file to a specific directory, deployment of COM+ applications would be
simple and none of us would be moaning about it.  But the authors of the
COM+ technology didn't consider how its clients would actually go about
deploying a COM+ application or a whole suite of COM+ applications.
Therefore, COM+ deployment sucks because MS didn't come up with a good story
for it, not because MSI or WiX didn't handle it.

 

This begs me to ask: why does the installer suck when people just wrote bad
software?  If all software followed simple file-based deployment models,
would MSI still suck?  I'm not sure that it would.  If explorer shortcut
files didn't use some crappy proprietary format would they be nearly as
difficult to get installed?  Probably not.  But the explorer team didn't
consider how deployments should work when writing explorer.  Of course,
hindsight is always 20/20, and it's really only recently that people are
really paying much attention to deployment of software as compared to
authoring it in the first place.  

 

For your own software: learn from MS's mistakes and don't write it the same
way.  

 

jmr

No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.16/1431 - Release Date: 5/13/2008
7:55 PM


BEGIN:VCARD
VERSION:2.1
N:Personal;ILT
FN:ILT Personal ([EMAIL PROTECTED])
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20070620T050625Z
END:VCARD
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Actions

[Blair Murri]

Administrative Installation
(http://msdn.microsoft.com/library/aa367541.aspx) is not directly related to
custom actions running with administrative privileges
(http://msdn.microsoft.com/library/aa368069.aspx).

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harini
Gurusamy
Sent: Monday, May 12, 2008 7:34 PM
To: Rob Mensching; Bob Arnson
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom Actions

 

Ok. So if want the exe to run on a admin command prompt, then setting
Impersonate=no a better option ?

From: Rob Mensching 
Sent: Monday, May 12, 2008 7:03 PM
To: Harini Gurusamy; Bob Arnson
Cc: wix-users@lists.sourceforge.net
Subject: RE: Custom Actions

 

Are you doing an admin install?  If not, you'll want the action in the
InstallExecuteSequence.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harini
Gurusamy
Sent: Monday, May 12, 2008 18:48
To: Bob Arnson
Cc: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom Actions

 

I am trying to execute a custom action during install as below. But the exe
never gets executed.

Any pointers ??

 


 

NOT Installed
 

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

Re: [WiX-users] Installshield decompiling

[Blair Murri]

The blog mentions bug 1581071:
http://sourceforge.net/tracker/index.php?func=detail&aid=1581071&group_id=10
5970&atid=642714

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Monday, May 12, 2008 1:16 PM
To: Jody Belka (WCS); wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Installshield decompiling

Is a bug open on this issue?  I try to keep up with what is going on in the
internet but we tend to focus our fixes on bugs that open in the bug
database for WiX on SourceForge.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jody Belka
(WCS)
Sent: Sunday, May 11, 2008 15:21
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installshield decompiling

I just tried to decompile an msi we produced using Installshield, and
hit the bug mentioned here:

http://skizz.biz/blog/2007/11/22/wix-bug-fix-for-importing-installshield-pro
ject-with-dark/

I was wondering if a fix for this will be making it into WiX sometime
soon? Or if there's any way around it other than building my own copy of
Dark?


J
--
Jody Belka
knew (at) pimb (dot) org

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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


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

Re: [WiX-users] Services depending on VC++ merge modules don't start on Vista

[Blair Murri]

2) If this is a known problem, I tried to skip starting services if the OS
is vista using


VersionNT = 600


but it do not respect the condition and it don't let start the services on
any OS. Is there something wrong with this configuration?


Suppress="yes" will cause it to remove that action in all cases (the
condition will be ignored) such that the action is no longer in the MSI at
all.

What I think you want is something more like this:


VersionNT < 600





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

[WiX-users] request to reboot doesn't reboot

[John Lalande]

During uninstallation of our product, the FilesInUse dialog appears (as
expected), the user clicks Ignore and at the end is prompted for a reboot.
However, if the user selects 'yes', the reboot does not occur.

Looking in the log there are many entries regarding files that need a reboot
to complete their removal.  The log finishes with 'Removal completed
successfully'.

In the system event log, there is the entry:
Event ID: 1005
The Windows Installer initiated a system restart to complete or continue the
configuration of 'Your Product 5.0'.

Is it possible the PC has a policy in place that prevents the reboot?  Or is
it the  way I have authored the installer?

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

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Justin Rockwood]

The long lines in VS 2005 has been around for a while. This is due to a bug in 
Visual Studio 2005 that was fixed in Visual Studio 2008. There are some ways 
around this bug, but none of them are pretty. We'll have to take another look 
at it and see what we can come up with.

 

Justin

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Tuesday, May 13, 2008 1:43 PM
To: Scott Palmer
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

 

Yeah, unfortunately “1200” == “one year”.  Okay, I’m going to kick Justin to go 
back and look at VS2005.  I’m more and more certain that behavior is regressing 
badly on that codebase and not being tested except by people picking up new 
drops.  I appreciate any bug fixes you can open and please do note if you're 
are using VS2005.

 

From: Scott Palmer [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 13, 2008 13:19
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

 

Yes, I am using VS2005.  The 2925 build on SourceForge works properly with the 
line endings.  That narrows it down to only around 1200 builds :-)

Regards,

Scott

On Tue, May 13, 2008 at 4:12 PM, Rob Mensching <[EMAIL PROTECTED]> wrote:

The line endings is a different bug that has been open for a long while.  
Again, I don't understand Visual Studio integration well enough to know what is 
causing this.

 

Are you by chance running on VS2005?  I'm beginning to think that because 
pretty much everyone working on WiX has moved to VS2008 that we're creating a 
huge number of regressions in VS2005.

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

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Justin Rockwood]

I hate the locking as well. Unfortunately, this is a bug in the MPF (the Visual 
Studio SDK) that they have not fixed yet. We will have to just fix it on our 
own instead of waiting for a fix from them. Note that it's not a trivial fix 
either because it requires a separate thread to do the build. That's not too 
bad, but then you have to jump through some hoops to communicate progress back 
to the UI thread and get the COM marshalling to work correctly with the Visual 
Studio shell. I worked on this for quite a bit way back in Votive 2.0 and 
didn't end up finding an adequate solution. I'm not saying there isn't a fix 
(there obviously is), it's just not an "easy" fix.

 

Justin

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Tuesday, May 13, 2008 1:10 PM
To: Scott Palmer
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

 

I know what you are saying here.  I don’t know enough about the Visual Studio 
architecture to understand why this happens but I’ll ask the guys working on 
Votive again. 

 

PS:  I know what is taking forever in light.exe, two things.  1.  Cabinet 
creation is I/O intensive and can take a while.  2.  ICE validation is very 
intensive.  ICE03 is the big offender and we’re still trying to determine if we 
can just turn ICE03 off and let light.exe do all of the same checks.  Verifying 
“conditional syntax” is still a problem.

 

From: Scott Palmer [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 13, 2008 12:37
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

 

I take it back 4102 crashes visual studio...  The huge lock ups I could 
tolerate... barely.

Why doesn't someone address the issue where running Light.exe locks up the 
entire dev environment (let alone bring the entire machine to  a crawl) for 
several minutes?  I always laugh at the little pop-up that says "Visual Studio 
is not responding.  If this happens frequently contact Microsoft." - Is always 
frequently enough?

Scott

On Tue, May 13, 2008 at 3:00 PM, Scott Palmer <[EMAIL PROTECTED]> wrote:

4102 works better.. though it still has problems with Light output.  The text 
description of errors is missing - you just get a code, and it's all on one 
line in visual studio.

Scott

 

On Tue, May 13, 2008 at 12:02 PM, Scott Palmer <[EMAIL PROTECTED]> wrote:

Cool thanks.

Another thing... I dropped in an older wix.targets file so I could do a build 
and noticed that output from Light didn't have the right line-endings.. 
everything showed up on one line in the dev studio output window..  The build 
was done and I didn't even know it because the message was *way* off to the 
right.

Regards,

Scott

 

On Tue, May 13, 2008 at 11:51 AM, Rob Mensching <[EMAIL PROTECTED]> wrote:

I just saw a bug get opened about the build targets having issues.  Try 4102 
and if that fixes the problem then you probably are seeing the same bug.  I'll 
make sure the bug gets fixed by the next build.

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer
Sent: Tuesday, May 13, 2008 08:31
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

 

I just updated WiX from the 2925 build (still the last "beta" posted to SF) to 
the May 9 weekly build 4109.   Now all of my WiX project don't build.  They 
don't even get started.  I instantly get this error when trying to build:

3>-- Build started: Project: Stream, Configuration: Release Any CPU --
3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error MSB4067: 
Done building project "MyInstallerProject.wixproj" -- FAILED.
3>
3>Build FAILED.

Reverting to build 3907 appears to fix the problem.

What am I doing wrong?

I searched the email list and didn't find MSB4067 anywhere.

Scott

 

 

 

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

Re: [WiX-users] Error 1937

[Rob Mensching]

The "HRESULT: " should provide a error code that details why it failed.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta 
(Volt)
Sent: Tuesday, May 13, 2008 14:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Error 1937

This is not WiX specific but this does happen to installs authored in WiX as 
well

If you search the web for "error 1937" you will see that there are many people 
out there encountering this error on many different products; including VS 
2008, MS Office, and .Net Framework. It happens at the very end of install and 
the same type of error message appears.

Does anyone have any experience with this? What is the cause? And most 
importantly... what is the solution?
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FragmentRef - Converting from WiX 2 to WiX 3

[Rob Mensching]

The WiX toolset creates references for you.  Likely you don't need the 
FragmentRefs at all.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Petersen
Sent: Tuesday, May 13, 2008 14:12
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FragmentRef - Converting from WiX 2 to WiX 3

Looking at converting to WiX 3 from WiX 2.

FragmentRef seems to be gone. I used these fairly extensively in V2. Most 
everything is in a Fragment and I pull everything together with the 
FragmentRefs. Any suggestions for the best way to proceed? I'm not sure what to 
substitute for those elements.  Or do I just need to remove them altogether? 
I'll try that and see what sort of error I get.

Anyone go through something like this?

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

[WiX-users] CLICK (RSVP to this invitation)TO READ YOUR MESSAGE INSIDE

[Phillipe Ouattara]

You are invited to "CLICK (RSVP to this invitation)TO READ YOUR MESSAGE INSIDE".


By your host Phillipe Ouattara:


 Date:  Tuesday May 13, 2008

 Time:  9:00 pm - 10:00 pm (GMT +00:00)

Will you attend? RSVP to this invitation at:

 
http://calendar.yahoo.com/phillipe_o3?v=126&a1=0&iid=ShAjhc3dhL3I%40AZjOhAUdF%40%40KeUwBPzX&igid=fx%40nMvh%40hMp4aHi3-hJGEXt%40vttcANu0epQMYh%40%40

Copyright © 2008 All Rights Reserved
 www.yahoo.com

Privacy Policy:
 http://privacy.yahoo.com/privacy/us

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

[WiX-users] Error 1937

[Don Tasanasanta (Volt)]

This is not WiX specific but this does happen to installs authored in WiX as 
well

If you search the web for "error 1937" you will see that there are many people 
out there encountering this error on many different products; including VS 
2008, MS Office, and .Net Framework. It happens at the very end of install and 
the same type of error message appears.

Does anyone have any experience with this? What is the cause? And most 
importantly... what is the solution?
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] FragmentRef - Converting from WiX 2 to WiX 3

[Chad Petersen]

Looking at converting to WiX 3 from WiX 2.

 

FragmentRef seems to be gone. I used these fairly extensively in V2.
Most everything is in a Fragment and I pull everything together with the
FragmentRefs. Any suggestions for the best way to proceed? I'm not sure
what to substitute for those elements.  Or do I just need to remove them
altogether? I'll try that and see what sort of error I get.

 

Anyone go through something like this?

 

Thanks

Chad

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

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Rob Mensching]

Yeah, unfortunately “1200” == “one year”.  Okay, I’m going to kick Justin to go 
back and look at VS2005.  I’m more and more certain that behavior is regressing 
badly on that codebase and not being tested except by people picking up new 
drops.  I appreciate any bug fixes you can open and please do note if you're 
are using VS2005.

From: Scott Palmer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 13:19
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

Yes, I am using VS2005.  The 2925 build on SourceForge works properly with the 
line endings.  That narrows it down to only around 1200 builds :-)

Regards,

Scott
On Tue, May 13, 2008 at 4:12 PM, Rob Mensching <[EMAIL PROTECTED]> wrote:

The line endings is a different bug that has been open for a long while.  
Again, I don't understand Visual Studio integration well enough to know what is 
causing this.



Are you by chance running on VS2005?  I'm beginning to think that because 
pretty much everyone working on WiX has moved to VS2008 that we're creating a 
huge number of regressions in VS2005.
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Scott Palmer]

Yes, I am using VS2005.  The 2925 build on SourceForge works properly with
the line endings.  That narrows it down to only around 1200 builds :-)

Regards,

Scott

On Tue, May 13, 2008 at 4:12 PM, Rob Mensching <[EMAIL PROTECTED]>
wrote:

>  The line endings is a different bug that has been open for a long while.
> Again, I don't understand Visual Studio integration well enough to know what
> is causing this.
>
>
>
> Are you by chance running on VS2005?  I'm beginning to think that because
> pretty much everyone working on WiX has moved to VS2008 that we're creating
> a huge number of regressions in VS2005.
>
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Rob Mensching]

The line endings is a different bug that has been open for a long while.  
Again, I don’t understand Visual Studio integration well enough to know what is 
causing this.

Are you by chance running on VS2005?  I’m beginning to think that because 
pretty much everyone working on WiX has moved to VS2008 that we’re creating a 
huge number of regressions in VS2005.

From: Scott Palmer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 09:03
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

Cool thanks.

Another thing... I dropped in an older wix.targets file so I could do a build 
and noticed that output from Light didn't have the right line-endings.. 
everything showed up on one line in the dev studio output window..  The build 
was done and I didn't even know it because the message was *way* off to the 
right.

Regards,

Scott
On Tue, May 13, 2008 at 11:51 AM, Rob Mensching <[EMAIL 
PROTECTED]> wrote:

I just saw a bug get opened about the build targets having issues.  Try 4102 
and if that fixes the problem then you probably are seeing the same bug.  I'll 
make sure the bug gets fixed by the next build.



From: [EMAIL PROTECTED] [mailto:[EMAIL 
PROTECTED]] On Behalf Of Scott Palmer
Sent: Tuesday, May 13, 2008 08:31
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?



I just updated WiX from the 2925 build (still the last "beta" posted to SF) to 
the May 9 weekly build 4109.   Now all of my WiX project don't build.  They 
don't even get started.  I instantly get this error when trying to build:

3>-- Build started: Project: Stream, Configuration: Release Any CPU --
3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error MSB4067: 
Done building project "MyInstallerProject.wixproj" -- FAILED.
3>
3>Build FAILED.

Reverting to build 3907 appears to fix the problem.

What am I doing wrong?

I searched the email list and didn't find MSB4067 anywhere.

Scott

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

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Rob Mensching]

I know what you are saying here.  I don’t know enough about the Visual Studio 
architecture to understand why this happens but I’ll ask the guys working on 
Votive again.

PS:  I know what is taking forever in light.exe, two things.  1.  Cabinet 
creation is I/O intensive and can take a while.  2.  ICE validation is very 
intensive.  ICE03 is the big offender and we’re still trying to determine if we 
can just turn ICE03 off and let light.exe do all of the same checks.  Verifying 
“conditional syntax” is still a problem.

From: Scott Palmer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 12:37
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

I take it back 4102 crashes visual studio...  The huge lock ups I could 
tolerate... barely.

Why doesn't someone address the issue where running Light.exe locks up the 
entire dev environment (let alone bring the entire machine to  a crawl) for 
several minutes?  I always laugh at the little pop-up that says "Visual Studio 
is not responding.  If this happens frequently contact Microsoft." - Is always 
frequently enough?

Scott

On Tue, May 13, 2008 at 3:00 PM, Scott Palmer <[EMAIL PROTECTED]> wrote:
4102 works better.. though it still has problems with Light output.  The text 
description of errors is missing - you just get a code, and it's all on one 
line in visual studio.

Scott


On Tue, May 13, 2008 at 12:02 PM, Scott Palmer <[EMAIL PROTECTED]> wrote:
Cool thanks.

Another thing... I dropped in an older wix.targets file so I could do a build 
and noticed that output from Light didn't have the right line-endings.. 
everything showed up on one line in the dev studio output window..  The build 
was done and I didn't even know it because the message was *way* off to the 
right.

Regards,

Scott

On Tue, May 13, 2008 at 11:51 AM, Rob Mensching <[EMAIL 
PROTECTED]> wrote:

I just saw a bug get opened about the build targets having issues.  Try 4102 
and if that fixes the problem then you probably are seeing the same bug.  I'll 
make sure the bug gets fixed by the next build.



From: [EMAIL PROTECTED] [mailto:[EMAIL 
PROTECTED]] On Behalf Of Scott Palmer
Sent: Tuesday, May 13, 2008 08:31
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?



I just updated WiX from the 2925 build (still the last "beta" posted to SF) to 
the May 9 weekly build 4109.   Now all of my WiX project don't build.  They 
don't even get started.  I instantly get this error when trying to build:

3>-- Build started: Project: Stream, Configuration: Release Any CPU --
3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error MSB4067: 
Done building project "MyInstallerProject.wixproj" -- FAILED.
3>
3>Build FAILED.

Reverting to build 3907 appears to fix the problem.

What am I doing wrong?

I searched the email list and didn't find MSB4067 anywhere.

Scott



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

Re: [WiX-users] yep - back to being 100% frustrated

[Josh Rowe]

Scott,

I actually agree with you.  Deployment SHOULD be trivial.  It's usually risky 
and non-trivial because people tend to write programs that require special 
steps during deployment.  By understanding the desired deployment model 
up-front you reduce the tendency to write software that operates with complex 
deployment models.  If you want a deployment model that is a simple file copy, 
make sure your software doesn't require any more "registration" and 
"deployment" activities than simple file copies.  Then, your WiX file becomes a 
simple list of components and files, maybe a feature or two.  On the other 
hand, if your deployment steps require a lot of registration, feature choices, 
etc., those facts will be apparent from the increased complexity of the source 
code that represents those deployment steps.  As people modify the software, 
they are responsible for understanding how they are changing the deployment 
model.

Every piece of software has a deployment model.  Somewhere, someone had to 
decide how software should be structured, how third party products integrate 
with a parent product, etc.  When the base platform you are installing onto 
requires complicated deployment steps, I guess you're just screwed.  Especially 
when things come up like:

Icon files that are associated strictly with file extensions or CLSIDs can have 
any extension, such as .ico. However, Icon files that are associated with 
shortcuts must be in the EXE binary format and must be named such that their 
extension matches the extension of the target. The shortcut will not work if 
this rule is not followed. For example, if a shortcut is to point to a resource 
having the key file Red.bar, then the icon file must also have the extension 
.bar. Multiple icons can be stuffed into the same icon file as long as all of 
the target files have the same extension.

I assume this is the madness you were referring to.  Probably, this has more to 
do with how explorer works than with how MSI works, I don't really know.

I do think that it is pathetic to not consider a technology for the development 
of an application because you can't write the installer for it.  But instead of 
blaming WiX or MSI, I blame the author of the technology.  If the developer of 
that technology made good decisions about how to deploy software that uses that 
technology, you wouldn't be forced into making those hard choices.  For 
example, if COM+ registration was as simple as copying a .xml file to a 
specific directory, deployment of COM+ applications would be simple and none of 
us would be moaning about it.  But the authors of the COM+ technology didn't 
consider how its clients would actually go about deploying a COM+ application 
or a whole suite of COM+ applications.  Therefore, COM+ deployment sucks 
because MS didn't come up with a good story for it, not because MSI or WiX 
didn't handle it.

This begs me to ask: why does the installer suck when people just wrote bad 
software?  If all software followed simple file-based deployment models, would 
MSI still suck?  I'm not sure that it would.  If explorer shortcut files didn't 
use some crappy proprietary format would they be nearly as difficult to get 
installed?  Probably not.  But the explorer team didn't consider how 
deployments should work when writing explorer.  Of course, hindsight is always 
20/20, and it's really only recently that people are really paying much 
attention to deployment of software as compared to authoring it in the first 
place.

For your own software: learn from MS's mistakes and don't write it the same way.

jmr


From: Scott Palmer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 2:58 PM
To: Josh Rowe
Cc: WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated

On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <[EMAIL PROTECTED]> wrote:


The moral of the story is that deployment procedures really are part of the 
source code for an application.  They are also risky, so implement them first 
to minimize risk.

This is the problem.  Deployment SHOULD be trivial.  That it is a "risky" part 
is outrageous.  Shouldn't the hard part be in your application's algorithms 
rather than how to install it?  (Your statement also ignores the fact that 
there is risk in other parts of the development - should those parts also be 
done first to minimize risk? :-) )

Saying it's risky is fine to justify the point that installers should be dealt 
with sooner in the development process - Given the current state of installer 
technology I must sadly agree.  But it belittles the fact that the installer 
technology sucks so bad and is the root problem that needs fixing.  Am I the 
only one that thinks it is somewhat pathetic to not consider a certain 
technology for the development of my application because I wont' be able to 
write the installer?  Doesn't that just say that A: the technology to be 
installed (e.g. COM+), and B: the installer techno

[WiX-users] Не пропустите!

[Афиша Москвы]

  МОСКВА ТЕАТРАЛЬНАЯ

495  517 83 08   495 202 86 89  
билеты, доставка
  
LADIES NIGHT. Мужская комедия для женщин -   19.05, 9, 16, 23.06  - В. 
ЯРЕМЕНКО, Г. КУЦЕНКО, М. БАШАРОВ,  Э. КЮРДЗИДИС ...Самый аншлаговый спектакль 
столицы...

1900-Й - НОВАЯ ПРЕМЬЕРА - В ГЛАВНОЙ РОЛИ ОЛЕГ МЕНЬШИКОВ -15,16 МАЯ

TOUT PAYE, ИЛИ ВСЕ ОПЛАЧЕНО (Ленком, О. ЯНКОВСКИЙ, И. ЧУРИКОВА, А. ЗБРУЕВ ) 
– 25, 31 мая  9,10,20,21июня

НОМЕР 13( МХАТ А.ЧЕХОВА,  Е.МИРОНОВ, Е.ЛЕОНТЬЕВ) - 16,  19.06

KYLIE MINOGE  " KYLIEX 2008" ( CК Олимпийский) - 16.06

ЮНОНА И АВОСЬ (Ленком, Д.ПЕВЦОВ, А.БОЛЬШОВА.) -17, 29.05 и 5,11,17,27.06

БЕСПРИДАННИЦА (Театр Мастерская П.ФОМЕНКО, ПРЕМЬЕРА) - 6,18,24,29.06. 
Действие происходит в большом городе Бряхимове на Волге в 1879 году. В 
спектакле звучат: русские
романсы,цыганские песни, незабываемые хиты

МАСТЕР И МАРГАРИТА (Театр наТаганке, легендарная постановка Ю.ЛЮБИМОВА) - 
23,30.05 и 8,18,27.06

СЛИШКОМ ЖЕНАТЫЙ ТАКСИСТ (Театр Сатиры, Ю. ВАСИЛЬЕВ, О.ВАВИЛОВ, А.ЯКОВЛЕВА) - 
17,27.05 И 5, 27.06

ТАРТЮФ (Ленком, Д.ПЕВЦОВ, А.ЗБРУЕВА, А.БОЛЬШОВА)  1,21.06

СЛУЖАНКИ  (Легендарный спектакль РОМАНА ВИКТЮКА)- 20.05 

ШУТ БАЛАКИРЕВ (Ленком, О.ЯНКОВСКИЙ, А.ЗБРУЕВ,  А.ЗАХАРОВА, С.ФРОЛОВ) -9,30.05 И 
3,4.06

МАМАПАПАСЫНСОБАКА (Современник, Ч.ХАМАТОВА в гл. роли) - 15.05 И 11.06

БЕЗУМНЫЙ ДЕНЬ ИЛИ ЖЕНИТЬБА ФИГАРО (Ленком, Д.ПЕВЦОВ, А.ЗАХАРОВА, А.ЛАЗАРЕВ) - 
16,21.05 И 16,20,26.06





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

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Scott Palmer]

I take it back 4102 crashes visual studio...  The huge lock ups I could
tolerate... barely.

Why doesn't someone address the issue where running Light.exe locks up the
entire dev environment (let alone bring the entire machine to  a crawl) for
several minutes?  I always laugh at the little pop-up that says "Visual
Studio is not responding.  If this happens frequently contact Microsoft." -
Is always frequently enough?

Scott


On Tue, May 13, 2008 at 3:00 PM, Scott Palmer <[EMAIL PROTECTED]> wrote:

> 4102 works better.. though it still has problems with Light output.  The
> text description of errors is missing - you just get a code, and it's all on
> one line in visual studio.
>
> Scott
>
>
>
> On Tue, May 13, 2008 at 12:02 PM, Scott Palmer <[EMAIL PROTECTED]> wrote:
>
> > Cool thanks.
> >
> > Another thing... I dropped in an older wix.targets file so I could do a
> > build and noticed that output from Light didn't have the right
> > line-endings.. everything showed up on one line in the dev studio output
> > window..  The build was done and I didn't even know it because the message
> > was *way* off to the right.
> >
> > Regards,
> >
> > Scott
> >
> >
> > On Tue, May 13, 2008 at 11:51 AM, Rob Mensching <
> > [EMAIL PROTECTED]> wrote:
> >
> > >  I just saw a bug get opened about the build targets having issues.
> > > Try 4102 and if that fixes the problem then you probably are seeing the 
> > > same
> > > bug.  I'll make sure the bug gets fixed by the next build.
> > >
> > >
> > >
> > > *From:* [EMAIL PROTECTED] [mailto:
> > > [EMAIL PROTECTED] *On Behalf Of *Scott Palmer
> > > *Sent:* Tuesday, May 13, 2008 08:31
> > > *To:* wix-users@lists.sourceforge.net
> > > *Subject:* [WiX-users] Did WiX V3 projects break compatibility with
> > > earlier builds?
> > >
> > >
> > >
> > > I just updated WiX from the 2925 build (still the last "beta" posted
> > > to SF) to the May 9 weekly build 4109.   Now all of my WiX project don't
> > > build.  They don't even get started.  I instantly get this error when 
> > > trying
> > > to build:
> > >
> > > 3>-- Build started: Project: Stream, Configuration: Release Any
> > > CPU --
> > > 3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error
> > > MSB4067: Done building project "MyInstallerProject.wixproj" -- FAILED.
> > > 3>
> > > 3>Build FAILED.
> > >
> > > Reverting to build 3907 appears to fix the problem.
> > >
> > > What am I doing wrong?
> > >
> > > I searched the email list and didn't find MSB4067 anywhere.
> > >
> > > Scott
> > >
> >
> >
>
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Scott Palmer]

4102 works better.. though it still has problems with Light output.  The
text description of errors is missing - you just get a code, and it's all on
one line in visual studio.

Scott


On Tue, May 13, 2008 at 12:02 PM, Scott Palmer <[EMAIL PROTECTED]> wrote:

> Cool thanks.
>
> Another thing... I dropped in an older wix.targets file so I could do a
> build and noticed that output from Light didn't have the right
> line-endings.. everything showed up on one line in the dev studio output
> window..  The build was done and I didn't even know it because the message
> was *way* off to the right.
>
> Regards,
>
> Scott
>
>
> On Tue, May 13, 2008 at 11:51 AM, Rob Mensching <
> [EMAIL PROTECTED]> wrote:
>
> >  I just saw a bug get opened about the build targets having issues.  Try
> > 4102 and if that fixes the problem then you probably are seeing the same
> > bug.  I'll make sure the bug gets fixed by the next build.
> >
> >
> >
> > *From:* [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED] *On Behalf Of *Scott Palmer
> > *Sent:* Tuesday, May 13, 2008 08:31
> > *To:* wix-users@lists.sourceforge.net
> > *Subject:* [WiX-users] Did WiX V3 projects break compatibility with
> > earlier builds?
> >
> >
> >
> > I just updated WiX from the 2925 build (still the last "beta" posted to
> > SF) to the May 9 weekly build 4109.   Now all of my WiX project don't
> > build.  They don't even get started.  I instantly get this error when trying
> > to build:
> >
> > 3>-- Build started: Project: Stream, Configuration: Release Any CPU
> > --
> > 3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error
> > MSB4067: Done building project "MyInstallerProject.wixproj" -- FAILED.
> > 3>
> > 3>Build FAILED.
> >
> > Reverting to build 3907 appears to fix the problem.
> >
> > What am I doing wrong?
> >
> > I searched the email list and didn't find MSB4067 anywhere.
> >
> > Scott
> >
>
>
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] yep - back to being 100% frustrated

[Scott Palmer]

On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <[EMAIL PROTECTED]> wrote:

>  
>
> The moral of the story is that deployment procedures really are part of
> the source code for an application.  They are also risky, so implement them
> first to minimize risk.
>

This is the problem.  Deployment SHOULD be trivial.  That it is a "risky"
part is outrageous.  Shouldn't the hard part be in your application's
algorithms rather than how to install it?  (Your statement also ignores the
fact that there is risk in other parts of the development - should those
parts also be done first to minimize risk? :-) )

Saying it's risky is fine to justify the point that installers should be
dealt with sooner in the development process - Given the current state of
installer technology I must sadly agree.  But it belittles the fact that the
installer technology sucks so bad and is the root problem that needs
fixing.  Am I the only one that thinks it is somewhat pathetic to not
consider a certain technology for the development of my application because
I wont' be able to write the installer?  Doesn't that just say that A: the
technology to be installed (e.g. COM+), and B: the installer technology
itself (e.g. MSI) both suck?

On a Mac you would just drag and drop the application icon. The very
existence of an installer is frowned upon for most things.  Why doesn't
Microsoft rip-off that instead of the desktop eye-candy? :-)

Isn't the goal of WiX to make creating MSI easier without giving up any of
it's raw abilities?  Should we really have to worry at the WiX level about
naming icon Ids with extensions that match what shortcuts that use them
point to?  That is just plain dumb and WiX should deal with that behind the
scenes for us.   Just like it deals with the insane requirement for 8.3
filenames (WiX V3).  Should I have to hack the component keys when I want to
use shortcuts in a simple install for ALL_USERS? No, WiX should handle that
too.

Regards,

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

[WiX-users] references of WIX 3

[Evan Kim]

Is there any manual or referece about WIX3?

I'm using version 2 now because there's tutorial and manual of it but I
couldn't find any for WIX3.


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

[WiX-users] Which version should I use.

[Reza Farzin]

Hello.

 

I am trying move out of InstallShield to Wix. I used Wix 2 about a year
ago however now I like to know which build should I use going forward.

 

I don't like to start using version 2 and in less than a year, upgrade
it to version 3. 

 

Cheers

 

Reza Farzin

Computer System Analyst

LiteScape

1000 Bridge Pkwy - Ste 200

Redwood Shores, CA 94065

 

 

 

Things should be made as simple as possible, but not any simpler.

-Albert Einstein

 

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

Re: [WiX-users] yep - back to being 100% frustrated

[Josh Rowe]

Agreed.

Software Engineering is many times about risk management.  Many projects leave 
understanding the deployment model of an application until just before it 
ships, and then because MSI often isn't well understood and the product wasn't 
written to work well with MSI people run into problems that cause the ship date 
to fall back because of an installer issue.

If you reverse it, and do the install up front, this allows you to make 
updating the installer a development responsibility and include the install in 
your integration test suite.  Doing an MSI integration test is trivially easy: 
just spawn the MSIEXEC.EXE process passing your .msi file and properties w/o a 
GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features MYPROPERTY=1 
MYOTHERPROPERTY=2 is what I'm using, I think).  Now, if a developer breaks the 
install, your automated tests should pick that up and that developer can fix it 
long before the ship date.

Re. COM+ etc, I ran into exactly that problem and ended up writing a whole CA 
system in MSI to deploy our 20+ COM+ applications at my last job.  It took 
weeks of effort to write deployment operations for our applications.  We 
started with .vbs and .zip files, but soon progressed to needing the full 
functionality of MSI.  It turns out that MSI really is quite simple, as long as 
you work within what it does well from the beginning rather than trying to 
back-port your existing application to be installed via MSI.  We would have 
chosen a different software model that would have cost a little more coding 
time but a lot less deployment effort time if we had spent the time to 
understand the deployment model up front.

The moral of the story is that deployment procedures really are part of the 
source code for an application.  They are also risky, so implement them first 
to minimize risk.

jmr


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Tuesday, May 13, 2008 12:51 PM
To: Scott Palmer; WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated

As this was my comment I thought I should respond.

>"I believe you should write the install then the code - if you can't install 
>it, don't code it."

>>That's simply not the way it works, and that isn't going to change.  I get 
>>where you are coming from though... the general installation layout of the 
>>product does need to be >>understood sooner rather than later.  The reason 
>>that the installer isn't "done first" or in parallel with other development 
>>is simple - everyone hates it.  Getting anyone to do it >>is like pulling 
>>teeth.  Nobody on the team wants to be the "installer guy", for good reason. 
>>(There is also the fact that it is intuitively backwards to write an 
>>installer for >>something that doesn't exist yet.)
I like doing installs!

I know it is a bit flippant to say write the install first but in my experience 
no one considers the install when choosing the latest and greatest development 
code. If they did (and I feel Microsoft is to blame here) they wouldn’t touch a 
lot of the technologies. COM+ was never properly supported for installs, moving 
up to date some of the WFP stuff is incredibly completed to configure. SQL 
server it still not properly scriptable without writing you own code.

I don’t think it is intuitively backwards to write an installer first – my 
analogy is – hydrogen powered cars might be a good idea but if you can’t buy 
hydrogen or aren’t going to put the infrastructure in place there is no point 
building them. I think the same is true of code, make sure you can deploy it 
before you write any code. Together we can make it happen ☺

Neil

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]


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

Re: [WiX-users] yep - back to being 100% frustrated

[Neil Sleightholm]

As this was my comment I thought I should respond.

 

>"I believe you should write the install then the code - if you can't install 
>it, don't code it."

>>That's simply not the way it works, and that isn't going to change.  I get 
>>where you are coming from though... the general installation layout of the 
>>product does need to be >>understood sooner rather than later.  The reason 
>>that the installer isn't "done first" or in parallel with other development 
>>is simple - everyone hates it.  Getting anyone to do it >>is like pulling 
>>teeth.  Nobody on the team wants to be the "installer guy", for good reason. 
>>(There is also the fact that it is intuitively backwards to write an 
>>installer for >>something that doesn't exist yet.)



I like doing installs!

 

I know it is a bit flippant to say write the install first but in my experience 
no one considers the install when choosing the latest and greatest development 
code. If they did (and I feel Microsoft is to blame here) they wouldn’t touch a 
lot of the technologies. COM+ was never properly supported for installs, moving 
up to date some of the WFP stuff is incredibly completed to configure. SQL 
server it still not properly scriptable without writing you own code.

 

I don’t think it is intuitively backwards to write an installer first – my 
analogy is – hydrogen powered cars might be a good idea but if you can’t buy 
hydrogen or aren’t going to put the infrastructure in place there is no point 
building them. I think the same is true of code, make sure you can deploy it 
before you write any code. Together we can make it happen J

 

Neil

 

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]

 

 

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

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Scott Palmer]

Cool thanks.

Another thing... I dropped in an older wix.targets file so I could do a
build and noticed that output from Light didn't have the right
line-endings.. everything showed up on one line in the dev studio output
window..  The build was done and I didn't even know it because the message
was *way* off to the right.

Regards,

Scott

On Tue, May 13, 2008 at 11:51 AM, Rob Mensching <[EMAIL PROTECTED]>
wrote:

>  I just saw a bug get opened about the build targets having issues.  Try
> 4102 and if that fixes the problem then you probably are seeing the same
> bug.  I'll make sure the bug gets fixed by the next build.
>
>
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Scott Palmer
> *Sent:* Tuesday, May 13, 2008 08:31
> *To:* wix-users@lists.sourceforge.net
> *Subject:* [WiX-users] Did WiX V3 projects break compatibility with
> earlier builds?
>
>
>
> I just updated WiX from the 2925 build (still the last "beta" posted to
> SF) to the May 9 weekly build 4109.   Now all of my WiX project don't
> build.  They don't even get started.  I instantly get this error when trying
> to build:
>
> 3>-- Build started: Project: Stream, Configuration: Release Any CPU
> --
> 3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error
> MSB4067: Done building project "MyInstallerProject.wixproj" -- FAILED.
> 3>
> 3>Build FAILED.
>
> Reverting to build 3907 appears to fix the problem.
>
> What am I doing wrong?
>
> I searched the email list and didn't find MSB4067 anywhere.
>
> Scott
>
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Rob Mensching]

I just saw a bug get opened about the build targets having issues.  Try 4102 
and if that fixes the problem then you probably are seeing the same bug.  I’ll 
make sure the bug gets fixed by the next build.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer
Sent: Tuesday, May 13, 2008 08:31
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Did WiX V3 projects break compatibility with earlier 
builds?

I just updated WiX from the 2925 build (still the last "beta" posted to SF) to 
the May 9 weekly build 4109.   Now all of my WiX project don't build.  They 
don't even get started.  I instantly get this error when trying to build:

3>-- Build started: Project: Stream, Configuration: Release Any CPU --
3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error MSB4067: 
Done building project "MyInstallerProject.wixproj" -- FAILED.
3>
3>Build FAILED.

Reverting to build 3907 appears to fix the problem.

What am I doing wrong?

I searched the email list and didn't find MSB4067 anywhere.

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

Re: [WiX-users] installing services with wix

[Robert.Priest]

Checkout the  and  elements.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Willie
Burton
Sent: Tuesday, May 13, 2008 11:29 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] installing services with wix

 

Is there a way besides using a custom action to do this?

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

[WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Scott Palmer]

I just updated WiX from the 2925 build (still the last "beta" posted to SF)
to the May 9 weekly build 4109.   Now all of my WiX project don't build.
They don't even get started.  I instantly get this error when trying to
build:

3>-- Build started: Project: Stream, Configuration: Release Any CPU
--
3>C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(978,7)Error
MSB4067: Done building project "MyInstallerProject.wixproj" -- FAILED.
3>
3>Build FAILED.

Reverting to build 3907 appears to fix the problem.

What am I doing wrong?

I searched the email list and didn't find MSB4067 anywhere.

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

Re: [WiX-users] To Prevent Install on Windows 2008

[Rob Mensching]

How about "MsiNTProductType" or some of the other MsiNTXXX properites?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anidil
Sent: Tuesday, May 13, 2008 00:31
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] To Prevent Install on Windows 2008


I have an MSI that is intended for Only Vista and Vista SP1.Can anybody give
me some hints to prevent install on Windows 2008? I have tried the following
condition but it doesn't work
WindowsBuild = 6000 OR WindowsBuild =
6001 AND ServicePackLevel = 1

NB: For Windows 2008 and Vista SP1,VersionNT and WindowsBuild numbers are
600 and 6001 respectively
--
View this message in context: 
http://www.nabble.com/To-Prevent-Install-on-Windows-2008-tp17202645p17202645.html
Sent from the wix-users mailing list archive at Nabble.com.


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

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

Re: [WiX-users] yep - back to being 100% frustrated

[Scott Palmer]

Well I dropped by to ask for help (I wonder if I will get it now :-)) but
first I have to chime in and agree with Chris and Mark.  I dislike that what
I am about to post is basically a rant, but I think there are a lot more
people on their side than others seem to think, so I want to show my
support.

Rob, it's worse than assembly... I can handle assembly, it's just low level,
there is still logic and order to it (well, less so with Intel.. but
still).Many of the statements in this thread defending WiX demonstrates
to me how out of touch some people (the development team?) are with the
needs of the users.  Of course the fact that MSI sucks beyond belief isn't
the fault of WiX.  That WiX does so little to remedy the situation is
something that can be addressed though.  If it wasn't a "design goal" one
wonders why?  Your #3 - "being very cautious" is valid of course... but
there is a very strong need to "automagically fix things" because what
you've got with MSI is a REALLY big mess.

I still laugh that short filenames are required in what is labelled as
version 2... that is so far off the mark.  I've even seen comments relating
to V3 (where short filenames were addressed) that go something like
"apparently some developers found that useful" maybe I missed the sarcasm,
but it seemed as if the WiX development team didn't get how brain dead the
short filenames were in the first place?  Keeping short filenames around at
all has got to be one of Microsoft's biggest blunders, the fact that MSI
only runs on systems that support long filenames adds to the pain.  I still
to this day am dumbfounded that anyone uses WiX V2, they are masochists I
guess.

(comments below are referring to other messages, not Rob's that I have
quoted at the bottom)

>> 2. learn how to write custom dialogs and use them liberally

>Use custom dialogs only when needed; most projects don't need them.

So very wrong.  They are needed.. in my experience, almost always.  In the
cases where you don't need them, you usually don't even need an installer at
all - though I think all software on Windows should require an installer
that is properly integrated into the Add/Remove programs database before the
system will even run it.  It would probably plug a few user vulnerabilities
in a much friendlier way than the Vista disaster, It's just not practical
because of the difficulty in making a proper installer - a fault of MSI.

>"My critisism does not come from the frustration of being stuck. It does
come from realization, once it was solved, how complicated even the simplest
task was!"

Full agreement here.  We have a team of very bright developers.. and all of
them stare in disbelief at what needs to be done for the installer. When I
have to seriously struggle with the decision to write an installer framework
from scratch or suffer though the poorly thought out crap that is available
already - something is wrong.  I choose to suffer through MSI because it
appears to be "the right way to install software on Windows" - why else is
it "built-in"?

We moved to WiX because the other products like Install Shield/Install
Anywhere were too narrow and only worked well for the most trivial installs
- and they were severely overpriced for that.  Hearing that internal
projects at Microsoft were using WiX gave us some confidence in it.

I do need to re-state that I realize most of the pain points with WiX are
because of the complete rubbish that WiX has to work with - MSI.  MSI is so
filled with seemingly arbitrary restrictions and odd-ball requirements.
Simple things like getting icons to work properly for example are needlessly
encumbered with nonsensical requirements.   That's a perfect example of
something WiX could "fix" but doesn't.   Another example is the simple task
of  getting the "back" button to work in a UI if you need a few custom
dialogs (with some of them conditionally shown).  That the end user EVER has
to code the logic for the back button is ridiculous.  I realize that the way
MSI does UIs is much lower level, that having a back button at all isn't a
requirement of MSI... but be practical - handling the common case of having
the back button is a good thing and doesn't need to interfere with anyone
that chooses to slap some odd-ball UI on their installer.

I think the WiX development team underestimates the number of professional,
top-end developers that are stunned with how crappy doing an installer for
Windows is.  I've never met a single developer that isn't flabbergasted at
the hoops you need to jump through to do the simplest things.

>"I believe you should write the install then the code - if you can't
install it, don't code it."

That's simply not the way it works, and that isn't going to change.  I get
where you are coming from though... the general installation layout of the
product does need to be understood sooner rather than later.  The reason
that the installer isn't "done first" or in parallel with other development
is simple - 

[WiX-users] installing services with wix

[Willie Burton]

Is there a way besides using a custom action to do this?

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

Re: [WiX-users] To Prevent Install on Windows 2008

[Tony Hoyle]

Anidil wrote:
> I have tried that but still it's not preventing install on Windows 2008..
> 
Windows 2008 is the identical kernel to Vista SP1 (in fact Win2008 makes 
a great client OS for development - Vista without the cruft.. several 
people here have switched to it already).

There should be no reason to install on one but not the other, even for 
device drivers... but I'm sure something could be put together (might 
need a CA for it though).

Tony

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

[WiX-users] You have been caught spamming

[Naresh]

Check out the amazing shots taken by these paparazzi http://www.cosatenal.com/

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

[WiX-users] Создание сплоченной команды

[Устранить сложности общения]

ТРЕНИНГОВАЯ КОМПАНИЯ 
МОСКОВСКИЙ ЦЕНТР 
ВЗАИМООТНОШЕНИЙ 

Психологические и бизнес-тренинги, курсы, семинары, детские лагеря, 
индивидуальные консультации, системные расстановки. Создание тренингов для 
организаций с учётом специфики деятельности. 
Подробная информация о компании по телефонам 514-8870, 518-4547, 8-903- 
766-7204 

Приносим свои извинения, если эта информация Вам не нужна. 

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

[WiX-users] Выход из Управления

[Владелец Компании]

Выход собственника из оперативного управления компанией
03-04 июня, Москва, эксклюзивный семинар-практикум


Может ли собственник без последствий для бизнеса:

- Передать управление наемному менеджеру?
- Продать компанию?
- Заняться новым бизнесом?


В программе:
Кризис ролей владельца и управляющего
Как топ-менеджеры обманывают и манипулируют собственниками
Проблема "прозрачности" бизнеса для владельца
Практические схемы и технологии построения оптимальной системы 
управления
Как найти, мотивировать и контролировать наёмного управляющего
Система контроля за собственным бизнесом "изнутри" и "снаружи"
Как заставить топ-менеджмент работать на владельца как "на себя"
Бонусы, опционы, акции и другие методы мотивации топ-менеджмента
Когда и как собственнику уходить из управления: успешный российский 
опыт
По всем вопросам обращайтесь по тел: ((495)) 5O8=б2Ч5, 8 ((9I5)) 3б2=78б1
или [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Таможенное оформление в 2008 г

[Все о экспорте и импорте товаров]

   Вниманию Участников ВЭД всё о экспорте и импорте товаров в 2OO8 г. 
 4-6 июня 2OO8 г. 
 Новое во внешнеторговой сделке и ее таможенном оформление в 2OO8 г. 
 В семинаре принимают участия специалисты из  Российской Таможенной Академии, 
ФТС России, Отдела таможенных режимов ЦАТ. 
 04 06 08.Договорное оформление внешнеэкономической сделки. 
 Внешнеторговые операции: виды, организация и основные этапы 
.Нормативно-правовое регулирование внешнеторговых сделок Практика и особенности 
составления внешнеторгового контракта в соответствии с ГК РФ и международными 
нормами. Базисные условия поставки. Использование ИНКОТЕРМС. Анализ типичных 
ошибок, допускаемых участниками ВЭД при заключении и исполнении контракта, и 
определение их влияния на процесс таможенного оформления. Особенности 
оформления различных видов сделок Основные условия и особенности составления 
различных договоров. 
 05 06 08Таможенная стоимость товаров, перемещаемых через таможенную границу 
России. 
 Определение таможенной стоимости товаров. 
Система методов определения таможенной стоимости. Структура таможенной 
стоимости (налоговой базы). Цена внешнеторговой сделки. Выбор метода 
определения таможенной стоимости Влияние базисных условий поставки на структуру 
таможенной стоимости. Порядок определения таможенной стоимости товаров. 
 Заявление таможенной стоимости товаров .  Требования к представлению и 
заполнению ДТС. Правила заполнения ДТС Практические примеры заполнения 
декларации таможенной стоимости.
 Контроль таможенной стоимости. 
Действия декларанта в случае не принятия таможенным органом заявленной 
декларантом таможенной стоимости. Система управления рисками при осуществлении 
контроля таможенной стоимости. Правила заполнения форм корректировки таможенной 
стоимости вразличных случаяхПрактические примеры заполнения форм КТС-1,КТС-2. 
 Актуальные вопросы правоприменительной практики. Ответы на вопросы слушателей. 
 06 04 08 Актуальные проблемы таможенного оформления в 2008 г. 
 Изменения в таможенном законодательстве, вступившие в силу с 01.01.2OO8г., и 
регламентирующие виды деятельности в области таможенного дела : владельцев 
складов временного хранения и владельцев таможенных складов; таможенных 
брокеров; таможенных перевозчиков. 
Изменения в порядке заполнения грузовой таможенной декларации, внесенные 
Приказом ФТС России. 
Порядок установления специальных упрощенных процедур таможенного оформления для 
отдельных лиц. 
 Выбор и изменение таможенных режимов. Особенности применения таможенных 
платежей в различных таможенных режимах. 
 Стоимость участия в семинаре 15 200 (в том числе Н Д С) . 
 По окончании семинара выдается сертификат. 
 Проезд г. Москва м. Рижская, УЦБА 
 Звоните: /Ч 9 5/ 5О 63 О7 8, 7Ч I87 O5 
 Иногородним предлагается гостиница. 
   
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] To Prevent Install on Windows 2008

[Anidil]

I have tried that but still it's not preventing install on Windows 2008..


Holmgren Mathias wrote:
> 
> Example:  
> 
>  VersionNT = 600 AND
> ServicePackLevel >= 1
> 
> For more, see this link:
> http://msdn.microsoft.com/en-us/library/aa370556(VS.85).aspx
> 
>  
> 
>  
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anidil
> Sent: den 13 maj 2008 09:31
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] To Prevent Install on Windows 2008
> 
>  
> 
>  
> 
> I have an MSI that is intended for Only Vista and Vista SP1.Can anybody
> give
> 
> me some hints to prevent install on Windows 2008? I have tried the
> following
> 
> condition but it doesn't work
> 
> WindowsBuild = 6000 OR WindowsBuild =
> 
> 6001 AND ServicePackLevel = 1
> 
>  
> 
> NB: For Windows 2008 and Vista SP1,VersionNT and WindowsBuild numbers
> are
> 
> 600 and 6001 respectively
> 
> -- 
> 
> View this message in context:
> http://www.nabble.com/To-Prevent-Install-on-Windows-2008-tp17202645p1720
> 2645.html
> 
> Sent from the wix-users mailing list archive at Nabble.com.
> 
>  
> 
>  
> 
> 
> -
> 
> This SF.net email is sponsored by: Microsoft 
> 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> 
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> 
> ___
> 
> WiX-users mailing list
> 
> WiX-users@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> -
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/To-Prevent-Install-on-Windows-2008-tp17202645p17203835.html
Sent from the wix-users mailing list archive at Nabble.com.


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

Re: [WiX-users] To Prevent Install on Windows 2008

[Holmgren Mathias]

Example:  

 VersionNT = 600 AND
ServicePackLevel >= 1

For more, see this link:
http://msdn.microsoft.com/en-us/library/aa370556(VS.85).aspx

 

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anidil
Sent: den 13 maj 2008 09:31
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] To Prevent Install on Windows 2008

 

 

I have an MSI that is intended for Only Vista and Vista SP1.Can anybody
give

me some hints to prevent install on Windows 2008? I have tried the
following

condition but it doesn't work

WindowsBuild = 6000 OR WindowsBuild =

6001 AND ServicePackLevel = 1

 

NB: For Windows 2008 and Vista SP1,VersionNT and WindowsBuild numbers
are

600 and 6001 respectively

-- 

View this message in context:
http://www.nabble.com/To-Prevent-Install-on-Windows-2008-tp17202645p1720
2645.html

Sent from the wix-users mailing list archive at Nabble.com.

 

 


-

This SF.net email is sponsored by: Microsoft 

Defy all challenges. Microsoft(R) Visual Studio 2008. 

http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

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

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

[WiX-users] Installing IIS via windows installer

[John Daintree]

Hello all,

Is it possible to install IIS (ie one of the "standard" Windows Components) 
via WIX/Windows installer?

Thanks,

John. 


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

[WiX-users] To Prevent Install on Windows 2008

[Anidil]

I have an MSI that is intended for Only Vista and Vista SP1.Can anybody give
me some hints to prevent install on Windows 2008? I have tried the following
condition but it doesn't work
WindowsBuild = 6000 OR WindowsBuild =
6001 AND ServicePackLevel = 1

NB: For Windows 2008 and Vista SP1,VersionNT and WindowsBuild numbers are
600 and 6001 respectively
-- 
View this message in context: 
http://www.nabble.com/To-Prevent-Install-on-Windows-2008-tp17202645p17202645.html
Sent from the wix-users mailing list archive at Nabble.com.


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