Hacking .Net Framework onto WINPE ?

Question:

Re: https://blogs.msdn.com/david.wang/archive/2005/10/24/The_Joys_of_Vista_Unattend_Setup.aspx

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.

Thanks,

Answer:

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:

1. 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.
2. 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.

//David

Comments

• Anonymous
  August 16, 2007
  I think MS really dropped the ball, taking the "will not support .Net in WinPE" stance. as it stands, there is no good solution for creating deployment apps that run in WinPE that require more advanced programming and GUIs. I've had to resort to RealBASIC, which is a terrible programming language btw.

• Anonymous
  November 17, 2007
  Mr. Ed - Can you elaborate on which critical deployment task cannot be run in WinPE? WinPE is designed to be a basic environment to bootstrap OS deployment. I do not understand what "advanced programming and GUIs" have anything to do with OS deployment, nor why you have to use RealBASIC for your tasks. It seems that you have no .Net dependency since you can resort to RealBASIC, so why should WinPE support .Net? Is .Net on WinPE a concrete requirement or mere personal preference and opinion? C/C++, and Windows Scripting Host, ADO, and HTML are perfectly acceptable and low-cost/low-impact way to develop deployment applications in a basic environment like WinPE. //David

• Anonymous
  May 02, 2008
  I'm with Mr. Ed on this one. I am working on a deployment system that currently relies on HTAs and JavaScript/VBScript to perform a series of special tasks to select, prepare, and deploy operating system configurations. Using HTAs with JavaScript/VBScript using WMI is currently the "best" solution and it is quite a terrible working environment. The ability to use .NET would not only help by allowing us to use a strong-typed language such as C# but also give us access to a wider array of APIs to leverage in the deployment. And on top of all of that it would make programming and testing easier to do in our development environment by letting us leverage Visual Studio's debugger to work out problems.

• Anonymous
  May 02, 2008
  The comment has been removed

• Anonymous
  August 11, 2008
  David, I am a systems engineer at a large retail company, and I have some input on this discussion. As a systems engineer, and not a software developer, it is often useful for me to develop tools using manged code, such as C#, which as others have mentioned, gives access to a rich set of APIs. There are many tasks that WinPE would be great for, NOT as an operating system, but as a diagnostic and remediation platform, which is what I leverage it for quite a bit. I understand why you are suggesting that .NET goes against the concept of WinPE being a light-weight bootstrapper, and I agree, WinPE needs to stay lightweight, but regardless of that, I would still absolutely love to see .NET be supported on WinPE. There are a lot of things that probably wouldn't make sense to support on WinPE, like WCF, WPF, and WF, but if even just the 2.0 Framework were available, that would open up so many doors to make offline diagnostics and remediation more possible. I'm just thinking here, but I wonder if there's a way to perhaps rather than actually loading an entire ISO, which .NET would bloat up a little more, if there's some way that OS streaming technology could be used to only transfer the necessary parts of WinPE. I'm not sure if you're familiar with Citrix Provisioning Server, but it's a really cool technology that lets you stream OS's out to workstations. It only transfers data that is requested by the client, so network utilization is limited as such. It would be VERY awesome if WinPE could somehow be distributed this way in an enterprise environment, again, as a diagnostic and remediation platform, as well as a bootstrapper. That's all I have to say for now, but if you'd like to contact me, please feel free to at <FirstName><LastName> at OfficeMax d0t com. Thanks in advance, Trevor Sullivan

• Anonymous
  February 27, 2009
  I think that Microsofts desires for how we use WinPE and our desires for how we want to use WinPE are at odds. Microsoft can't understand anything that doesn't come out in agreement to their implementation because they would have to see beyond their own expectations of how WinPE would be used by customers. WinPE is not just a preinstall OS. It's not just a simple environment. It's a platform for applications that are not at all related to installing. Many products use WinPE for distaster recovery for instance and those products may have much native code but could benefit greatly by inclusion of .Net Framework availability on WinPE. When we originally wanted to write code to boot off a disk we went the DOS route. This meant we had a lot of code that had to be written twice. Once for our main product running under Windows NT/2000/XP etc and again for DOS. Later we started considering ways to get away from DOS one of those ways was Linux. Sure we'd have to write our code for Linux but we at least would have a better more modern OS than DOS. But because we wanted to use as much of our code on the bootable disc version of our product as possible we went WinPE. It saved us a lot of rewriting of code and for the most part one binary works on both PE and Windows 2000/XP/2003/Vista. But now as the environment changes and more and more of what we do would benefit or require C# our WinPE choice is now feeling a lot like our DOS choice. There are many aspects of our product that would benefit from writing in a richer language with richer APIs of the .Net framework languages and because of our code having to run on WinPE at times we can not taken advantage of .Net Framework. Stop looking at WinPE like a tool to install the OS and look at it as a platform that may find many more uses than you can imagine.

• Anonymous
  March 05, 2009
  The comment has been removed

• Anonymous
  May 05, 2010
  I have developed UI's for WinPE using Delphi 7...  It works GREAT!!!  The thing is that is an OLD version of Delphi.  I'm a beta tester for Delphi Prism which uses .NET. I would prefer to use C#, but that is not an option.  Lately I'm using C++ which works, but development is MUCH MUCH slower... Is there a Rapid Application Development environment out there that compiles to .EXE's that will run in WinPE? I'm running Windows 7 right now, and I do not like running Delphi 7 in XPM...  I need to create a GUI for ImageX to make/restore snapshot images of machines.  I've already created other UI's to help techs to image machines quickly... Anybody got any suggestions?

• Anonymous
  July 05, 2010
  agree there should be no need to write any custom .NET executable. MDT 2010 should be used for deployment, all the scripts are already written for you. Customize the task sequence to do anything else you need. That being said - having got so attached to the beautiful C# language, the fact I cannot use it for creating diagnostic utilities is a pain. it would be nice if we could at least get a compact .NET framework supported in PE. while it is true it can all be done with HTA VBScript or C++ the problem is 1) C/C++ development takes WAY longer than using .NET 2) Large programs in VBScript are a nightmare to manage/debug At the moment I'm resorting to use C++ but I have to say I'm suffering after getting so used to .NET for Windows development. Plus when use don't use C++ often, coming from C#, it seems way easy to introduce stupid bugs...have to go back to reading C++ best practice manuals...

• Anonymous
  July 05, 2010
  agree there should be no need to write any custom .NET executable. MDT 2010 should be used for deployment, all the scripts are already written for you. Customize the task sequence to do anything else you need. That being said - having got so attached to the beautiful C# language, the fact I cannot use it for creating diagnostic utilities is a pain. it would be nice if we could at least get a compact .NET framework supported in PE. while it is true it can all be done with HTA VBScript or C++ the problem is 1) C/C++ development takes WAY longer than using .NET 2) Large programs in VBScript are a nightmare to manage/debug At the moment I'm resorting to use C++ but I have to say I'm suffering after getting so used to .NET for Windows development. Plus when use don't use C++ often, coming from C#, it seems way easy to introduce stupid bugs...have to go back to reading C++ best practice manuals...

• Anonymous
  July 14, 2010
  I think what is really being asked for here is the use of WinPE for reasons other than just OS Deployment, such as being able to use diagnostic utilities and small applications.  I know that many admins aren't against CLI, but at the same time, there are many times where I find a small gui based application to be quite easier and quicker to use because I'm not having to type everything out.  Having the ability to automate tasks with a GUI might be more visually appealing.  I don't think people want WinPE to be a full fledged OS, but many of us are looking to be able to use it as a comparable "LIVE" version of windows for diagnostics and administrative tasks along side of deployment. That being said, the fact that I cannot make a small gui to manage a diagnostics process leaves me having to do one of two things: 1) write all my apps in CLI and use scripts to run the apps, or 2) I need to development my apps in C++ and cannot use C# or VB (since there is no way to compile them natively without the need for the .NET framework. I believe that is more or less where the negative feelings come in about WinPE.  Again, not to run MS Office and Web browsers and Adobe Photoshop from, but small tools/utilites to diagnose things or to improve the effeciency of lower end techs working to solve small problems.

• Anonymous
  September 22, 2010
  In most large environment OS deployment needs  to be automated using WinPE or other Tools. With that you need to able to use GUI environment to select certain parameters prior to deployment.  Most server environment use static IP and In it's most basic state, at the very least, we should be able to provide GUI interface to type in IP configuration, not to mention, Server Naming enforcement. ability to select Apps to be deployed etc. If the purpose of WinPE is to facilitate OS deployment then providing ability to have GUI interface makes perfect sense Small shops that deploy server or two once in a while don't need WinPE they can just manually deploy OS using Windows CD. This lack of these features in WinPE makes room for tools like BartPE.

• Anonymous
  November 28, 2010
  The comment has been removed

• Anonymous
  March 03, 2014
  ms should come with hacking software cause its a pain to find