Windows Installer XML (WiX) toolset › wix-users

yep - back to being 100% frustrated

41 messages

1 2 3

Scott Palmer-3

Re: yep - back to being 100% frustrated

Reply Threaded

We all knew this thread was going nowhere from the first post of course...

My only point was that (in my experience) the original posters frustration is shared by the vast majority of developers trying to do installers on Windows. (i.e. everyone I know that has ever seen or worked on a WiX project)
Anything that can be done by WiX to ease these pain points is therefore justified by the vast payoff in improved productivity around the globe :-)

They solved the 8.3 filename issue in WiX V3.. I believe they can do more.

Regards,

Scott

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

Josh Rowe

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by chrpai

Some javascript/style in this post has been disabled (why?)

Actually, I'm not saying that at all. I'm just suggesting that these problems should be solved up front because they are difficult to solve. I'm also saying that by trying to solve deployment problems up front you may be able to successfully influence the architecture of an application to not include technologies that are ultimately difficult to use. If you wait to solve these problems until the last possible second then you will not be able to successfully influence the architecture of an "already-implemented", "working" solution. The key point is that the deployment of a solution is very much part of the solution itself, and if that happens to be the risky part of a project then it should be tackled first. That's just good project / risk management.

If you want to influence an upstream "architect", you have to do so before the software has solidified. If you believe strongly enough that MSI or deployment in general is difficult, you should work on that part of the project first with one goal to influence the design to be easily deployable.

When you don't have a choice, do what Christopher Painter says. I've had to write CAs for MSI, too. Because of those experience, when given the choice of writing CAs or changing the software to not require the CAs, I change the software.

jmr

From: [hidden email] [mailto:[hidden email]] On Behalf Of Christopher Painter
Sent: Wednesday, May 14, 2008 10:06 AM
To: Neil Sleightholm; [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

I think they are. Everytime you hear things like `solve the applicartion problem`, `custom actions are an admission of failure`, `we won't implement that feature`, `There are few setup experiences more stable than an application that simply needs a bunch of files installed`, I believe that very notion is being implied.

On one hand I understand why you'd say it, and in theory I agree with it. But in practice it's not possible. The reality is even if you are lucky enough to be in a shop where the developers/architects believe that their design choices should be guided by integration ( read build/install ) implications, they rarely have the specialized domain knowledge to know what those implications are because they usually never touched a build or an install while they were cutting their programming teath. Setup is rarely taught, it's not included in books, it's not included in certifications and if you offer up a lecture at work or at a code camp you won't get anyone to come. The reality is they are much more interested in discussing the merits of the latest new thing. ( Agile, Scrum, ALT.NET, WCF, WPF, SliverLight, DSL's are very popular topics at my local DNUG ... no one is interested in MSI ).

So from my perspective, I try to influence upstream design decisions but when it doesn't happen the way I'd like, I do what all good Marines do: Adapt and Overcome.

Neil Sleightholm <[hidden email]> wrote:

>>In any reasonably professional shop you can't just say "hey, MSI doesn't
>>support doing that, we just can't have that in our application!".

I don't think anyone was suggesting that but if you new it would need a custom action, for example, you could either not do it that way or schedule in writing one.

Neil

Neil Sleightholm
X2 Systems Limited
[hidden email]

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

chrpai

Re: yep - back to being 100% frustrated

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Very good points and I agree with you. Unfortunatly in my experience it's almost always too late to do the upstream influencing and fixing. I've been writing setup since 1996. In those 12 years I've held around a dozen positions with various companies and completed dozens of additional projects on the side. With only a couple exceptions, every project that I've been invited to work on was very late in the project life cycle.

Sure, I'd love to sit in part time on a bunch of project startups and provide guidance so that from build 1 they were on course for an easy deployment but the reality is limiting my engagements to those parameters won't get my mortgage paid. The `help, we need to deploy and we are screwed` customers knock a lot harder and more often. It's in both of ours best interest to service them with cost effective tools that enable me to adapt and overcome the problems that shouldn't exist and yet do.

Josh Rowe <[hidden email]> wrote:

Actually, I'm not saying that at all. I'm just suggesting that these problems should be solved up front because they are difficult to solve. I'm also saying that by trying to solve deployment problems up front you may be able to successfully influence the architecture of an application to not include technologies that are ultimately difficult to use. If you wait to solve these problems until the last possible second then you will not be able to successfully influence the architecture of an "already-implemented", "working" solution. The key point is that the deployment of a solution is very much part of the solution itself, and if that happens to be the risky part of a project then it should be tackled first. That's just good project / risk management.

If you want to influence an upstream "architect", you have to do so before the software has solidified. If you believe strongly enough that MSI or deployment in general is difficult, you should work on that part of the project first with one goal to influence the design to be easily deployable.

When you don't have a choice, do what Christopher Painter says. I've had to write CAs for MSI, too. Because of those experience, when given the choice of writing CAs or changing the software to not require the CAs, I change the software.

jmr

From: [hidden email] [mailto:[hidden email]] On Behalf Of Christopher Painter
Sent: Wednesday, May 14, 2008 10:06 AM
To: Neil Sleightholm; [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

I think they are. Everytime you hear things like `solve the applicartion problem`, `custom actions are an admission of failure`, `we won't implement that feature`, `There are few setup experiences more stable than an application that simply needs a bunch of files installed`, I believe that very notion is being implied.

On one hand I understand why you'd say it, and in theory I agree with it. But in practice it's not possible. The reality is even if you are lucky enough to be in a shop where the developers/architects believe that their design choices should be guided by integration ( read build/install ) implications, they rarely have the specialized domain knowledge to know what those implications are because they usually never touched a build or an install while they were cutting their programming teath. Setup is rarely taught, it's not included in books, it's not included in certifications and if you offer up a lecture at work or at a code camp you won't get anyone to come. The reality is they are much more interested in discussing the merits of the latest new thing. ( Agile, Scrum, ALT.NET, WCF, WPF, SliverLight, DSL's are very popular topics at my local DNUG ... no one is interested in MSI ).

So from my perspective, I try to influence upstream design decisions but when it doesn't happen the way I'd like, I do what all good Marines do: Adapt and Overcome.

Neil Sleightholm <[hidden email]> wrote:

>>In any reasonably professional shop you can't just say "hey, MSI doesn't
>>support doing that, we just can't have that in our application!".

I don't think anyone was suggesting that but if you new it would need a custom action, for example, you could either not do it that way or schedule in writing one.

Neil

Neil Sleightholm
X2 Systems Limited
[hidden email]

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

Markus Kuehni

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Josh Rowe

Some javascript/style in this post has been disabled (why?)

I just wanted to add that some of us had working installers before. In our case this goes back to a fossil InstallShield v3 script based solution. The only reason we're really forced to replace it, is because it contains 16bit bootstrapper code, can you belive it ;-)

All the real deployment problems were already solved and working using this antique technology. The latest version even supported Vista and respected all (relevant) guidelines. So I can kind of prove it was by no means a problem of our application, ever.

Granted there was no repair option, no change option, and just rudimentary rollback in case of failure. But that was never a big problem for us in many years.

Not even in my worst nightmare did I anticipate, what changing over to MSI really meant....

_Mark

Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Josh Rowe
Gesendet: Mittwoch, 14. Mai 2008 17:30
An: [hidden email]
Betreff: Re: [WiX-users] yep - back to being 100% frustrated

jmr

So from my perspective, I try to influence upstream design decisions but when it doesn't happen the way I'd like, I do what all good Marines do: Adapt and Overcome.

Neil Sleightholm <[hidden email]> wrote:

>>In any reasonably professional shop you can't just say "hey, MSI doesn't
>>support doing that, we just can't have that in our application!".

I don't think anyone was suggesting that but if you new it would need a custom action, for example, you could either not do it that way or schedule in writing one.

Neil

Neil Sleightholm
X2 Systems Limited
[hidden email]

jmcfadyen

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Scott Palmer-3

It seems to me reading this from a link via Christopher Painter that you guys are all missing a few vital points.

It looks to me like most of you looking at this as Dev's which is where you are going wrong. I agree these items should be trivial to fix but there is a vast number of regions outside of the development sphere which are the reason it is not. I feel some of you need to take your blinkers off and see what is really the big picture here.

Windows Installer is complex it is difficult to get decent information on but there are very valid reasons why its so difficult and most of them extend outside the realm of the developer developing a piece of software for his single little machine.

Windows Installer caters for a massive array of issues problems operating systems, and integrates the entire setup not only for your little application but is designed to integrate hundred/thousands of applications developed by hundreds/thousands of developers onto multiple platforms. There is a much bigger picture at work here.

I think the guys at MS have done a great job. I could say vbscript is a great programming language and that C# or F# is crap when the reality is my understanding of them may not be as good as some of you guys here. Most of you would look at me like I was mental or something but the reality is many of you are looking at this with the same mentality.

I have been using windows installer since its inception and these days I find little that it cant do with a tiny bit of brute force. Don't blame the tools as there are plenty of people out there using these tools and making them work seemlessly and quickly on a day to day basis.

Each day I integrate around 1,000,000 lines of code into multiple msi's within minutes using WiX. (I couldnt care less what its written in, if you know how to use it as it was designed it works like a charm).

If anyone would like some assistance understanding the finer intricacies of windows installer I have some heavy detail on most of the undocumented features here.

http://john.mcfadyen.spaces.live.com

No offence intended to anyone on these boards, this post is not aimed at being nasty and I hope my blog can aid with some of your troubles.

Scott Palmer-3 wrote:

On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <Josh.Rowe@dynamicops.com> wrote:

> <snip>
>
> 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/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Holmgren Mathias

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Chris Mumford-2

Some javascript/style in this post has been disabled (why?)

> Don't blame the tools as there are plenty of people out there using these tools and making them work seemlessly and quickly on a day to day basis.

Well, you can’t just disregard the large majority of people who are struggling a lot with this. And you can’t disregard the “developer perspective”, because developers are the people that have to deal with this.

Sure, one part of the story is about expectations and the learning curve of installation. Before building an installation package, you expect it to be pretty easy, like a couple of days work. Then when you start doing it you find out that the level of investment necessary to complete a working real world installer is not 10 but maybe 100 times greater than what you expected, or more (yes, for real, I’m not making this up). And we are talking very experienced people here, not rookie devs.

Having to invest your time so heavily to get so little tangible result back is a shock to most people. And when all the bumps, twists and turns of the technology are added on top of that learning process there will be frustration.

Now, I’m not much for nursing cry baby mentality either. It will get you nowhere. But I do feel that there is a case to be made here about not putting up with things that are overburdening. This is the other part of the story.

If the tools can be improved to make installation simpler, why settle for less?

Or are installer technology and the tools already as good as they can ever become?

No. Identify the stuff that can be made easier with better tools. Reduce some of the burden of that complexity you are referring to and streamline the more common stories to ease the learning curve. That’s what should be done.

> http://john.mcfadyen.spaces.live.com

Domain lookup of that comes up blank. Do you have another link? I sure could use some info on those undocumented features.

/Mathias

Martin MacPherson

Re: yep - back to being 100% frustrated

Reply Threaded

http://johnmcfadyen.spaces.live.com/

2008/5/15 Holmgren Mathias <[hidden email]>:

> Don't blame the tools as there are plenty of people out there using these tools and making them work seemlessly and quickly on a day to day basis.

Well, you can't just disregard the large majority of people who are struggling a lot with this. And you can't disregard the "developer perspective", because developers are the people that have to deal with this.

Sure, one part of the story is about expectations and the learning curve of installation. Before building an installation package, you expect it to be pretty easy, like a couple of days work. Then when you start doing it you find out that the level of investment necessary to complete a working real world installer is not 10 but maybe 100 times greater than what you expected, or more (yes, for real, I'm not making this up). And we are talking very experienced people here, not rookie devs.

Having to invest your time so heavily to get so little tangible result back is a shock to most people. And when all the bumps, twists and turns of the technology are added on top of that learning process there will be frustration.

Now, I'm not much for nursing cry baby mentality either. It will get you nowhere. But I do feel that there is a case to be made here about not putting up with things that are overburdening. This is the other part of the story.

If the tools can be improved to make installation simpler, why settle for less?

Or are installer technology and the tools already as good as they can ever become?

No. Identify the stuff that can be made easier with better tools. Reduce some of the burden of that complexity you are referring to and streamline the more common stories to ease the learning curve. That's what should be done.

> http://john.mcfadyen.spaces.live.com

Domain lookup of that comes up blank. Do you have another link? I sure could use some info on those undocumented features.

/Mathias

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

Justin Rockwood

Re: yep - back to being 100% frustrated

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Interesting discussion so far. I just wanted to chime in a little here. I think Mathias is correct here in stating that there are some real problems with Windows Installer (and thereby Wix in its current form). I work on the dang thing but I still get frustrated at Windows Installer. It's just too hard to do simple things. Right now, Wix is a wrapper on top of MSI, and while we are trying to make things simpler by bundling in custom actions, providing some guidance on how to write "correct" installers, providing a development environment via Votive, etc. we still have a long, long way to go before it's really easy for devs not conversant in all of the intricacies of MSI. We'll get there eventually, but slowly. As always, we are open to constructive feedback and will try our best to pass on some of your feedback to the Windows Installer group.

Thanks,

Justin

From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin MacPherson
Sent: Thursday, May 15, 2008 2:14 AM
To: Holmgren Mathias
Cc: [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

http://johnmcfadyen.spaces.live.com/

2008/5/15 Holmgren Mathias <[hidden email]>:

> Don't blame the tools as there are plenty of people out there using these tools and making them work seemlessly and quickly on a day to day basis.

Well, you can't just disregard the large majority of people who are struggling a lot with this. And you can't disregard the "developer perspective", because developers are the people that have to deal with this.

Sure, one part of the story is about expectations and the learning curve of installation. Before building an installation package, you expect it to be pretty easy, like a couple of days work. Then when you start doing it you find out that the level of investment necessary to complete a working real world installer is not 10 but maybe 100 times greater than what you expected, or more (yes, for real, I'm not making this up). And we are talking very experienced people here, not rookie devs.

Now, I'm not much for nursing cry baby mentality either. It will get you nowhere. But I do feel that there is a case to be made here about not putting up with things that are overburdening. This is the other part of the story.

If the tools can be improved to make installation simpler, why settle for less?

Or are installer technology and the tools already as good as they can ever become?

> http://john.mcfadyen.spaces.live.com

Domain lookup of that comes up blank. Do you have another link? I sure could use some info on those undocumented features.

/Mathias

chrpai

Re: yep - back to being 100% frustrated

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Last year the MSBuild team had a very interesting blog asking people if they had $100 to spend on MSBuild how would they spend it? They then went on to give a list of possible priorities.

I think it would be very beneficial if both the MSI team and the WiX virtual team would have similar blog posts. When doing it, be sure to include a broad list of features that consumers would want not just things the teams want.

For the MSI team, my wish would be that they put a lot more work into properly behaving custom action sandboxes so that consuming EXE's and Managed Code DLL's wouldn't be problematic.

Justin Rockwood <[hidden email]> wrote:

Interesting discussion so far. I just wanted to chime in a little here. I think Mathias is correct here in stating that there are some real problems with Windows Installer (and thereby Wix in its current form). I work on the dang thing but I still get frustrated at Windows Installer. It's just too hard to do simple things. Right now, Wix is a wrapper on top of MSI, and while we are trying to make things simpler by bundling in custom actions, providing some guidance on how to write "correct" installers, providing a development environment via Votive, etc. we still have a long, long way to go before it's really easy for devs not conversant in all of the intricacies of MSI. We'll get there eventually, but slowly. As always, we are open to constructive feedback and will try our best to pass on some of your feedback to the Windows Installer group.

Thanks,

Justin

From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin MacPherson
Sent: Thursday, May 15, 2008 2:14 AM
To: Holmgren Mathias
Cc: [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

http://johnmcfadyen.spaces.live.com/

2008/5/15 Holmgren Mathias <[hidden email]>:

> Don't blame the tools as there are plenty of people out there using these tools and making them work seemlessly and quickly on a day to day basis.

Well, you can't just disregard the large majority of people who are struggling a lot with this. And you can't disregard the "developer perspective", because developers are the people that have to deal with this.

Sure, one part of the story is about expectations and the learning curve of installation. Before building an installation package, you expect it to be pretty easy, like a couple of days work. Then when you start doing it you find out that the level of investment necessary to complete a working real world installer is not 10 but maybe 100 times greater than what you expected, or more (yes, for real, I'm not making this up). And we are talking very experienced people here, not rookie devs.

Having to invest your time so heavily to get so little tangible result back is a shock to most people. And when all the bumps, twists and turns of the technology are added on top of that learning process there will be frustration.

Now, I'm not much for nursing cry baby mentality either. It will get you nowhere. But I do feel that there is a case to be made here about not putting up with things that are overburdening. This is the other part of the story.

If the tools can be improved to make installation simpler, why settle for less?

Or are installer technology and the tools already as good as they can ever become?

No. Identify the stuff that can be made easier with better tools. Reduce some of the burden of that complexity you are referring to and streamline the more common stories to ease the learning curve. That's what should be done.

> http://john.mcfadyen.spaces.live.com

Domain lookup of that comes up blank. Do you have another link? I sure could use some info on those undocumented features.

/Mathias

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
[hidden email]
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/vse0120000070mrt/direct/01/_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Wheeler, Blaine (DSHS/DCS)

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by jmcfadyen

I'd like to read your notes but unfortunately this link doesn't work for
me. http://john.mcfadyen.spaces.live.com

I concur with your views on Windows Installer and count myself very
lucky to build installs in a closed environment where we control the OS,
the installer on has to know 1 language and we don't build or show
dialogs because we don't give users choices during install.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of jmcfadyen
Sent: Wednesday, May 14, 2008 11:51 PM
To: [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

It seems to me reading this from a link via Christopher Painter that you
guys
are all missing a few vital points.

It looks to me like most of you looking at this as Dev's which is where
you
are going wrong. I agree these items should be trivial to fix but there
is a
vast number of regions outside of the development sphere which are the
reason it is not. I feel some of you need to take your blinkers off and
see
what is really the big picture here.

Windows Installer is complex it is difficult to get decent information
on
but there are very valid reasons why its so difficult and most of them
extend outside the realm of the developer developing a piece of software
for
his single little machine.

Windows Installer caters for a massive array of issues problems
operating
systems, and integrates the entire setup not only for your little
application but is designed to integrate hundred/thousands of
applications
developed by hundreds/thousands of developers onto multiple platforms.
There
is a much bigger picture at work here.

I think the guys at MS have done a great job. I could say vbscript is a
great programming language and that C# or F# is crap when the reality is
my
understanding of them may not be as good as some of you guys here. Most
of
you would look at me like I was mental or something but the reality is
many
of you are looking at this with the same mentality.

I have been using windows installer since its inception and these days I
find little that it cant do with a tiny bit of brute force. Don't blame
the
tools as there are plenty of people out there using these tools and
making
them work seemlessly and quickly on a day to day basis.

Each day I integrate around 1,000,000 lines of code into multiple msi's
within minutes using WiX. (I couldnt care less what its written in, if
you
know how to use it as it was designed it works like a charm).

If anyone would like some assistance understanding the finer intricacies
of
windows installer I have some heavy detail on most of the undocumented
features here.

http://john.mcfadyen.spaces.live.com

No offence intended to anyone on these boards, this post is not aimed at
being nasty and I hope my blog can aid with some of your troubles.

Scott Palmer-3 wrote:
>
> On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <[hidden email]>
> wrote:
>
>> <snip>
>>
>> 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/vse0120000070mrt/direct/01/
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
View this message in context:
http://www.nabble.com/yep---back-to-being-100--frustrated-tp17181242p172
47075.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/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
[hidden email]
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/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Rob Mensching-2

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Scott Palmer-3

Some javascript/style in this post has been disabled (why?)

I think we’ve covered the whole gambit of issues on this thread. I am going through all of them and will try to collect all the issues raised here and attempt to answer some the open questions over time.

However, this particular comment made me chuckle:

“They solved the 8.3 filename issue in WiX V3.. I believe they can do more.”

Heh. “They” is *us*. You and you and you and you over there who doesn’t talk much. This mailing list, this place where we talk about what we do with the WiX toolset and the Windows Installer, this is where we live. This is where we get work done. This is where we make the world a better place one line of code or one question answered or one piece of feedback at a time. You may think that’s all flowery language or complete and utter bullshit but that is how I see what we (all of us) are doing here. We are a community built around using the WiX toolset and making it better.

The WiX toolset isn’t done. Nobody here is arguing that there isn’t more that we can do to make the experience better. Just look at our bug list and you can see literally hundreds of places where we are *clearly* not done. IMHO, there is so much work to do the real question is about what gets done next.

All I ask is that you remember that there are people here. We work on code, we talk about code, but this place is about people. I understand that the technology (both MSI and WiX) can be frustrating. Trust me, we all know that. I also appreciate that sometimes you just have to rant to get it out of your system. It’s fine if you want to do that here (I always read rants about actual problems since they almost always point at some pain point we have yet to address). But don’t make it personal. I can assure you that no one here is actively working to make your life harder. Instead, I encourage you to consider yourself a member of this community and frame your feedback such that it can help us improve the toolset or the community itself.

Finally, I disagree with the sentiment that this thread was doomed from the beginning. Open (and preferably respectful) debate is one of the best ways to explore the spectrum of options and issues available for us to solve. You underestimate the power you have in this community if you think that debates like this (that were mostly respectful <smile/>) have no impact.

PS: None of my comments are intended to be directed *at* Scott. They are about *all of us*. <smile/>

From: [hidden email] [mailto:[hidden email]] On Behalf Of Scott Palmer
Sent: Wednesday, May 14, 2008 07:22
To: [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

jmcfadyen

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Wheeler, Blaine (DSHS/DCS)

my apologies the link is here.

http://johnmcfadyen.spaces.live.com/

Wheeler, Blaine (DSHS/DCS) wrote:

I'd like to read your notes but unfortunately this link doesn't work for
me. http://john.mcfadyen.spaces.live.com

I concur with your views on Windows Installer and count myself very
lucky to build installs in a closed environment where we control the OS,
the installer on has to know 1 language and we don't build or show
dialogs because we don't give users choices during install.

-----Original Message-----
From: wix-users-bounces@lists.sourceforge.net
[mailto:wix-users-bounces@lists.sourceforge.net] On Behalf Of jmcfadyen
Sent: Wednesday, May 14, 2008 11:51 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] yep - back to being 100% frustrated

It seems to me reading this from a link via Christopher Painter that you
guys
are all missing a few vital points.

It looks to me like most of you looking at this as Dev's which is where
you
are going wrong. I agree these items should be trivial to fix but there
is a
vast number of regions outside of the development sphere which are the
reason it is not. I feel some of you need to take your blinkers off and
see
what is really the big picture here.

Windows Installer is complex it is difficult to get decent information
on
but there are very valid reasons why its so difficult and most of them
extend outside the realm of the developer developing a piece of software
for
his single little machine.

Windows Installer caters for a massive array of issues problems
operating
systems, and integrates the entire setup not only for your little
application but is designed to integrate hundred/thousands of
applications
developed by hundreds/thousands of developers onto multiple platforms.
There
is a much bigger picture at work here.

I think the guys at MS have done a great job. I could say vbscript is a
great programming language and that C# or F# is crap when the reality is
my
understanding of them may not be as good as some of you guys here. Most
of
you would look at me like I was mental or something but the reality is
many
of you are looking at this with the same mentality.

I have been using windows installer since its inception and these days I
find little that it cant do with a tiny bit of brute force. Don't blame
the
tools as there are plenty of people out there using these tools and
making
them work seemlessly and quickly on a day to day basis.

Each day I integrate around 1,000,000 lines of code into multiple msi's
within minutes using WiX. (I couldnt care less what its written in, if
you
know how to use it as it was designed it works like a charm).

If anyone would like some assistance understanding the finer intricacies
of
windows installer I have some heavy detail on most of the undocumented
features here.

http://john.mcfadyen.spaces.live.com

No offence intended to anyone on these boards, this post is not aimed at
being nasty and I hope my blog can aid with some of your troubles.

Scott Palmer-3 wrote:
>
> On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <Josh.Rowe@dynamicops.com>
> wrote:
>
>> <snip>
>>
>> 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/vse0120000070mrt/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/yep---back-to-being-100--frustrated-tp17181242p172
47075.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/vse0120000070mrt/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/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Tanikella, Rajanikanth (SCR US)

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Rob Mensching-2

Some javascript/style in this post has been disabled (why?)

I must say, you have all made my day. I've spent months banging my head and feeling like I'm not worth a damn despite all my non-deployment development experience. And worse, feeling like no one would understand why this installer is sucking up so many staff hours even if I tried my technical best to explain it! Now I feel validated.

John McFayden does raise a good point in bringing up the perspective of the MSI user over that of the developers. I try to believe that even ridiculous-seeming things we encounter might actually have a very good reason behind them if we only knew the actual requirement that they were intended to fulfill. Yes, I know, 8.3 file names and such do not provide a compelling example of this in 2008. But it's still more likely that there is (or once was) a good reason for it than that there are a bunch of dunces writing the software we depend upon. Each trade-off made was probably well reasoned, and yet we still have MSI as we know it today. Who is to say that we would not have made the same decision at the time?

As for writing the installer first (SDD), I think it is a good idea but impractical to most people's minds who aren't trained to think that way. (It's hard enough to get them to do TDD!) But I agree with Neil's (and Rob's) "together we can make it happen" thinking. Good practice suggests having a reasonable base infrustructure for development, CM, etc early on. So it should be with the MSI. After all the work my group has done to get my current project "humming" (albeit somewhat out of tune at times), I'd be very disappointed if my client did not end up distilling this work (especially this mysterious MSI thing) into a repeatable process for future use. Capitalize on the experience!

Ultimately, there are usability concerns all over everything we've been discussing: The usability of MSI severely impacts the usability of WiX. Perhaps WiX can improve the usability of of MSI. Maybe a future version, or a layer on top of WiX will achieve that. Similarly, the process of developing software has usability issues. If you make it easy to consider the installer at the outset by making a canned build project that has a ready-to-go target for MSI-generation, it'll be that much easier. Much like refactoring support and easy-to-use continuous integration have been a significant enabler for agile development. But it takes time, research, and conversations like this to determine what that canned build project should provide. Votive and the MSBuild parts for WiX go a long way toward helping with this.

I thank you all for the discussion, validation, and the continuing support!

Raj

From: [hidden email] [mailto:[hidden email]] On Behalf Of Rob Mensching
Sent: Thursday, May 15, 2008 1:00 PM
To: [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

However, this particular comment made me chuckle:

“They solved the 8.3 filename issue in WiX V3.. I believe they can do more.”

PS: None of my comments are intended to be directed *at* Scott. They are about *all of us*. <smile/>

Mike Dimmick-2

Re: yep - back to being 100% frustrated

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Windows Installer was designed to support corporate deployment of applications to shared machines with install-on-demand and roaming profiles, and to support Windows 95 and up. If you understand that, a lot of the features and the ICE error reports make sense. The trouble is that this corporate deployment environment is so rare – even large corporations rarely use it, largely because many MSIs don’t work right in that environment – and so far away from the common case that most of us are dealing with, namely installing applications one time for all users of a personal computer that isn’t on a managed network and doesn’t roam.

Why is a per-user install the default? Because in these corporate environments, multiple users on the same machine might not be allowed access to the same applications.

Why are advertised shortcuts the default? Because in these environments, you might advertise the product only so that only those users who actually need to use it actually invoke the installer. (Never mind that users will typically browse to see what’s available, ‘what does this do?’, so invoke the installer almost by accident.) That comes from a corporate desire to fit smaller, cheaper disks but there’s a lower limit as to how small you can make a disk with a given technology. For example an 80GB Seagate SATA drive costs £24.20 from a site I’m looking at now, but a 160GB drive, double the space, costs only £6 or 25% more. The disk as a fraction of the system cost has fallen over the last ten years.

Why are advertised shortcuts and icons so complex? To support Windows 95 and NT 4.0 without the IE4 Desktop Update.

Why do the Class and TypeLib (etc) tables create an advertised link? Because someone thought it would be a good idea to support on-demand installs of COM objects, when it was a tenet of architecture astronauts that we’d stop buying pre-assembled applications and instead assemble our applications ourselves from libraries of pluggable components. (This one keeps coming back, only now it’s called a ‘mash-up’, but everyone always overlooks the testing matrix, which suffers combinatorial explosion with even a few different components.)

In some cases the ICE tests indicate a ‘smell’ in the core installer engine – ICE38, keying the installation of a shortcut from the absence of a registry key, should have been fixed in Windows Installer itself somehow.

And now, time for a confession. I haven’t built any installers with WiX. Everything we’re shipping we’re still shipping with Visual Studio deployment projects. I haven’t been given the time to invest in improving the installer for our application server product, which is really our only product (in that the same object code is shipped to every customer) for which I was evaluating WiX. (I work for a small contract development house owned by a value-added reseller, mainly of handheld devices, but we’re all generalists and do some management consoles, Web- and Windows-based, for handheld-driven systems, plus this application server and some comms servers.) The application server is nearly exclusively sold as part of a larger solution – while plug-in applications can be written by anyone (you write a COM object with a couple of defined entry points), in practice we’ve sold to very few companies doing their own application development. As such any investment in the application server tends to be to fix issues experienced by one or more customers or to add features for an upcoming system.

Having been on this mailing list for a long time I’m torn between replacing the installer for this with a WiX-based installer – with a huge amount of pain that will go with that, and the knowledge that few of my colleagues will be able to maintain it – and ditching it for something like NSIS. We don’t install many shared components, which in my view is the area in which Windows Installer-compliance is necessary. I’m considering going registration-free COM, a tricky prospect with VB6 applications (no investment in migrating from VB6…), but better than installing shared components. Shared-nothing components and application initialisation of configuration make for very simple WiX installs, but they’re so simple that there’s no need to do component reference-counting (which is a good thing, since that’s where Windows Installer is complicated) so you might as well have used xcopy. The only thing Windows Installer is doing for you is allowing you to create shortcuts and register services! It’s not very compelling.

With my database administrator’s hat on, I find applications that install their own databases tiresome. They inevitably seem to make mistakes in their installers. Reporting Services service packs don’t quite line up with schema versions, so you seem to end up scrapping the existing database and recreating. SourceGear’s Vault accidentally inserted a backslash before the data file name when there was already one at the end of the path, then SQL Server’s Volume Shadow Copy Writer complained when trying to back that database up. Other tools don’t give the administrator the option of where to place the database – any sensible SQL Server setup (not dedicated to a single database) will want to place the data files on a disk separate from any other files, and the log files on further separate disks, so the ‘default’ DB location may well not be useful. Given the amount of flexibility required, you may well want to just supply scripts and allow the DBA to run them after creating databases themselves, and that’s the approach we’re taking (the application server supports server farms with a SQL Server database for shared state).

Mike Dimmick

From: [hidden email] [mailto:[hidden email]] On Behalf Of Tanikella, Rajanikanth (SCR US)
Sent: 16 May 2008 15:35
To: [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated

Mike Dimmick-2

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Scott Palmer-3

Some javascript/style in this post has been disabled (why?)

It’s true for simple applications, but those simple applications are just anything that can be written to be statically linked into a single binary. You could do this on Windows if you were prepared to stick to those rules – and you can produce quite powerful applications that way, if you cared to do it. But you’d have to forgo anything that needs a shared library or framework or fonts – basically anything bigger than a single file. Apple’s page “Installs for Product Developers” says:

For anything that requires something shared, it’s a myth. The icon you drag-and-drop is an installer. It’s just that drag-and-drop invokes the installer, the same way that double-clicking invokes an MSI installer. See ‘Managed Installs’ in Apple’s Software Delivery Guide at http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_1.html.

I think the difference really is that there isn’t such a prevalence of shared libraries on the Mac as on Windows, and of things like multiple disk volumes. To upgrade your Mac, you buy a new one, you don’t start adding disks (because on most Macs, you can’t add internal disks). It makes for a far simpler environment. Also, the pace of support for new operating systems is much faster, most Mac apps won’t install on the OS earlier than one version before current. A lot of us are still writing software to work on Windows 2000 (I hope no-one here is still building ANSI apps for Windows 9x though!) There are also many, many places where Windows allows plug-ins (e.g. Explorer context menus) that just aren’t there on the Mac.

Microsoft’s approach tends to be to offer many new features even on down-level operating systems. Imagine if your customers had to update to XP.3 in order to get .NET 2.0, or Windows Vista 6.1 to get .NET 3.5! But that makes deployment much more complicated, because you have to deploy the framework you depend on, and its dependencies, to get your program to work at all.

Also Mac apps tend to be less configurable. The million-questions approach taken by most Windows install packages is ridiculous when you consider that most users just go with the defaults. Clicking through Windows Installer wizards is a pain in the neck. It’s not as if selecting a reduced install of Office 2003 or 2007 actually reduces the disk space used, because (to prevent problems with finding original media when patching or repairing) a complete copy of the install is cached on your hard disk anyway. You might as well install the whole thing to begin with. And a repair is only necessary when some shared component has been stomped on with an incompatible version anyway.

Mike Dimmick

From: [hidden email] [mailto:[hidden email]] On Behalf Of Scott Palmer
Sent: 13 May 2008 19:58
To: Josh Rowe
Cc: WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated

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? :-)

chrpai

Re: yep - back to being 100% frustrated

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Good points Mike. Personally I'm starting to pay attention to application virtualization solutions. Just as once upon a time I made the transition from script based installs to MSI based installs, I'm wondering if one day in my future I'll be able to just get rid of the install all together. I see this as a possibility for simple client side applications. Unfortunatly for things that have much more complicated dependencies I wonder if it'll ever be a possibility.

Mike Dimmick <[hidden email]> wrote:

Its true for simple applications, but those simple applications are just anything that can be written to be statically linked into a single binary. You could do this on Windows if you were prepared to stick to those rules and you can produce quite powerful applications that way, if you cared to do it. But youd have to forgo anything that needs a shared library or framework or fonts basically anything bigger than a single file. Apples page Installs for Product Developers says:

For anything that requires something shared, its a myth. The icon you drag-and-drop is an installer. Its just that drag-and-drop invokes the installer, the same way that double-clicking invokes an MSI installer. See Managed Installs in Apples Software Delivery Guide at http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_1.html.

I think the difference really is that there isnt such a prevalence of shared libraries on the Mac as on Windows, and of things like multiple disk volumes. To upgrade your Mac, you buy a new one, you dont start adding disks (because on most Macs, you cant add internal disks). It makes for a far simpler environment. Also, the pace of support for new operating systems is much faster, most Mac apps wont install on the OS earlier than one version before current. A lot of us are still writing software to work on Windows 2000 (I hope no-one here is still building ANSI apps for Windows 9x though!) There are also many, many places where Windows allows plug-ins (e.g. Explorer context menus) that just arent there on the Mac.

Microsofts approach tends to be to offer many new features even on down-level operating systems. Imagine if your customers had to update to XP.3 in order to get .NET 2.0, or Windows Vista 6.1 to get .NET 3.5! But that makes deployment much more complicated, because you have to deploy the framework you depend on, and its dependencies, to get your program to work at all.

Also Mac apps tend to be less configurable. The million-questions approach taken by most Windows install packages is ridiculous when you consider that most users just go with the defaults. Clicking through Windows Installer wizards is a pain in the neck. Its not as if selecting a reduced install of Office 2003 or 2007 actually reduces the disk space used, because (to prevent problems with finding original media when patching or repairing) a complete copy of the install is cached on your hard disk anyway. You might as well install the whole thing to begin with. And a repair is only necessary when some shared component has been stomped on with an incompatible version anyway.

--

Mike Dimmick

From: [hidden email] [mailto:[hidden email]] On Behalf Of Scott Palmer
Sent: 13 May 2008 19:58
To: Josh Rowe
Cc: WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated

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? :-)

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

Nathan Stohlmann

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Mike Dimmick-2

First, thank you for the excellent points about several of the
features that we put in for legacy platforms, but I'd like to politely
disagree with the idea that MSI corporate deployments are very rare.
Just to provide a different view, as someone who cut their teeth on
MSI back in the good old 1.0 days repackaging for corporate deployment
and having since been involved in medium and large corporate
deployments as well as ensuring that the large corporate deployment
pattern was part of the design of several first party installation
projects, I can state from experience that the use of Windows
Installer is alive and well for corporate deployments. The default
application set on my desktop at work is entirely MSI managed by SMS
and IME that is not nearly as uncommon as you seem to indicate. Even
in the case of Citrix and similar pseudo-virtualization scenarios, the
primary method that I have encountered for deployment to those
environments (and some of the new patterns I'm having to take into
account) is based around MSI.

As has been pointed out fairly often in this thread, installation
development and application deployment is far from a narrow field in
the Windows ecosystem. The design of a setup has to take into account
a huge array of variation in the target platform that leads to a
certain level of complexity. As you pointed out, factoring in the huge
legacy of quirks of previous operating systems as well as the new
features (some of which I'm sure will be considered quirks in five
years time :-) ) just adds to that complexity.

I would also just like to add a small thanks for the obviously
conscious effort to try and keep this thread from devolving into the
flame war it could have been.

--
--Nathan Stohlmann
Minneapolis, MN USA
[hidden email]

On Fri, May 16, 2008 at 10:30 PM, Mike Dimmick <[hidden email]> wrote:
> Windows Installer was designed to support corporate deployment of
> applications to shared machines with install-on-demand and roaming profiles,
> and to support Windows 95 and up. If you understand that, a lot of the
> features and the ICE error reports make sense. The trouble is that this
> corporate deployment environment is so rare – even large corporations rarely
> use it, largely because many MSIs don't work right in that environment – and
> so far away from the common case that most of us are dealing with, namely
> installing applications one time for all users of a personal computer that
> isn't on a managed network and doesn't roam.

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

dB.

Re: yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Chris Mumford-2

Some javascript/style in this post has been disabled (why?)

I wanted to thank the windows installer team and offer a fresh perspective. I don’t think that Windows Installer sucks, and I just can’t get myself to hate the technology.

I think building a solid installer should be as hard as writing good code and force you to think. Every time I put an average developer on something seemingly easy that they can’t screw up, I end up with crap that needs to be thrown away. If it’s easy, it’s done fast and it works, until it doesn’t or until you read the code. For important pieces of any application, I need experienced senior people. So a huge problem is the misconception that an average developer can do an installer well – truth is that an average developer can’t do anything well, MSI is no exception.

In my company the few very senior people jumpstart everything, including installers. Once the hard stuff is done, architecture is designed and essential pieces are implemented, tasks are distributed amongst less experienced yet smart people. They are monitored through standard code reviews, heavy unit testing, etc.

I’ve used wix since 1.0 and my Microsoft days. It’s imperfect, but it helps me put installer code at the same level as C++ or C# code, and that’s the most important thing for me. We write custom actions when we can’t build a feature into the product itself. Some things do frustrate me in MSI, but not as much as the weather that forces me to use the indoor pool :)

From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Mumford
Sent: Monday, May 12, 2008 12:13 AM
To: [hidden email]
Subject: [WiX-users] yep - back to being 100% frustrated

Man:

I can't believe how much making Windows Installer based installs suck - I mean really sucks! Did we just invent this technology to make us hate our lives?

And WiX doesn't make it any easier.

I'm calling it a night.

Peace out man...

DEÁK JAHN, Gábor-2

yep - back to being 100% frustrated

Reply Threaded

In reply to this post by Tanikella, Rajanikanth (SCR US)

On Fri, 16 May 2008 07:35:17 -0700, Tanikella, Rajanikanth (SCR US) wrote:

Raj,

> 8.3 file names and such do not provide a compelling example of this in 2008.

This one comes up from time to time... It was mentioned a couple of times that some old but still functional Novell file servers have that limitation and if MSI dropped supporting it, it would be impossible to install those packages from those network servers. Probably a moot point for all but a dozen people on the planet but Windows has always been plagued with backward compatibility constraints far too long...

Bye,
Gábor

-------------------------------------------------------------------
DEÁK JAHN, Gábor -- Budapest, Hungary
E-mail: [hidden email]

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

chrpai

.NET 3.5 Optimized For Client Development Install

Reply Threaded

There are various references that VS 2008SP1 contains an optimized netfx redist. I've pulled the sp bootstrapper and ran the command create the installable layout but I don't see it. The only thing I see is a dotnetfx35setup.exe (3.5.30428.1) 2.8mb web downloader that when ran on my vs2008/.net3.5 x86 machine wants to download 51mb.

Has anyone seen a link or a white paper explaining how to get to this 20mb downloader? I have a few installs that I'd like to refactor and see if this solution would work for them.

1 2 3