This post originated from an RSS feed registered with .NET Buzz
by Darrell Norton.
Original Post: Why should you move to ASP.NET 2.0?
Feed Title: Darrell Norton's Blog
Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx
Feed Description: Agile Software Development: Scrum, XP, et al with .NET
Someone recently contacted me via my blog and asked some good questions on whether to move to ASP.NET now since 2.0 is coming out soon. I think these answers are generally helpful, so I'm posting them here.
I have been a web developer for about 7 years. I do most of my work with PHP although I have used Classic ASP, as well as some Java/Servlet stuff. I have been looking into ASP.NET and have tinkered around with a little coding in VB.NET. I have never used VB before but it seemed like Visual Studio .NET works best with VB.NET with the Intellisense and whatnot. As I have been reading up on ASP.NET it looks like the 2.0 release is really going to change things.
1. Should I wait to get involved in .NET until the 2.0 stuff is release? Well all my 1.1 knowledge be outdated and useless when 2.0 comes out? Will 1.1 apps still run in a 2.0 environment?
Learning ASP.NET 1.1 is not a bad thing. If you learn ASP.NET 1.1 you will be able to support all ASP.NET web sites out there (the differences between ASP.NET 1.0 and 1.1 are minor). Microsoft has also written a detailed guide on Migrating from ASP.NET 1.x to ASP.NET 2.0. ASP.NET 2.0 will also be fully backwards compatible with ASP.NET 1.1. So there wonât be a big âconversionâ effort, you can just start new sites in ASP.NET 2.0 once it is publicly available. If you really want to wait until ASP.NET 2.0 and since youâve mentioned you have done ASP development before, there is a guide written on Migrating from ASP to ASP.NET 2.0.
You can work with ASP.NET 2.0 now using the Visual Web Developer Express beta, but realize that it is in Beta and has not been fully completed. It is also important to realize that there is not a âgo-liveâ license associated with the Beta version. Microsoft recently has given a go-live license to Beta 2 of a given technology.
2. From the brief amount of time I have spent programming .NET (I use Visual Studio .NET 2003) it looks like all the code behind files get compiled into 1 dll. This is a neat idea but the problem I had was that if I am wokring on several different parts of the site at once then compiling the whole site to make one little change is a huge pain. For example, I was making a simple project management application that would let me keep track of my projects and the tasks for each project. I got everything working, compiled my code behind files into one dll and published my application to the server. Then I started working on another feature of the application that would let me email reports of my logged time for each task to my clients. As I was working on that, I realized that I had a little problem with my application and needed to adjust edit task function a little. This was just a minor adjustment that would have taken about 5 mins to fix. The problem was that I had all this unfinished code for emailing reports that wasn't ready to compile. So I ended up going through the new files and I "excluded" them from the project which was a huge pain. Then a made my little update to the edit task function, compiled, and uploaded my .dll. Then I had to go back an include all my new files back into the project. It was this incident that caused me to really rethink this .NET thing and seek some advice form someone who has more experience than I have. How do you avoid this problem? Do you use VS.NET and code behind?
The compilation model has changed in ASP.NET 2.0. The full details can be found here, but basically you have 4 options:
ASP.NET 2.0 offers four different compilation models for a Web application:
Normal (ASP.NET 1.x)âIn a normal ASP.NET Web application, the code-behind files were compiled into an assembly and stored in the /bin directory. The Web pages (ASPX) were compiled on demand. This model worked well for most Web sites. However, the compilation process made the first request of any ASP.NET page slower than subsequent requests. ASP.NET 2.0 continues to support this model of compilation.
Batch-compilationâIn ASP.NET 2.0, you can batch-compile any application with a single URL request. As with ASP.NET 1.x, batch compiling removes the delay on the first page request, but creates a longer cycle time on startup. In addition, batch-compilation still requires that the code-behind files are compiled pre-deployment.
Deployment pre-compilationâA new feature of ASP.NET 2.0 allows for full compilation of your project prior to deployment. In the full compilation, all of the code-behind files, ASPX pages, HTML, graphics resources, and other back-end code are compiled into one or more executable assemblies, depending on the size of the application and the compilation settings. The assemblies contain all of the compiled code for the Web site, and the resource files and configuration files are copied without modification. This compilation method provides for the greatest performance and security, at the cost of removing all of your ability to modify the Web site post-deployment. If you are working with highly visible or highly secure Web sites, this option is the best choice for final deployment. However, if you are building a small site running on your local intranet, and the site changes frequently, full pre-compilation may be overkill.
Full runtime compilationâAt the other extreme of deployment pre-compilation, ASP.NET 2.0 provides a new mechanism to compile the entire application at runtime. That is, you can put your uncompiled code-behind files, and any other associated code, in the new code directory and let ASP.NET 2.0 create and maintain references to the assembly that will be generated from these files at runtime. This option provides the greatest flexibility in terms of changing Web site content, at the cost of storing uncompiled code on the server.
Code-behind has also changed in ASP.NET 2.0. ASP.NET 2.0 takes advantage of partial classes to create a different coding model that many are calling code-beside (since you have 2 classes, or really partial classes, that work together instead of using inheritance), but Microsoft is still calling code-behind. Find out more detail on the coding models.
Both of these taken together, along with a better source code control tool and configuration management (branching your code would have solved the main part of the problem) would address all of the issues you had.
And yes, I do use Visual Studio for all my .NET development.
3. Do you have any thoughts about whether I should bail on VB.NET and instead start doing C# development? I visited the site that you link to about converting VB.NET code to C# and that site seemed to suggest that C# was a much better language. I have also read that if you aren't sloppy about how you write your VB.NET code and use Option Strict and so forth then there really is no difference other than syntax. What thoughts do you have about this? I read your website about how the language doesn't matter when it comes to performance but what about when it comes to using VS.NET? Do you think VB.NET is the better language in terms of using it with VS.NET?
Whether you choose VB.NET or C# is a matter or personal opinion. While I prefer C#, I can code almost as well in VB, and would choose VB if I had to do any Microsoft Office development. Both languages are starting to diverge in the 2.0 version of the Framework, so you might want to look into the new features of each language to see if there is any compelling reason to choose one over the other specific to your situation. Check out these articles on new C# 2.0 features and new VB 2005 features.