Introduction
So, it has come time to post my first (potentially last) article on CodeProject. Depending on how this goes, whether I am laughed out of the market or there is interest, there could be a follow up. I am going to be clear up front. There is no code sample in this intro article, therefore it is more of an informational article for anyone who wants to know. Secondly, I have not worked out all of the kinks yet myself; however, the theory is sound. All that this requires is more testing and a small C++ Win32 shim to get started.
Without further ado... let's state what this is about: A "standalone" .NET exe file. I put quotes around standalone, but the file won't actually be able to run by itself. If Windows allowed for in memory loading of complex DLLs from resources, then this might make the exe truly standalone, but alas, Microsoft for some very "good" reasons do not allow the developer to do such a thing.
What I wanted to do was to run a custom branded WPF program on a system running Windows. A minimum of XP is assumed. Since we are running XP, we have to assume that there is no .NET Framework installed.
Now you may be thinking to yourself: "Virtualization! Virtualization!", and while yes, that is an option, this option got ruled out fairly quickly. Thus there is no virtualization voodoo happening in this article.
Background
So like I said.. a custom branded WPF application without installing the .NET Framework. Some people that I discussed this with said: "HERESY!" and for good reasons. Multiple articles and questions posted online said it was not possible. To all these people, I say it is in fact possible with some catches. Let's discuss some options.
When I first started strategizing how to do this, I ran into my first bout with Win32 hooking. This seemed like a good method. Modify the DLL tables, or maybe just hook the required DLLs in process using a CLR host. Then one realizes that hooking is not the do all end all for certain things. Hooking has its ups, but it also has its downs. Like for instance... it is not a 100% rock solid solution. You have to put your tongue at the right angle and hope that in 100% of your test cases, after performing the hooking magic, your solution works. Hooking won't catch 100% of the cases no matter how hard you try in such a complex scenario as this. After about two days of pouring my mind into figuring out how to do this with hooking, this option went off the table.
Next we come to virtualization technologies. For instance, we can look at Boxed app, thin app, spoon studio, and the like. These all seemingly allow you to pack the .NET Framework into a single exe and distribute it and it will just work. There are two issues with this option. The first is stability. Since this method is unsupported, it can be unstable. After taking a look at Boxed app's forums, one of the first posts that I saw was "hey.. my app doesn't work in this scenario". I then looked at how Boxed app does its magic: Hooking! That one liner made me throw Boxed app off the table of options because of the aforementioned reason above about test cases. It turns out spoon studio does the same thing. These virtualization options essentially make a virtual file system on the media and then hook all calls to the Windows registry and file system. Sure it apparently works... They sell the products, but that is not good enough to get my blessing. The second option is that these solutions are not free. Spoon studio costs an arm and a leg. While boxed app is more affordable.. it's not free. I won't be shelling out money for a solution that relies on hooking.
Read more: Codeproject
QR: 