A coworker introduced me to Anthem.NET, which is an AJAX library for the ASP.NET platform. Within the last year or so, quite a few AJAX libraries have surfaced, including Microsoft’s ASP.NET AJAX (formerly known as ATLAS), and other free and commercial products. Some of these are pretty decent, while others are not even worth investigating. Anthem.NET, with it’s impressive functionality, belongs to the former group.
Some of the features of Anthem.NET include:
- Free and open source
- Support for .NET 1.x and 2.0
- Seamless integration with Visual Studio 2005
- Broad browser support (IE, Firefox, and Safari)
- Support for Mono
- Familiar ASP.NET postback style functionality
- Support for ASP.NET ViewState
- Support for web user controls
You can download Anthem.NET from SourceForge.
Up until Visual Studio 2005 and .NET Framework 2.0, the actual build process of solution or project files was pretty much a black-box phenomenon for developers. With .NET Framework 2.0 and Visual Studio 2005, Microsoft unveiled its new build platform called MSBuild. MSBuild essentially provides a transparent build process through Visual Studio IDE, as well as allows developers to build projects and solutions from the command line. This allows us to fully customize our builds and create builds on machines where Visual Studio is not even installed.
On a recent team project I was using continuous integration or CI (an Agile practice) via CruiseControl.NET. It was a breeze to automatically build projects and solutions using MSBuild on our build server (a run-of-the-mill Dell workstation running Windows XP without Visual Studio 2005 installed) whenever someone checked-in any files to source control. This allowed us to be confident at all times that various pieces our distributed project integrate well. Moreover, since MSBuild can build projects and solutions from command line, I had some batch files setup that would build release versions of our projects, create setup files (using NSIS), archive older versions of setup files, and move new setup files to a network share where MIS / Operations folks could install the new version on the production server from.
In Visual Studio 2005, project and solution files are nothing more than MSBuild XML build scripts. This allows us full control over the build process. For example, in a web project, Visual Studio 2005 does not provide any user interface to modify pre and post build actions. However, since solution file is simply an MSBuild script, we can modify such actions manually by opening up the solution file in any text/XML editor.
MSBuild can perform several key tasks out of the box. Each task is essentially a unit of work (UOW) that contributes to the entire build process, e.g. copy files and folders, compile files, etc. If we ever require tasks that do not ship with MSBuild, we can always create custom tasks in any .NET language by simply implementing the ITask interface or deriving from the Task class.
In conclusion, MSBuild allows developers full control of the build process so that builds can be fully customized. This may not be so crucial in smaller projects, but for enterprise solutions that typically comprise of several projects and many dependencies, MSBuild is definitely a God-send!
I recently posted about how the lack of project files in Visual Studio 2005 Web Site Projects make it difficult to deploy web applications.
I just came across this add-in for Visual Studio 2005 that actually addresses this very issue. It’s called the Visual Studio 2005 Web Application Projects (WAP) and is available as a free download from Microsoft. WAP provides following features to ASP.NET 2.0 Web Site Projects in Visual Studio 2005:
- A project file that contains references to all web content as well as any assembly references.
- Compilation into single assembly that is built into the bin folder.
- Pre and Post Build actions.
While WAP is aimed at developers converting web applications from Visual Studio 2003, I think that it’s an invaluable tool for anyone creating web applications using Visual Studio 2005.
Microsoft screwed up royally in Visual Studio 2005 when it comes to deployment of web projects. It seems like they initially assumed that everyone would use web site publishing feature for deployments, but that certainly is not the case. Later they came up with the Visual Studio 2005 Web Deployment Projects (WDP) add-in hoping to rectify their oversight, but WDP is nothing more than a lame bandage over a broken bone. The departure of project files from ASP.NET projects serves as an icing on the cake! And what exactly were they thinking when they decided that web projects can’t have any more than two build configurations (Debug and Release)?
While I really like .NET 2.0 and Visual Studio 2005, I just can’t come to peace with the fact they did not think through deployment features of ASP.NET projects.
