My friends lament how I’ve turned coat against the Java establishment and joined the ranks of Microsoft. For the past few years, I’ve enjoyed a model of efficiency that I hadn’t had since the early days of Java. Back then code was king, and writing software quickly and smartly is what made Java such a hit.
When .NET was released, it was 1996 all over again for me. I could write code quickly, and so I did. As a result, many products I did develop, and many of which were libraries that would be incorporated into future products. Like many Java to .NET’ers, I didn’t really understand the implications of the Microsoft’s library versioning, so I did not establish a clear version protocol for my early work.
Yesterday, that lack of foresight was my undoing. After 8 hours of fighting with ASP, I finally got my application to work. This was all the result of a minor bug fix in a core library that is used ubiquitously. Additional products of mine that are incorporated into my client’s projects were also affected by this bug fix, so I had to update them as well, and so on.
In the realm of .NET 1, this was very easy to do. ASP.NET in version 1 was good about letting you decide what libraries would go into your web application. I call that WYBIWYG, or “What You Build Is What You Get.” That’s a great thing for programmers, because we tend to have lots of junk on our development machines for other clients and projects.
In the world of .NET 2, though, it is different. Microsoft has “fixed” ASP so that it can load libraries from the GAC (shared library space) as well as from a local bin directory. Unfortunately, you specify libraries using the configuration file of the web application or just plunk them into the project output directory. But that really doesn’t work. You have to use the VS.NET 2005 IDE to figure out how to include the external libraries into your project output, which doesn’t work either. All that ever did was cause the ASP worker process to “terminate unexpectedly.”
If you try to include libraries into your project, and they turn out to also be registered in the GAC, then they will be included as GAC libraries in your web configuration file. When you go to deploy the web project, they aren’t in the deployment output because they are assumed to be in the GAC of your server. That’s not always the case when you have a variety of projects hosted on the same server.
From all of this, I concluded that ASP.NET 2 is not WYBIWYG compliant because it includes “phantom” library references that you can not override with any measure of determination. You simply are forced to install your libraries into the GAC and hope that they do not conflict with any other projects on the server. That, in the Java world, is considered a dirty deployment, tantamount to sticking your library jars in the “ext” directory (no no!).
I like .NET and will continue to espouse its efficiencies and support, but I can not say the same for ASP.NET 2. The Java Enterprise platform is much more friendly to developers because you can truly get WYBIWYG (except in early versions of JBOSS) for your projects. That, my friends, is peace of mind.
When .NET was released, it was 1996 all over again for me. I could write code quickly, and so I did. As a result, many products I did develop, and many of which were libraries that would be incorporated into future products. Like many Java to .NET’ers, I didn’t really understand the implications of the Microsoft’s library versioning, so I did not establish a clear version protocol for my early work.
Yesterday, that lack of foresight was my undoing. After 8 hours of fighting with ASP, I finally got my application to work. This was all the result of a minor bug fix in a core library that is used ubiquitously. Additional products of mine that are incorporated into my client’s projects were also affected by this bug fix, so I had to update them as well, and so on.
In the realm of .NET 1, this was very easy to do. ASP.NET in version 1 was good about letting you decide what libraries would go into your web application. I call that WYBIWYG, or “What You Build Is What You Get.” That’s a great thing for programmers, because we tend to have lots of junk on our development machines for other clients and projects.
In the world of .NET 2, though, it is different. Microsoft has “fixed” ASP so that it can load libraries from the GAC (shared library space) as well as from a local bin directory. Unfortunately, you specify libraries using the configuration file of the web application or just plunk them into the project output directory. But that really doesn’t work. You have to use the VS.NET 2005 IDE to figure out how to include the external libraries into your project output, which doesn’t work either. All that ever did was cause the ASP worker process to “terminate unexpectedly.”
If you try to include libraries into your project, and they turn out to also be registered in the GAC, then they will be included as GAC libraries in your web configuration file. When you go to deploy the web project, they aren’t in the deployment output because they are assumed to be in the GAC of your server. That’s not always the case when you have a variety of projects hosted on the same server.
From all of this, I concluded that ASP.NET 2 is not WYBIWYG compliant because it includes “phantom” library references that you can not override with any measure of determination. You simply are forced to install your libraries into the GAC and hope that they do not conflict with any other projects on the server. That, in the Java world, is considered a dirty deployment, tantamount to sticking your library jars in the “ext” directory (no no!).
I like .NET and will continue to espouse its efficiencies and support, but I can not say the same for ASP.NET 2. The Java Enterprise platform is much more friendly to developers because you can truly get WYBIWYG (except in early versions of JBOSS) for your projects. That, my friends, is peace of mind.