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<mailto:r...@robmensching.com>>
Sent: Saturday, November 09, 2013 5:22 PM
To: "WiX toolset developer mailing list"
<wix-devs@lists.sourceforge.net<mailto: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<mailto:br...@cran.org.uk>>
Sent: Saturday, November 09, 2013 3:22 PM
To: "WiX toolset developer mailing list"
<wix-devs@lists.sourceforge.net<mailto: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
