RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


The Two Faces of .NET : Page 4

Developing applications with .NET sometimes feels like I'm working with a split personality. Now that .NET has been around long enough, I and many of you undoubtedly have had a chance to put .NET through its paces with some real applications rather than just little samples. For me, the .NET learning curve has been a long one. I find working with .NET both exciting and frustrating at the same time. Talking to other developers I think I'm not alone.

The Unknown
.NET touts easy installation and when you build applications that you have full control over it certainly seems that .NET delivers on this count. You easily can deploy applications as Web applications, Web services, or rich client applications. Rich client applications can take the form of Windows Forms apps running locally or from the Web or as Web Browser controls. Cool, right? Well, not so fast. The Web deployment scenario is certainly clean. You can pretty much create a virtual directory on your Web Server and copy the contents of your Web application into this directory. But for rich client applications, things are considerably more difficult. It always looks so easy in the prospectus.

It seems to me that a policy is needed at Microsoft to document functionality as the specs and the code are created, not afterwards when nobody is around to explain how the functionality is supposed to work.
You can build attractive rich client applications with .NET, but I wonder whether .NET is really the right tool to build vertical or shrink wrap applications with. .NET applications are monsters. Even the smallest.NET applications requires close to 8MB of memory at startup. And startup is slow as the code compiles on the fly. A simple Windows Forms application takes around 12 megs of memory. While memory is cheap these days, it just doesn't seem right to build small utility applications that take this much memory. Especially if you want to have it run all the time as might be the case with a Windows Service. Most administrators would have a fit to have a simple application take 10MB to run when it loads at startup.

Security is also a big issue for shrink wrapped applications. The only environment an application will likely be able to run from once the client gets it is the local machine. If you load an application from the network but you haven't set a specific security policy, the application will run into a host of security violations from any code that tries to access the file system, call unmanaged code (which a lot of code from any third-party provider is likely to do) or access content on the network. While this is configurable via machine and network policies, do you as a software developer/publisher want to be in the business on telling people how to configure their machines just so they can run your application? Security might be an important feature for Microsoft in large IT departments but it's not going to go over well with small businesses or sales to consumers who might want to do something as silly as run the application from a network share via their Wireless connection. .NET might be a sketchy platform to develop consumer or even business end user applications with. Security and security configuration in .NET is a very complex topic—I have three different .NET Framework security books on my bookshelf, each more than 800 pages, and most of it dealing with trying to justify the security features of .NET along with explaining the complex hierarchy of Code Access Security. Security is good, but providing a model so complex that it gets in the way of applications that you need to run can be a problem too. At the very least, Microsoft needs to make the configuration tools easier or .NET should ship with more default policies that you can easily apply to real life application scenarios.

There's also the issue of versioning applications as new versions of the .NET runtime become available. I've already seen that this is not a painless process with the beta version of the .NET 1.1 Framework. If you've built an application using the original version of .NET, upgrading to 1.1 is not as simple as simply recompiling your application. You have to swap out your application references for the new versions of the runtime assemblies. In my applications which are rather simple to boot, not a single application ran under the new version of .NET. Some errors that occurred were changes to parameters and types of VS.NET-generated code that were difficult to track down and fix (and not mentioned in the 'update' documents). In fact, I simply gave up trying to upgrade two applications and I've decided to be content with leaving these apps at version 1.0. Incremental application updates as the platform matures should be relatively painless; instead, you end up with a 'legacy' application that's a pain to bring up to the latest version. This is not how I would envision a great 'deployment story'.

If you've built an application using the original version of .NET, upgrading to 1.1 is not as simple as simply recompiling your application. You have to swap out your application references for the new versions of the runtime assemblies.
Summing Up
I certainly don't want to be a naysayer as I really believe that .NET has accomplished a lot of technical milestones in this first release. It's a very capable development platform and I enjoy working with it. I merely point out a few of the issues that I have run into as a developer myself—I'm sure many of you have many more to add to this small personal list. Some of these things are minor and more annoyances. Others such security and deployment still make me wonder just how viable .NET is for building desktop applications that are shipped to many users.

Yet the trade press is pleased to say how perfect .NET is for every type of application and how well integrated and powerful the environment is. Indeed there are strengths but it is important to also voice some of the shortcomings, if for no other reason than to spur workarounds and solutions and to let Microsoft know that certain things require fixing.

There's so much great information from third parties out there today about .NET—if there's a problem somebody's probably figured it out and found a workaround. Many people are free about sharing this knowledge which is awesome. However, its difficult to find all of this knowledge and ultimately I think its Microsoft's responsibility to provide an out-of-the-box where the information is more accessible via MSDN and the .NET Help.

This is a call for better usability in the tools. For me, this alone is a huge loss in productivity every day as I roll my mouse around the screen for things that should be automatically positioned or handled more naturally. This is also a call to try and keep things simple when they can be made simple. This doesn't mean to give up power, but it means supporting the powerful features with easy to use, common use features that require less code and are more intuitive. This may mean providing simpler ways to subclass existing classes (potential bloat) or sometimes maybe even breaking encapsulation in the class hierarchy chain to provide improved usability for common use scenarios. For a tool that has so much RAD potential it would be a shame to miss this opportunity to provide better developer productivity and reduce the learning curve.

Rick Strahl is president of West Wind Technologies on Maui, Hawaii. The company specializes in Web and distributed application development and tools that focus on Visual Studio. Rick is author of West Wind Web Connection, a powerful and widely used Web application framework for Visual FoxPro and West Wind HTML Help Builder. He's also a Microsoft MVP, and a frequent contributor to magazines and books. He is co-publisher of CoDe Magazine, and his book, Internet Applications with Visual FoxPro 6.0, is published by Hentzenwerke Publishing. Reach him at rstrahl@west-wind.com.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date