Hacking .Net Framework onto WINPE ?


Re: http://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.



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.


Comments (14)

  1. Mr. Ed says:

    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.

  2. David.Wang says:

    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.


  3. Nick says:

    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.

  4. David.Wang says:

    Nick – Basic, bare-bones systems like WINPE and access to wider, richer array of API are contradicting desires. You can’t have bare-bones system offering rich array of support. You will have to choose one or the other.

    I suspect that you really want a rich but still relatively locked down environment to run LOB applications, and since WINPE is the closest locked down environment, you want it to also be sufficiently feature-rich to doeverything you want.

    Alas, everyone’s definition of "feature-rich" is different, governments/EU also want to define what is available in such environments, and if we allowed this environment to be so customizable, it would lose its locked-down stability.

    Also, it seems like you are really complaining about Visual Studio’s support for developing HTA/JavaScript/VBScript and/or your own dependence on .NET because if Visual Studio offered a complete development environment for them, would you still need .NET or need to debug inside of WINPE?

    For example, when developing for a similarly lightweight environment, like a mobile phone — one tends to author/debug the application on a workstation with Visual Studio and emulation — and run final validation inside of an actual phone. You’re not asking to run Visual Studio or full-blown .Net on the mobile phone, so why ask to do the same in WINPE.

    I think what you are really asking for is an in-between environment that is more than WINPE but less than standard Windows. Whether the market supporting such an in-between environment makes sense… that is beyond my abilities.

    Unfortunately, what you are currently asking for is not the design goal of WINPE, so as much as you or anyone else would desire such an environment, it is not going to happen on WINPE.


  5. 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

  6. John says:

    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.

  7. Stewart Basterash says:

    To All,

    I feel your pain. I’ve made numerous attempts at getting the .NET framework into PE. Serveral years ago I was working a project where I designed a deployment methodology for 6000 systems. The concept was taking user intervention out of image deployment. Initially I was using a JSCRIPT / HTA solution connecting to a corporate SQL database… In fact the database was SMS. This gave me the ability to have the WinPE bootable capture the MAC address of the machine, which then used the SMS database to do a MAC-to-Name translation. This took fat fingered computer names out of the equation.

    This solution worked great, however it had some issues… HTA display sucks… I was limited to the fonts that MS meant for us to have with the limited browser capability… the display was cheezy to say the least. So this is where I headed down the, "write my own executable" path. I needed a better interface that what HTA could provide. After numerous attempts at C# and .NET I gave up after nearly 100 hours of hacks and attempts… Fortunatley I am versed in numerous languages. My best solution was to use either C++ or Delphi. Both will compile a fully contained executable and give you what you need. Granted this is not optimal, but it does solve the problem.

    Microsoft has a firm handle on what they DO NOT want WinPE to turn into. Becuase it’s free I’m certain that they are worried about someone writing a custom shell and layering it onto a fully viable OS base. This would push people further away from Windows for tirnary installations like KIOSKS… Actually this is quite easy to build with WinPE anyway… It is possible to build a very simple WinPE CD that has Firefox portable browser embedded. You then set the WinPE CD to use Firefox as the shell in WINPESHL.INI and set the default home page to be some .NET Web server. It’s a long way around the block but it works!

    If you need any further assistance I can help… I have tons of experience with WinPE as a deployment tool.

    Stew Basterash


  8. Lee Parker says:

    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?

  9. 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…

  10. 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…

  11. Michael says:

    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.

  12. Deepak says:

    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.

  13. Stewart Basterash says:

    I wonder if anyone in this group who thinks that the .NET Framework should not be included in WinPE has ever tried to build a custom Windows 7 Image? Try it. After primary install of the OS get to the point where one boots into audit mode, where you can make customizations to the image… With no crap running in the background, the OS absolutely RIPS… Installs that take 5 minutes on a typical Win7 box take under 2 minutes in this mode…

    The point that I'm making is that if we had the ability to build a clean bootable Win7 enviroment that had a psuedo gui, or even build your own gui, which I have done, makes a lot of sense for many reasons… I have customized WinPE with a simple menu system that uses a Win32 application framework. This gives me the flexibility I need to include applications, scripts and batch that I require to accomplish my administrative tasks. But I have had a hundered other new ideas that I would love to run with if I had a set of dev tools, like VS Express, to accomplish those tasks… In order for that to work, I need the .NET framework in WinPE… Until then I am stuck with batch and script.

    I am an infrastructure guy, not a developer… I know enough about development to be dangerous, but I need applications to solve real probems… The other problem that WinPE without .NET Framework presents is my inability to run PowerShell in WinPE… This is a contradiction to Microsoft's move toward Powershell as the core scripting tool… But, the reasoning isn't sound… The real reason Microsoft does not including .NET in WinPE is simple economics… If individuals could build their own environments on a FREE base Windows 7 framework like WinPE, it is a very short step off the "who needs Windows 7" cliff…

    I imagine that if I had a bootable, wide open, Win7 framework environment that I could add custom tools to, and keep the OS small, this would be an ideal "thin client". With a bootable OS I don't need to worry about individual utility licensing (anti-virus, spam filtering, etc)… I could virtualize all my applications and have a simple explorer gui where either IE or Windows explorer would do.

    What we really need and want in the 21st centruy is the ability to customize our OS the way we want for every environment we encounter. A single company could have numerous builds for different areas of the business. Imagine if Windows 7 was built like Windows Embedded… We open a build GUI for Windows 7, include the features we want, and we pay ONLY for those features… If you add no components you end up with a FREE WinPE build… Add, .NET framework and you pay… $10 for the OS… and so on… Ala carte Windows… That's the ticket… But the chances of seeing that is about the same as me ordering Cable or Satellite TV with only the stations I want and parying ONLY for that… without all the other junk I don't want. At the end of the day this will solve everyones problems…

    I just think that those who feel that .NET should not be included in WinPE are a bit short sighted and need to think bigger picture. There is much to be gained through innovation if the environment allows for it… Like a comment on Powershell scripting I saw recently… someone asked the question, "Why would you want to use a Forms, approach in a Powershell script"? the answer that was given was simple… "Becuase you can, and it's cool"! But that wasn't the real answer… The real answer boils down to control and utilization. I have a need right now to give first level support personnel the ability to control environmental changes… What better way than to validate information through a GUI form, and then execute through Powershell script… Control and Validation… Simple…

    Stew Basterash

  14. mboy says:

    ms should come with hacking software cause its a pain to find

Skip to main content