ASP.NET

A beginner ASP.NET developer also knows pretty well that each ASP.NET page needs to have a <form runat="server"> tag on the page and that all server controls need to be present inside this tag (although this is not entirely true; you can place server controls outside <form runat="server"> but then they cannot participate in regular ASP.NET functionality like PostBacks, Viewstate etc).

I do not have much time to provide the background, suffice it should be to say that I decided to adopt ASP.NET 4.0 MVC Web Api in a major way today after being in evaluation mode for some days (4.0 MVC was still in Beta as I wrote this).

And so I needed to convert my existing Web Application (WAP) projects to Web Api projects. And I followed a very simple approach to figure out the same. I created a new solution with 2 projects, one a WAP project and the other a Web Api project. I removed all default configuration from both the projects leaving only the absolute essentials behind.

Our designer had created a comprehensive custom theme for ExtJs, and we wanted to use it in our ASP.NET app that leverages Ext.Net and ExtJs extensively.

If you have used Ext.Net, you would know that all ExtJs resources are embedded in Ext.Net.dll assembly that are automatically put on the page whenever you add an <ext:ResourceManager /> to the page. This includes the core ExtJs css and javascript resources (including current ExtJs theme's resources), plus Ext.Net's own resources (providing extensions/enhancements to Ext classes).

One of my most important ASP.NET application in production last week saw a very confusing error. The client reported the following error when they came back to use the application on a fine Thursday morning:

I think all of us would agree that Ext.Net provides too good (and a bit complex) ExtJs and ASP.NET integration. It exposes almost all ExtJs toolkit classes server-side in ASP.NET and many of the popular extensions too. In addition, it provides own custom components that are useful (e.g. MultiCombo, Linkbutton etc).

In this blog post, I present a complete framework for automatic localization in ASP.NET, ability to customize what is produced by this framework and a completely functional ASP.NET app demonstrating the features and process.

A couple of days ago, I started implementing a rather interesting piece of code. It was late into the night, and I was not feeling like doing my regular work and neither was I sleepy. At that time, I was reminded of another project where we needed to provide users the ability to browse and upload files while entering content through the WYSIWYG editor we would provide them.

Okay, here's the second consecutive blog post on serializing/deserializing RSA public/private keys, this time generated by the native RSACryptoServiceProvider available in .Net (the previous post available here related to serializing keys generated by open-source Bounty Castle library).

This is more of a personal blog post I am creating for my own referecne. We have migrated one of our apps from July/August version of Ext.Net (based on ExtJs 3.2.1) to Feb 19, 2011 (Revision 3469) version of Ext.Net (based on ExtJs 3.3.0).

There have been some breaking changes that I am enumerating for my reference so I can use this list when planning migration of other projects. This is a work in progress and I might add points to it as I find them out. So, here are some breaking changes that I have found:

I had earlier written a quick and dirty method to convert a Physical path to a virtual path (aka a url) that can be used on the client after passing through ASP.NET's ResolveUrl method. Without much talking, here's the method: