Have we traded DLL Hell for .Net version hell?
As I set out to write my next software project, my chosen platform is the 1.1 version of the .Net framework. I have chosen it because it is the version supported by Microsoft. And, I like Microsoft's platform and their products. I think that Microsoft has the most user-friendly OS and applications available.
This is not to say that I see no problems with Microsoft platforms or applications. Take .Net for instance...
The .Net platform has been stated by Microsoft to be it's selected toolset for moving forward. Microsoft has stated that .Net will be in every future operating system that is currently under development. .Net is becoming core to technologies like SQL Server too.
Seeing as how .Net is at the core of all new development at Microsoft, I can't, for the life of me, understand the .Net framework not being an automated download of all Microsoft operating systems (at least the systems that haven't been retired which includes XP Pro, XP Home and Windows 2003).
With Microsoft pushing .Net as the next generation development platform for the Windows environment, you'd think they's want every user to be able to run .Net applications. Oh sure, you can download the .Net framework free from Microsoft, but how many regular users know how to do that?
Yes, I know....developers can include the framework in their setups. But, there are sometimes problems with the .Net install when not installing on a "clean" machine. Are developers supposed to do Microsoft's .Net support too?
Then there is the question of bloated installations....especially if you put web-based installations on your website. Forget that Microsoft is asking for a free ride for their 23+MB framework on your installation CDs and simply consider the implications of NOT being able to distribute your application via the internet to your customers because they don't have a high speed connection to download the bloated install of .Net framework plus your application.
50% of US customers still do not have access to high speed internet connections. Can you imagine waiting for a 23+MB install over a modem? I can, and it makes me shudder.
There is a really neat feature of .Net that allows you to publish an application (of limited use if deployed over the internet because of security restrictions) on a server and include it's needed DLLs in the same folder. When the executable is run, it only downloads the parts of the program it needs to run. If it doesn't need a DLL to perform a function that the user is attempting, it just doesn't download it. Why doesn't the .Net framework work like that?
Is it really too much to ask to place a small package in each .Net executable that looks for the .Net version and classes on the local machine and downloads what it needs (and only what it needs) of the .Net framework directly from Microsoft before running?
This would distribute the .Net framework right from Microsoft (with all of the latest patches and hotfixes) while preserving bandwidth by downloading only the needed portions of the framework and you could still distribute your .Net applications from your website.
Yes, I heard you. So .Net will be shipped with the OS, huh? Well, what happens when a newer version of .Net is released? Do you wait 2+ years for it to be on most desktops before using it? That's what it will take to wait for the people to upgrade their OS in the best of scenarios. This very scenario is playing out with versions 1.0, 1.1 and 2.0.
This brings me to the question at hand. Since you may be developing in version 1.0, 1.1 or 2.0, you still have to make sure that your users have the version of the framework that you wrote your code in installed. If you don't ship the .Net install with your installation package, you really can't be sure the customer will be able to run it. And, if you do include the .Net framework in your installation package, *poof* there goes internet distribution.
Have we swapped one hell for another? Not that I even believe there was a DLL Hell...but that's another discussion altogether.
I have found a solution that works for my development shop. It's a little pricey, but if you make a living distributing applications, it is well worth it.
This solution will take your executable (.Net, VB or C++) and all of its dependencies and wrap them all into a single executable. The neat thing is that it even includes the portions of the .Net framework needed to run your executable inside the executable it creates. So, there's no need to distribute the whole .Net framework.
If you use DLLs, your program always uses the right DLLs because they are safely tucked inside your wrapped executable.
Even .Net code is safer because the IL disassemblers can't decode the .Net application inside the wrapped executable! This stuff is just plain cool! (This was my biggest worry about distributing my .Net code. Now I distribute .Net applications freely without worrying about decompilers or losing sales because someone copied my hard work.)
You can distribute database files (also secured inside your wrapped executable) and even do licensing of your application with the built in functionality of the wrapper.
It saves bandwidth too. A simple, single form application with the .Net framework installation will weigh in at 25+MB in an ordinary installation package. In my testing the same application wrapped for distribution weighs in at only 6MB. Small enough for modem distribution.
The wrapped executables can even run with no installation whatsoever! The wrapped executable creates a virtual filesystem, virtual registry entries and has access to all of the physical files and registry entries also. When the app closes there are no residual registry entries or application files/directories - not even temp files. (Of course there are options to place real files in real directories and leave them there if you need to....like for an updatable database application or image editing.)
Since your customers don't have to install .Net to use your application when it is wrapped, and your DLLs are always secure inside your wrapped executable, you will cut your installation support issues to almost nil. The customer simply double clicks your wrapped executable and the application just runs! You gotta see it to believe it.
The drawback? It's kinda pricey for freeware app devlopers. You need to be making money from your apps to make it pay off. Their pricing model is currently under review. They are trying very hard to come up with a licensing model that works well for both large and small development houses. IMHO, it pays for itself in short order if you publish software for a living (which I do).
The wunderware I speak of is Thinstall. You can read all about it at www.Thinstall.com.
Nope....I'm not paid to advertise their stuff. (Not yet anyway.... :) ) I just really love this software! Why can't Microsoft do this?
Damn! What a concept! A development suite that wraps absolutely everything the application needs into one secure executable. No more DLL hell. No more .Net version issues. No more installation issues.
If Microsoft put this into the .Net development suite (a plug-in for .Net is scheduled in the 3.0 release due out late this year) THAT would be a development suite!
I'm not the only one that likes it. Almost every branch of the armed forces uses it along with NASA, Boeing, GE, Lucent....well, you get the picture.
The one endorsement that impressed me the most was the one from Alan Cooper (the "Father of Visual Basic" and author of "The Inmates Are Running the Asylum"). You can read it for yourself at http://www.thinstall.com/help/?customerquotes.htm.
In my humble opinion, .Net framework verisoning is the next "DLL Hell". Thankfully Johnathan Clark and his staff are there with Thinstall to help.
If you do decide to buy it (like I did) mention promotion code jim__hubbard@hotmail.com and Jonathan will knock 5% off the price.
Next....."Automatic downloads in the 2003 .Net Studio. Why aren't they automatic?"
This is not to say that I see no problems with Microsoft platforms or applications. Take .Net for instance...
The .Net platform has been stated by Microsoft to be it's selected toolset for moving forward. Microsoft has stated that .Net will be in every future operating system that is currently under development. .Net is becoming core to technologies like SQL Server too.
Seeing as how .Net is at the core of all new development at Microsoft, I can't, for the life of me, understand the .Net framework not being an automated download of all Microsoft operating systems (at least the systems that haven't been retired which includes XP Pro, XP Home and Windows 2003).
With Microsoft pushing .Net as the next generation development platform for the Windows environment, you'd think they's want every user to be able to run .Net applications. Oh sure, you can download the .Net framework free from Microsoft, but how many regular users know how to do that?
Yes, I know....developers can include the framework in their setups. But, there are sometimes problems with the .Net install when not installing on a "clean" machine. Are developers supposed to do Microsoft's .Net support too?
Then there is the question of bloated installations....especially if you put web-based installations on your website. Forget that Microsoft is asking for a free ride for their 23+MB framework on your installation CDs and simply consider the implications of NOT being able to distribute your application via the internet to your customers because they don't have a high speed connection to download the bloated install of .Net framework plus your application.
50% of US customers still do not have access to high speed internet connections. Can you imagine waiting for a 23+MB install over a modem? I can, and it makes me shudder.
There is a really neat feature of .Net that allows you to publish an application (of limited use if deployed over the internet because of security restrictions) on a server and include it's needed DLLs in the same folder. When the executable is run, it only downloads the parts of the program it needs to run. If it doesn't need a DLL to perform a function that the user is attempting, it just doesn't download it. Why doesn't the .Net framework work like that?
Is it really too much to ask to place a small package in each .Net executable that looks for the .Net version and classes on the local machine and downloads what it needs (and only what it needs) of the .Net framework directly from Microsoft before running?
This would distribute the .Net framework right from Microsoft (with all of the latest patches and hotfixes) while preserving bandwidth by downloading only the needed portions of the framework and you could still distribute your .Net applications from your website.
Yes, I heard you. So .Net will be shipped with the OS, huh? Well, what happens when a newer version of .Net is released? Do you wait 2+ years for it to be on most desktops before using it? That's what it will take to wait for the people to upgrade their OS in the best of scenarios. This very scenario is playing out with versions 1.0, 1.1 and 2.0.
This brings me to the question at hand. Since you may be developing in version 1.0, 1.1 or 2.0, you still have to make sure that your users have the version of the framework that you wrote your code in installed. If you don't ship the .Net install with your installation package, you really can't be sure the customer will be able to run it. And, if you do include the .Net framework in your installation package, *poof* there goes internet distribution.
Have we swapped one hell for another? Not that I even believe there was a DLL Hell...but that's another discussion altogether.
I have found a solution that works for my development shop. It's a little pricey, but if you make a living distributing applications, it is well worth it.
This solution will take your executable (.Net, VB or C++) and all of its dependencies and wrap them all into a single executable. The neat thing is that it even includes the portions of the .Net framework needed to run your executable inside the executable it creates. So, there's no need to distribute the whole .Net framework.
If you use DLLs, your program always uses the right DLLs because they are safely tucked inside your wrapped executable.
Even .Net code is safer because the IL disassemblers can't decode the .Net application inside the wrapped executable! This stuff is just plain cool! (This was my biggest worry about distributing my .Net code. Now I distribute .Net applications freely without worrying about decompilers or losing sales because someone copied my hard work.)
You can distribute database files (also secured inside your wrapped executable) and even do licensing of your application with the built in functionality of the wrapper.
It saves bandwidth too. A simple, single form application with the .Net framework installation will weigh in at 25+MB in an ordinary installation package. In my testing the same application wrapped for distribution weighs in at only 6MB. Small enough for modem distribution.
The wrapped executables can even run with no installation whatsoever! The wrapped executable creates a virtual filesystem, virtual registry entries and has access to all of the physical files and registry entries also. When the app closes there are no residual registry entries or application files/directories - not even temp files. (Of course there are options to place real files in real directories and leave them there if you need to....like for an updatable database application or image editing.)
Since your customers don't have to install .Net to use your application when it is wrapped, and your DLLs are always secure inside your wrapped executable, you will cut your installation support issues to almost nil. The customer simply double clicks your wrapped executable and the application just runs! You gotta see it to believe it.
The drawback? It's kinda pricey for freeware app devlopers. You need to be making money from your apps to make it pay off. Their pricing model is currently under review. They are trying very hard to come up with a licensing model that works well for both large and small development houses. IMHO, it pays for itself in short order if you publish software for a living (which I do).
The wunderware I speak of is Thinstall. You can read all about it at www.Thinstall.com.
Nope....I'm not paid to advertise their stuff. (Not yet anyway.... :) ) I just really love this software! Why can't Microsoft do this?
Damn! What a concept! A development suite that wraps absolutely everything the application needs into one secure executable. No more DLL hell. No more .Net version issues. No more installation issues.
If Microsoft put this into the .Net development suite (a plug-in for .Net is scheduled in the 3.0 release due out late this year) THAT would be a development suite!
I'm not the only one that likes it. Almost every branch of the armed forces uses it along with NASA, Boeing, GE, Lucent....well, you get the picture.
The one endorsement that impressed me the most was the one from Alan Cooper (the "Father of Visual Basic" and author of "The Inmates Are Running the Asylum"). You can read it for yourself at http://www.thinstall.com/help/?customerquotes.htm.
In my humble opinion, .Net framework verisoning is the next "DLL Hell". Thankfully Johnathan Clark and his staff are there with Thinstall to help.
If you do decide to buy it (like I did) mention promotion code jim__hubbard@hotmail.com and Jonathan will knock 5% off the price.
Next....."Automatic downloads in the 2003 .Net Studio. Why aren't they automatic?"
posted by Jim Hubbard at 2:11 AM
6 Comments:
Hi Jim:
Thanks for your post. It was very informative. I have a question for you.
We have been trying for a while now to get an .exe (developed in VB 6) to run over our network but no matter how we twist and turn with permissions, all we get is an error 75. Do you think that "Thinstall" might slove this problem.
Thanks,
Ian
If you keep the thinstall app on a remote Pc and try and run it over the network - probably not.
Error 75 is the "Path/File access error." This error is generally raised when using Open, MkDir, ChDir and RmDir functions.
If you are seeing this error, your program is trying to access resources on a PC (perhaps across your network) that it cannot reach at all or that are "timing out" before the operation can be completed.
While Thinstall would alleviate this problem if ALL files for your application were wrapped together and the resulting executable was placed on each PC that needed to run it, Thinstall will not solve problems of reaching network resources.
Before trying Thinstall, I suggest that you check the availability of the networked resource that the application is trying to reach or use. Are there firewalls or sharing restrictions on the resource being accessed, it's directory or the machine that is "serving" up the resource?
Then, try running the app with the resource on the local PC. If it works with the resource locally available, you have a network issue. Could be timing out on a large piece of data or could be a sharing restriction issue.
Hope this helps.
Hello Jim Hubbard,
I am based in the UK and I stumbled across your post " Have we traded DLL Hell for .Net version hell? ".
I'm quite keen on finding any useful information on dlguard. I found some good stuuf on dlguard but I wondered whether you may have any advice on the best resources out there.
Thanks in advance.
Hi Jim Hubbard,
I see you share my interest in automated download software. Your input would mean a lot to me. If you would be so kind to visit my site and give me your feedback, I would most appreciate it.
Thanks
Hello Jim Hubbard,
I am based in the UK and I stumbled across your post " Have we traded DLL Hell for .Net version hell? ".
I'm quite keen on finding any useful information on secure download. I found some good stuff on secure download but I wondered whether you may have any advice on the best resources out there.
Thanks in advance.
Xenocode Postbuild allows .NET executables to be merged into a single binary that runs natively. Includes integrated code obfuscation, watermarking, optimization, and assembly linking.
Free download.
Post a Comment
<< Home