Here, you mentioned how Vista obviates the “need to push customized WINPE CDs with the .Net Framework and WMI hacked onto it”.
But back to the XP world for a bit: *Is* there an accepted method for hacking .NET Framework onto Windows PE? Or how could one avoid doing that if one needs to write VS-compiled tools to run on a Windows PE CD that installs 64-bit XP (since there is no 32-bit support in that environment)?
I’m figuring that I need .NET 2.0 for this task, but the Web has no advice to offer for this task beyond .NET 1.1.
I know this is off your IIS track, but if you have any ideas, it might stop me from cursing Microsoft for not considering the implications of failing to provide a 32-bit setup program for 64-bit XP.
To clarify – I did NOT say that Windows Vista eliminates the “need to push customized WINPE CDs with the .Net Framework and WMI hacked onto it”. I was saying that one can definitely install Windows Vista WITHOUT requiring such a hack of .Net Framework and WMI, and removing such requirements makes general sense for a tool seeking widespread adoption.
Actually, I am not certain how .Net Framework has anything to do with WINPE for x64. The official stance is that .Net Framework is not supported on WINPE. It sounds like what you are asking is:
“If I cannot run my 32bit tools in WINPE for x64, is there any way to author and run tools in a processor-agnostic environment [such as the .Net Framework] so that I do not need to recompile and run native 64bit tools in WINPE for x64”.
If that is the question, then my advice is to either:
- Bite the bullet and recompile your tools to be native bitness. WOW64 is a compatibility layer with its own baggage which would require a duplicate SYSWOW64 directory, duplicate Syswow6432 Registry nodes, COM support, etc… it is definitely not simple nor cheap, and I can understand why 32bit applications are not supported in a restricted and tight-fitting 64bit WINPE environment.
- Write tools in JScript/VBScript or Batch scripting, all of which execute in a processor-agnostic fashion.
Now, since .Net Framework 2.0 does natively support x64, it may be possible to hack it onto WINPE for x64, but that will not be supported. Personally, I prefer option #2 because for the purposes of having “processor agnostic tools that just work”, the Windows Scripting Host environment is:
- Far more lightweight
- Natively supported
- More stable than .Net Framework
In fact, if you were using tools based on the Windows Scripting Host, you probably would not skip a beat between 32bit and 64bit WINPE… I know I know, it does not account for your “custom Perl scripts” or “custom 32bit tools”, but presumably you own source code to all of them and should be able to freely recompile them (the free Windows Platform SDK gives you free compilers, and [I have not verified this] you can try the free Visual C++ Express for a free compiler).
But getting back to the original point – no, I have no desire to ever see .Net Framework in WINPE because the two seem like contrary goals.