"For all end users" would mean that 100% of end users don't have the
prerequisite and I think that's far, far from reality.
I believe it is an acceptable experience for the occasional user to be told to
go install a foundational piece of software. For those who don't want that,
they can wrap their MSI in a Burn EXE and include a full or web installation of
the prereq. The vast majority of Vista, Win7, Win 8/8,1, Server 2008/R2,
2012 and so on should all be covered. The occasional person who decided to
remove it from their O/S or are running a 10 year old installation of XP should
be told to get with the program. (The XP comment is what kind of started all
this.)
What I'm trying to express is that while we are discussing the merits of native
vs managed, countless developers are turning out installers that, well, just
suck. I'm sure you've seen what I've seen. The vast majority of installers
that I review are absolutely horrid in the things they do. Right now I'm
looking at one that uses an InstallScript custom action to build a .BAT file
and call it. The .BAT file then calls out to RegAsm multiple times. While we
discuss the user experience of requiring .NET, the users are experiencing
installers that fail miserable in countless ways.
Trying to keep it short, I'd rather get 99% of developers capable of creating
installers that while not absolutely perfect, don't outright suck then get 1%
of developers capable of creating absolutely perfect installers. I personally
am willing to make some compromises to that end. When all is said and done, I
think this would do far more to improve the end user experience across the
world.
----------------------------------------
From: "Rob Mensching" <r...@robmensching.com>
Sent: Sunday, November 10, 2013 1:08 AM
To: "WiX toolset developer mailing list" <wix-devs@lists.sourceforge.net>
Subject: Re: [WiX-devs] Managed code vs. native code.
I see. Do you believe the installation experience where the installation
blocks and tells you to go download some dependency is the best experience for
all end users? From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Saturday, November 9, 2013 3:46 PM
To: WiX toolset developer mailing list; WiX toolset developer mailing list
Subject: Re: [WiX-devs] Managed code vs. native code.
Re #1, I block when missing. This whole conversation started with you wishing
death to XP (or similar). From that I assume you mean the same for Server 2003
and that W2K/NT4.0/95/98/ME is already dead.
That would seem to me to leave a very, very high penetration rate for .NET 2.0
or newer. It seems to me (and experienced on a daily basis) that this changes
the balance. C++ is nice but my concern is, and this is going back to your
comment about XP making it harder, that we miss out on useful features because
we don't have the time and human resources to get it done in C++. I think
managed code is fine for the user space. I can't tell you how many open
programs I download that require you to get java, .net, python, git, some
postscript tools ectera because they took a dependency. It's just a fact of
life.
I just had to buy a replacement diamond for my wife when her old stone fell
out. We picked a larger stone with a good cut but inferior color and clarity
because it met her needs and I could afford it sooner. Better specs would have
been great but now she can wear her ring again. I hope that analogy makes
sense. :)
----------------------------------------
From: "Rob Mensching" <r...@robmensching.com>
Sent: Saturday, November 09, 2013 5:22 PM
To: "WiX toolset developer mailing list" <wix-devs@lists.sourceforge.net>
Subject: [WiX-devs] Managed code vs. native code.
Wait, there are a few things being discussed here so let me try to break them
down. Also, this has nothing to do with the original thread so I changed the
subject. First, there is a fundamental issue with the approach Christopher
described originally: provide a .config file to state your old managed code
will run on a newer CLR. Doing so either requires that a package with managed
code custom actions ship NETFX with the package (or block when missing) or you
can travel back in time. Since we don't want the WiX toolset to force our users
to require NETFX with their installation package (see next point) that only
leaves us the second option: discover time travel. Second, we want the WiX
toolset to force as few requirements on the user's installation package as
possible. Ignoring Server Core for a moment, if someone has a pure native code
application then I would understand if they were very disappointed if using
some functionality of the WiX toolset forced them to install NETFX with their
package. Third, the WiX BA is a different scenario than managed custom
actions. For example, the WiX BA can use managed code because it ensures that
the version of NETFX that it requires is installed before going forward (no
time travel necessary). Also, the WiX BA is not a reusable platform "component"
so technology decisions there do not have implications on users. Fourth, I
was discussing design complexity. It doesn't matter what language the code was
written in, we should strive for the simplest design reach our goal. Fifth,
today managed code is best for the stuff that runs in the "developer's space"
and native code is best for the stuff that runs on the "customer's space". We
can revisit use of managed code in the "customer's space" when the CLR is on
every platform the WiX toolset's output supports and the CLR never releases
side by side again. --- From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Saturday, November 9, 2013 2:29 PM
To: WiX toolset developer mailing list; WiX toolset developer mailing list
Subject: Re: [WiX-devs] Issue & possible solution: Burn Startup-Screen is
shown twice (on Windows XP) if bootstrapper contains driver-installation
And the default contains PowerShell and .NET. It seems like you are playing
both sides.... trying to make the defaults seem more important then they are
while at the same time talking about how someone could remove PowerShell which
is not a default.
In 2013, I feel very comfortable in making .NET my partner in the general case.
I answer questions on StackOverflow every day and the vast majority of
developers are still writing horrible InstallScript, VBScript, JScript,
InstallUtil, EXE, .BAT custom actions. It's hard enough to get through to
them with C#... C++ is a lost cause.
----------------------------------------
From: "Bruce Cran" <br...@cran.org.uk>
Sent: Saturday, November 09, 2013 3:22 PM
To: "WiX toolset developer mailing list" <wix-devs@lists.sourceforge.net>
Subject: Re: [WiX-devs] Issue & possible solution: Burn Startup-Screen is
shown twice (on Windows XP) if bootstrapper contains driver-installation
On 11/9/2013 9:08 PM, Christopher Painter wrote:
Let me bring this full circle. The conversation started with Rob saying:
"Also, XP is going to have to go away. Not desirable to do highly complex stuff
for something that is *definitely* not the future." To me, it's the same thing.
C++ is highly complex compared to C# and some Server-Core without .NET running
Hyper-V isn't even remotely a common case. I would question why software is
even being installed on a machine like that. If you are going to break best
practices by putting applications on the parent partition, you might as well
put .NET and PowerShell on there while you are at it.
Remember that the _default_ installation of Server 2012 onwards is Core. Of
course installers are still needed for drivers and their management tools, as
well as anything like Web apps etc.
--
Bruce Cran
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
