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

Reply via email to