Matt, think they did it as it is not officially supported for the platform or the compatibility was removed just because of this problem. Think for the msbuild bootstrapper it should also be possible to create such a prerequisite installing the windows imaging component on XP SP2++ and Win 2003.
For me it's not a problem as on the one hand we deploy InstallShield packages and they have the configuration to create such a bootstrapper and on the other hand side I'm doing some research with a NSIS installer. For this "Bootstrapper" it should be possible with few effort to work similar like a InstallShield one. MSBuild is discarded as it is not possible to create an all containing exe and Burn isn't on the market (or at least a Non-Beta version). For dotNetInstaller the desired behavior seemed not being so easy to implement like in NSIS. @Bruce: Hm ok I understand. Seems really an issue related to non RTM versions of OS'ses.That's one of these time consuming stupid issues :-/ For me I try only to test on RTM versions to avoid such things. Tobias 2010/9/9 Matt Sullivan <msulli...@zaptechnology.com>: > Tobias, > > That's exactly the problem I encountered, I was testing on Server 2003. > > According to this Scott HanselMan's blog: > http://www.hanselman.com/blog/TowardsASmallerNET4DetailsOnTheClientProfileAndDownloadingNET.aspx > Microsoft deliberately took WIC out of the .Net 4 install, to reduce the > installation size. > > What I don't really understand is why they didn't make a bootstrapper package > for it, or why if the msbuild bootstrapper is going to fail it doesn't do so > with graceful error dialog. > > -- > Matt > > -----Original Message----- > From: Tobias S [mailto:tobias.s1...@gmail.com] > Sent: Thursday, 9 September 2010 12:01 AM > Cc: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] .Net 4 bootstrapper with Windows Imaging Component > > Hm... ok. Just tried to configure a bootstrapper to install the .net > 4.0 client profile and ran into the same issue as well :-) Was on a XP SP2. > After installing the wic_x86_enu.exe installation of .net 4.0 sucedded. Ok. > From my current point of view it seems the following: > > .Net 4.0 Supported Operating Systems:Windows 7;Windows Server 2003 Service > Pack 2;Windows Server 2008;Windows Server 2008 R2;Windows Vista Service Pack > 1;Windows XP Service Pack 3 > > wic_x86_enu.exe Supported Operating Systems:Windows Server 2003;Windows > Server 2003 R2 Datacenter Edition (32-Bit x86);Windows Server 2003 R2 > Enterprise Edition (32-Bit x86);Windows Server 2003 R2 Standard Edition > (32-bit x86);Windows XP Service Pack 2 > > So for met it seems that XP SP2 and Win Server 2003 need the wic component to > be installed to run .net 4.0 isntallation. Some other versions of the > framework may install the WIC component as well (like .net 3.5). But the > solution seems not to be supported by Microsoft. > > Which OS were you running ? > > Regards > Tobias > > 2010/9/8 Bruce Cran <br...@cran.org.uk>: >> On Wed, 8 Sep 2010 14:21:58 +0200 >> Tobias S <tobias.s1...@gmail.com> wrote: >> >>> For the older versions of the Framework I always used the reg >>> detection mechanism which was also the Microsoft recommended way >>> (Sorry don't know the MSDN reference at the moment). InstallShield >>> also uses the reg detection for 4.0 versions: >>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework >>> Setup\NDP\v4\Client Install = 1 for client profile and for full one >>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full >>> Install = 1 >> >> I don't think I've seen any documentation from Microsoft about using >> the version of mscoree.dll but got the idea from a previous thread on >> wix-users. Since I expect to be updating the application regularly >> I'll switch back to using registry detection: it won't become an issue >> for a few years. >> >>> Think here the problem is that you don't know what is the policy used >>> by Microsoft for compatibility of the managed components with newer >>> framework versions. So for example 2.0 components may also work with >>> 4.0 Framework (where no 2.0 Framework is present - somehow a bit >>> seldom but possible with XP SP3). So in my oppinion for the 4.0 >>> Framework should detect exactly version 4.0 to ensure compatibility >>> of the application with the framework it was tested with. >> >> http://msdn.microsoft.com/en-us/library/ff602939.aspx explains the >> policy for backwards compatibility. I remember I had problems >> deserialising data created with .NET 1.1 on a system with 1.1SP1 so >> I'm not sure how far I'd trust it with anything more complex than a >> console application. >> >> -- >> Bruce Cran >> > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
