All controls that inherit from ListControl (BulletedList, CheckBoxList, DropDownList, ListBox and RadioButtonList) have some annoying behavior in common:

You can only bind the control to a single property using the DataTextField property. For example, if you have a Customer class with properties Id, Name, Surname, etc and you want to show the full name of a customer in any of the ListControls, you have several options:

1. When you get the data from the database, return another column with the name and surname.
2. Create a property (f.e. FullName) that returns what you want to show.
3. Use a DataSet and add a computed column.
4. Manually add ListItems with the appropriate values performing the data bind manually.
5. Create a simple class that will be bound (instead of the original one) just to fix the problem.

The truth is that I don’t like any of those options, all of them are hacks.

For nested properties you have the similar problems. You can bind to Id or Name, but you can’t bind to Address.City or Address.Zip.

Today I faced this problem again and I decided to investigate a more innovative solution. The problem itself is in the controls that inherit from ListControl that are very strict in the binding options. So I took a look of how the controls perform the binding to see if I could do anything to overcome those limitations. At first sight I thought I was loosing my time but after a deeper study I found that it was amazingly easy to fix those problems in a very sleek way.

The data binding of the controls is performed in the PerformDataBinding method. The code at ListControl.PerformDataBinding uses DataBinder.GetPropertyValue to retrieve the value to show in the control if you set the DataTextField property. However, DataBinder.GetPropertyValue doesn’t handle nested properties. DataBinder.Eval is a better choice because it does handle nested properties. So using it we solve one problem. The other problem can be solved easily as well. As we have two properties that control how the Text of each ListItem will be extracted and shown from the data source, with a bit more of effort we can handle the new functionality. I have come up with a very intuitive solution:

• DataTextField allows one or more properties (that can be nested if needed) separated by commas.
• DataTextFormatString can be used to control the formatting of the items, using {0}, {1}, {2}, {3}… as the value of the properties specified with DataTextField.

The code that performs the data binding is:

As we need to call this data binding code instead of the one from ListControl I needed to subclass all controls that inherit from ListControl in order to fix them. So now I have BulletedListEx, CheckBoxListEx, DropDownListEx, ListBoxEx and RadioButtonListEx.

I have created a simple example showing how to use them. Imagine that an Item can be supplied by a set of suppliers, and each supplier sells the item with a different price. The following image shows the properties of the 3 entities of the sample:

I have created a web page with a DropDownList with some items, and when you select an item in the DropDownList you will see a ListBox with the all suppliers of that item with the associated price for the item. Notice how I show the Id and the Name in the DropDownList and how I show the price, supplier Id and supplier name in the ListBox:

The ASPX of the page follows:

As you can see, the solution is really clean and elegant, and backward compatible with the current controls that inherit from ListControl.

That’s all for now,
Merry christmas!

ListControlsEx_bin.zip (6.53 KB)

I have been using Josh Twist’s XHTML validation module for a while and I have added a couple of small enhancements I have found useful:

• It works without internet access as I included the required DTDs as embedded resources. I usually have internet access when I’m using it, but it is a big problem if I don’t.
• It doesn’t validate ASP.NET trace output if it is present in the page. This is checked using the trace configuration section. I have not found a way to know if trace output is enabled in the current request.
• I have added an attribute called showErrorsOnly to the validatorModule element to avoid calling the Renderer.Render method if there isn’t any error. That way, if the page validates successfully no message is shown.

Download validator_binaries (42,78 KB)

Downlaod Validator_source code (44,04 KB)

The changes from v1.2 to the current one (v2.0) are:

• Now using NHibernate 2.0.0 CR1.
• Fixed a bug that caused the provider to look for the configuration settings only in the nhibernate config section. If you configured NHibernate using the hibernate-configuration section, it didn't work.
• Fixed a bug that prevented hashed passwords to work without supplying a password answer.
• Some code refactoring/clean up.
• Removed all FXCop warnings.
• Changed the mapping generation for the NHCustomMembershipProvider. In NHiberante 2.0.0 CR1, it is not possible to create mappings programatically as before, so now a xml document with the mapping is created.
• Fixed a bug in ChangePassword and ResetPassword methods that made the stored password answer useless if the provider was using hashed format with password salt.

From some questions/emails I've got, it seems that some people aren't using the provider the way it was designed. There is no need to modify the code in the provider to support custom fields for your Users or Roles. I have created a sample that uses all the fields in the membership provider and adds some custom fields to show how the provider should be used. The sample also uses the CreateUserExWizard control in order to create an user.

As always, feedback is welcome. It has been tested only in SQL Server 2005. Let me know if you try it in other databases.

The binaries and source code can be downloaded here

One of the tools I’m using is NDepend (http://www.ndepend.com/). It is a cool application that can be used for a lot of things, as will be detailed later.

To use NDepend you have to feed it with a set of assemblies. After that, it will analyze those assemblies and their reference assemblies. If the PDBs of the assemblies are available it will use them so more data is analyzed, although the PDBs are not needed for NDepend to work.

After the analysis has been completed, NDepend looks like this:

I have used version 1.1 of Spring.NET Framework (http://www.springframework.net/) for the sample. As you can see the application has a beautiful GUI. I’ll talk a bit about the main windows of the tool:

• Metrics: this window gives a graphical high level view of the project. You can see a lot of ellipses and some of them that are made of smaller ellipses. The big ellipses are types of the project. If a big ellipse is made of several smaller ellipses, those smaller ellipses are the methods of the type. The types of the same namespace are distributed in the same rectangular region, separated by a small yellow line. The assemblies are separated by a thicker yellow line.

By watching this window you can get an idea of which assemblies contain more code, which types are big, which types have a lot of methods, etc. The window was in “Method Level”. The available levels are Assembly, Namespace, Type, Method and Field.

• Class Browser: this is where the assemblies of the project and its referenced assemblies are shown. You can expand the assembly up to the field level. While you hover over an item in most windows, the Metrics window gets updated highlighting the hovered item.

What it’s really cool about the Class Browser is that for the referenced assemblies, only the namespaces, types, methods and other items that are used by the project are shown.

• Info: When you hover over an item the information about it is displayed here, with some metrics if applicable. There are a lot of metrics so it can take time to interiorize them and judge their value appropriately.

• Dependencies: this window is a bit intimidating at first but like a lot of things, with a bit of effort you can master it. The window displays very important information of the dependencies in a matrix form. As in other windows, the detail level is selectable, from the assembly level to the field level.

A cell can have 3 colors. Blue means that the associated item in the top header uses the associated item in the left header. Green means that the associated item in the left header is using the associated item in the top header. Black means a cyclic dependency. The blue and green cells express the same dependency using opposite points of view.

You can see a diagram of the dependencies clicking on a cell. For example, if you click in the cell corresponding to System.Web.Extensions and System.Web you get this:

To read more about the theory of dependencies take a look here:

ttp://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies

• CQL Queries: CQL stands for Code Query Language and it is a central piece of NDepend. Being able to ask questions about the code is great. If you like using the Analyzer window in Reflector you’ll love this. You can create new queries and modify the existing ones.

I have presented the main NDepend windows, but the main question is: what you can do with NDepend?

There are several uses that I can think of:

• It is an excellent tool to check differences between different builds of an assembly. You can use it as a diff tool, as it will show in the Class Browser which types, methods, etc have been added, removed or changed. This information is also available for CQL Queries, with the power that it implies.

• It can be used to understand code. When you are thrown with code that you have no clue about how it works you have several options to accomplish that task:

1. Look at the source code directly.
2. Make some diagrams from the source code (for example, using View Class Diagram in Visual Studio).
3. Use NDepend.

These methods are not exclusive, and probably you’ll use a combination of them to understand how the code works. However, the abstraction level is higher when you use NDepend is higher than when you use a Class Diagram (and a Class Diagram is a high level view compared to raw source code).  I’d use NDepend to have a global vision of the main assemblies, type most used, dependencies between namespaces, more complex methods, etc. and then focus my attention in the most important parts of the application, going to a lower level of detail.

• It can be used in the refactoring process, to see the impact of a change, and to keep dependencies to a minimum, in order to have a project that is easier to understand and maintain.

• Integrating NDepend in the software development process. IMHO this is a key point, as using NDepend regulary will certainly improve the quality of the software that is being developed.  NDepend can generate a report of a project. A sample report is available here:

http://www.ndepend.com/SampleReports/OnNUnit/NDependReport.html

There are a lot of sections in the report, but I’ll concentrate on the section called “CQL Queries and Constraints”. That section is really important as it shows a list of items that can be problematic or don’t follow the standards of your company (methods with a lot of lines of code, very complex methods, poorly commented methods, types or methods or properties or fields with incorrect naming conventions, etc). This way the project leader can make periodic checks of those problems and report them to the people that are responsible for them.
This also allows you to know more the people you’re working with. Some developers don’t comment code, others like to make very long methods, and others tend to write complex logic that is difficult to understand by others. With the review of the report, they can be instructed so the resulting code and comments is better and more uniform.

However, there are times where a method with more than 30 lines of code is necessary. Or a method with a cyclomatic complexity of 25 is needed. So it is up to the project leader to review the suspicious method and inform the developers of the problem or simply acknowledge that it is necessary.

Unfortunately, NDepend does not provide built in support for this level of detail of project management. I have been told that in a future version it will provide hooks so custom scenarios like the exposed above are fully supported.

So, after what I have said about NDepend, you can be thinking, is it for me? Well, that depends on a lot of factors. I know a lot of companies that have no interest in achieving high quality products and that they only care about having a project done as soon as possible. If the maintenance of that project is a nightmare, well, that is another problem for another moment. However, there are some companies that actually spend time and effort to produce excellent products, so they may be interested in what NDepend can add for them.

I have used NDepend in several projects that are widely used when learning about it, and I found something curious:

The image shows that almost all of the NHibernate code has a big dependency cycle. I wish them good luck making the transition to ASTs.

To finish this post, I have to say that I have received a free professional version of NDepend. This has not conditioned my post about it. If I think it was a useless product I will not have posted about it.

One of the tools I have been using is Selenium. Selenium is a test framework for web applications. Selenium is composed of 3 different projects:

• Selenium Core: A set of cross browser javascript classes that contain the test framework.
• Selenium IDE: A FireFox plugin that allows creation, recording and editing of tests for Selenium.
• Selenium RC: A web server and a set of classes to allow integrating Selenium tests in test applications like MbUnit.

To illustrate the concepts I’m going to use a sample. I have a control called ListControlMediator, that is used to connect two DropDownList controls in order to move ListItems from a DropDownList to the other. It can be used to reorder ListItems too. The following image shows two DropDownLists with a ListControlMediator:

The identifier is shown near the controls on the page.

The ListControlMediator can work in server side mode, performing a postback each time a button is pressed. However, it also has a client side mode that uses javascript to avoid postbacks. So I want to write some tests to check that the control works properly in client and server side mode, using IE and FireFox.
 
The first thing will be to create a page to perform the tests, as the one shown above. The only functionality of the page shown above is the action to perform when the “Send” button is clicked.  When the “Send” button is clicked, the text of the items of the ListBox2 is shown in the lResult label (separated with spaces).

The second thing to do is to create a test of the web page. In this step, there are two main options:

• Create the test by hand.
• Record the test with the Selenium IDE.

I usually record the test with the Selenium IDE and then adjust it a bit. To use the Selenium IDE just open FireFox and select Tools->Selenium IDE. Use the record button to start recording actions:

For example, after some actions in the page I got the following actions recorded:

As you can see, an action can have up to 3 attributes: Command, Target and Value. If you click on an action, you can select a command from the combo box. There are a lot of commands available, but you can learn them when you need them. The reference at the bottom of the Selenium IDE shows the help for the selected command, and the arguments it takes (Target is the first argument and Value is the second argument).

A cool thing about the Selenium IDE is that it adds an option in the FireFox context menu called “Show All Available Commands”. When you right click in an element of the page, it will show a list of the most common commands that can be applied to that element. That is very helpful for newbies.

After a test has been recorded, we can save it to replay it later (using File->Save Test). As a test is not more than a list of actions, and an action can have up to 3 attributes, tests are saved as HTML pages with a table. Each row in the table is an action, and has three columns, one per attribute of the action.

Once you have some tests saved, you can use the Selenium core to test them. Several tests are grouped in a “Test Suite”. A test suite is also an HTML file with a table, where each row in the table has only one column, where a link to the test of the suite is specified.

To use the Selenium core you will have to copy the “core” directory of the selenium core distribution to the root folder of your website. In the selenium core distribution, there is also a directory called “tests” where there are a lot of tests of a test suite. Create a directory called “tests” in the root folder of your website and copy the TestSuite.html file found in the “tests” directory of the selenium core distribution. Edit the TestSuite.html file, leaving only a row in the table that points to the test saved with the Selenium IDE (copy the saved test to the “tests” directory of your website). Some tests may not work in some browsers, so you can add that information to the row. For example, if you add unless="browserVersion.isSafari" to some rows and you try to run the tests using Safari, those tests won’t be executed.

To run a test suite using the Selenium core you have to point the browser to the /core/TestRunner.html page:

And select the test suite to run on the left. After the test suite has been selected, the tests contained in the test suite are shown on the left. When you click on a test the top center part of the browser shows the actions of the selected test. In the right there are some controls to run the tests. The bottom part of the browser is where the test will be run:

The TestRunner.html page accept some parameters to select the test suite, run the test automatically, etc, but the truth is that we use Selenium RC we won’t need to mess with the TestRunner anymore.

To use Selenium RC for our web tests we don’t need to copy the core or tests from the Selenium Core distribution.

Selenium Remote Control (RC) is basically a web server and the ThoughtWorks.Selenium.Core.dll assembly.

The selenium server is used to open browser sessions and is also a proxy. When the server opens a browser session it configures the browser to use the selenium server as a proxy. The selenium server injects the test framework for the pages it uses, capturing all requests to /selenium-server/ so they return stuff from the Selenium Core, making the page under test to be able to use the Selenium Core transparently without Javascript origin policy problems.

The ThoughtWorks.Selenium.Core.dll contains types to interact with the Selenium Server, so with .NET code we can create new sessions, and perform actions with it, testing our web sites with real browsers, using our favorite testing framework (MbUnit in my case).

To start the Selenium Server you need to have JRE 1.5.0 or higher installed and type:

java.exe -jar selenium-server.jar

The server listens to port 4444 by default.

However, to automate this I have added Assembly level SetUp and TearDown methods to my web tests so the server is started before all the tests and shutdown after the tests:

From .NET you have to use the DefaultSelenium class to create a browser session. In my tests, I have a base class for web tests that has a SetUp and TearDown methods that automatically open a close a browser session:

ServerUrl, ServerPort and BaseUrl are read from the application configuration file. The Browser property is passed to the constructor of the base class for web tests.

The actual test should use perform actions in the browser session that has been opened in the SetUp method. The Selenium IDE has an option to save a test in C# format, that converts an action to a call to the browser session object, so it can be used easily from code.

Let see some code of a test (don’t try to compare it with the example of the Selenium IDE, it is different):

As you can see, it is just another way to express the actions.
 
Some thing to clarify is the CheckPageError method. Unfortunately if an ASPX page throws an exception, the assembly ThoughtWorks.Selenium.Core.dll does not throw that exception and returns OK. This is because the Selenium Server requests a page and receives a response, so it doesn’t see any problem. This is very unfortunate and I hope it will be fixed in future releases. For now what I’m doing is to check if the body of the page starts with “Server Error”. This works for me because my test website doesn’t handle custom errors and the default error handling is displayed. You may have to create your own custom CheckPageError method.

Another thing that doesn’t work as I’d expect is the Selenium.GetSelectOptions method. If the select element is empty, it returns a string array with one item that contains an empty string instead of returning an empty string array. Hopefully this will be also fixed in the future.

Note that to be able to run the tests with Selenium RC you’ll probably need to use IIS instead of the built in server of Visual Studio.

I usually test my stuff in IE and FireFox. I inherit from the class where the test methods are defined as shown here:

If you want to test with more browsers probably this will get ugly and you will have to work out a better way to run the tests without inheritance.

To test the Server Side mode in the ListControlMediator, the only required changes to the test method is to place Selenium.WaitForPageToLoad instructions after each click, so the Selenium Core waits for the postback to complete before continuing processing the test.

I hope this helps some people to enter in the world of real web tests.

If you have worked with the design time infrastructure you will know that there are parts of it that are poorly documented.

To complement MSDN help and internet searches you can try another source of information: patents.

Most big companies like to patent a lot of stuff so I stumbled upon this patent that has some good information about design time. The inventors of the patent are:

• Andrew Cheng-Min Lin
• Bulusu Krishna Mohan
• Nikhil Kothari
• Simon Calvert

Does any one sound familiar to you?

Anyway, nothing beats using reflector to figure out some of the more obscure interfaces. Unfortunately, it is also the slowest method.

From time to time I like to evaluate the way I’m working, investigate on new alternatives, try other approaches, etc. in order to improve the way I do things. Other times, I have to change the way I do some things by necessity. This time was a bit of both. The number of components I’m selling on my web page www.manuelabadia.com is growing slowly and some things I was doing by hand were a pain to maintain and started to take too much time, so a change was really needed. Also, in the development area, things were also getting more complex.

Distribution of the components by mail is a lot less reliable than I thought as some companies have really strict firewall/attachment policies. Implementing a decent LicenseProvider based on digital signature was more complex than I thought, has some hurdles with ASP.NET and works a bit different between web site projects and web application projects. However, having the LicenseProvider implemented has freed me of all component distribution and signing, saving a lot of time and headaches.

Maintaining and developing new components was also getting more complicated, because components were starting to share code, and having to maintain two versions of the same code is problematic and error prone. However, splitting the components in several projects and then using ILMerge seems to work great. Improving my subversion merge/branch skills was also necessary as I end with a lot of releases with a very similar codebase but with little differences between them. Better tool integration for ordinary tasks with Visual Studio has also helped a lot. I’ll comment about a few of these tools in a future.

There seem to be a lot of good tools emerging with a goal to improve the quality and reliability of our code. Microsoft research is also trying some things with Spec# and Pex. Maybe I’ll blog about those when Pex becomes available to the masses.

So what about the future? Well, I have a lot of ideas for new components and new features for the existing ones. As always, the biggest problem is time. There’s no time to do all the stuff I have in mind or the cool things I want to try (has anybody tried SharpMap?) I have a component in the works that has been nearly finished for a couple of months. I hope to finish it at the end of the year or in January 2008. After that probably I’ll concentrate on further improving the existing components and checking if something new can be added if the version of ASP.NET shipped Visual Studio 2008 has a couple of significant changes. After that probably I won’t release more components because I can’t be sure to be able to provide a good service if I release more components.
 
As I said before, the sales are growing slowly, and the components are being used in most of the “important” countries:

This shows me that I’m doing things well and encourages me to work harder and keep improving my skills.

Due to lack of time I haven’t been able to make a sample website showing a complete usage scenario for my NHibernate custom Membership and Role providers. However, as there are nearly 100 downloads per month and there is some people using it I’m uploading a new version. The changes from the latest release are:

• Fixed an important bug that didn’t prevent locked out users from login in.
• Added a CreateUserWizardEx control that allows creating a user with extra information in an easy way.
• Added auto unlock support.
• Fixed some minor bugs/typos.

I’ll detail a bit the new features. The standard CreateUserWizard control generates an event before creating the user (CreatingUser) and one after the user has been created (CreatedUser). Somewhere between these two events the control calls the CreateUser method of the membership provider. The CreateUserWizardEx control extends the CreateUserWizard that ship with ASP.NET 2.0. It is supposed to be used when you want to insert a user in the system without using the CreateUser method of the membership provider (for example, because you want to store more data in the database).
 
The CreateUserWizardEx control adds a CreateUserEx event. You should handle this event, retrieve all the information for the new user and make the insert in your users table manually (as the provider interface can’t handle extra data). This event will be generated after all the password checking and generation have been made, so you only have to insert the user in the database. When you handle this event, you’ll be passed an instance of the CreateUserExEventArgs class. This class has 3 properties: EncodedPassword, EncodedPasswordSalt and EncodedPasswordAnswer that are useful if you’re not storing the sensitive data in plain text. After the CreateUserEx event is generated, the CreatedUser event is also generated.

There is one little problem with the CreateUserWizardEx control. Because quite a bit ASP.NET classes (especially controls) haven’t been designed with extensibility in mind, it is impossible to override some of the behavior of the CreateUserWizard control to achieve the desired result. In this particular case I can’t make the control to skip the CreateUser call to the membership provider in any way without rewriting the full control (the CreateUserWizard is one of the lengthiest controls in ASP.NET this is not an option). So the only solution without compromising medium trust scenarios is to ignore the CreateUser method calls in case you plan to insert the users manually. To do this you have to set the provider attribute ignoreCreateUserMethod to true. If the CreateUserWizard control is ever rewritten with extensibility in mind this hack could be removed, but I don’t think that will happen anytime. I posted about similar lack of extensibility problems here.

The auto unlock feature is useful if you use locking. If a user fails entering the password several times in a predefined period of time (specified by the maxInvalidPasswordAttempts and passwordAttemptWindow properties) his account gets locked out. However, you need human interaction in order to unlock the user.

If the auto unlock feature is enabled, when a locked user tries to log on the system, if the data supplied is correct and a certain period of time has passed since the account was locked out, the provider automatically unlocks the account. To enable auto unlocking you have to specify enableAutoUnlock="true" in the web.config. The provider property autoUnlockMinutes controls the minium period of time to wait since the last failed login to be able to auto unlock an account. The default is 30 minutes. Note that setting this value too low can make the security benefits of having a lockout feature disappear.

I’m thinking in adding some code to enforce single user log on for the next version as time permits (don’t expect this to be implemented in 2007).

As always, feedback is welcome. As the previous version, it has been tested only in SQL Server 2005. Let me know if you try it in other databases.

You can download the providers here.

The last two books I read were excellent so I'm recommending them:

Professional ASP.NET 2.0 Security, Membership, and Role Management.

Stefan Schackow is the author of this book. He is a Program Manager on the ASP.NET team so he really knows what he is talking about.

The book covers the life of a request from IIS to ASP.NET, in an incredibly level of detail, explaining what happens in some lifecycle events. It analyzes the 3 different identities used in an asp.net request, trust levels, security in the configuration files, forms authentication, session state, page security, the provider model, and the membership and role provider. Also includes an understandable section about CAS, something difficult to find.

The explanations provided in this book are awesome. Incredibly detailed. It feels like you're following the fully commented ASP.NET source code while reading some parts.

I was so hooked up when I started to read it that I didn't stop until I finished the first 5 chapters! I wish I had read this book earlier. Definitely one of the best ASP.NET books of all time.

Microsoft SQL Server 2005 Integration Services

This one is written by Kirk Haselden, a Development Manager on the SSIS team.

I have read a couple of SSIS books before this one, and they have helped me to be comfortable using SSIS. However, this book explained some things that weren't covered by other books or if they were covered, they weren't explained very well. Thanks to this book now I'm an advanced SSIS user. However, I'm not sure if this book will be useful to a complete newbie to SSIS, so be warned if that's your case.

One cool thing in ASP.NET 2.0 is the concept of build providers. A file extension can be associated with a build provider that parses it and generates the associated code.

For example, the .XSD files have an associated build provider that generates a strongly typed dataset.

The bad news is that build providers only work for web site projects and not for web application projects. I don’t know what the exact reason is for Microsoft not having them working on web application projects but at the moment, we have to manually generate the associated code files and add them to our project. I hope they will fix this at least for VS 2008.

For now, they recommend creating a custom tool in order to handle the file creation. I don’t know very much about Visual Studio internals and I don’t have free time at the moment so I won’t try it.
 
If someone has some free time and can give it a try it will be cool to create a custom tool that reads the configured build providers from the web.config and generates code based on the file type and build provider.

There is a nice article that explains how to create something like the build providers for windows forms that can be a good starting point:

http://msdn.microsoft.com/msdnmag/issues/06/02/CuttingEdge/

Visual Studio 2005 shipped with the Web Site Project to do ASP.NET development. Later, Microsoft realized that the previous mode used in Visual Studio 2003 was also useful, so they added the Web Application Projects later as a download and now it is included in SP1.

The main differences between both approaches are that for Web Application Projects, all code-behind class files and all the stand alone classes for the project are compiled into a single assembly placed in the bin folder; for Web Site Projects, the source code is deployed and when a page is requested dynamic compilation takes place, generating an assembly for each page (this is not 100% true as there are some options to change the default behavior, precompilation, etc, but is enough for the following discussion).

For a more detailed comparison between the two approaches take a look here:

http://msdn2.microsoft.com/en-us/library/aa730880(VS.80).aspx

I'll post a few entries to show some subtle problems I’ve run when working with a Web Site Project and then converting it to a Web Application Project.

The first difference:

I use an HttpModule to handle NHibernate sessions and NHibernate set up. The module captures the Init event and iterates through all loaded assemblies, creating a list of all loaded assemblies and its dependencies, and then initializes NHibernate adding all the assemblies to the Configuration object, so all .hbm.xml mappings embedded in the assemblies are consumed by NHibernate.

The code I was using was:

And this worked fine until I converted the project to a Web Application Project. After the conversion the assembly that had the NHibernate mapping was not loaded in the Init HttpApplication event. It seems that for a Web Site Project all the assemblies that are in the bin folder are loaded when the AppDomain starts, so with AppDomain.CurrentDomain.GetAssemblies() I was able to retrieve the assembly with the mappings. However, for a Web Application Project, only the assemblies that were used until that moment were loaded, and that’s why it failed. The big problem is how to get all assemblies for the web application even if they haven’t been used. 

My first try was to search in the MSDN documentation for the class System.Web.Compilation.BuildManager, as it had something similar for types (the GetType method). Unfortunately the documentation didn’t show any related method (at least in the local Spanish documentation I installed, I haven’t checked others). I googled for a solution to my problem but I didn’t find it anywhere. My only chance was Reflector, so I spend quite some time investigating when I found out the GetReferencedAssemblies public method in the BuildManager class (a class that I have previously discarded because it wasn’t shown in the documentation!). It was very frustrating to waste time for a missing method in the documentation, but using that method solved my problem and works for Web Application Projects and Web Site Projects. The method return an ICollection (to be more precise, an instance of the internal class System.Web.Util.AssemblySet) with the referenced assemblies.

The working code is this:

Today is my “official rant day” so I had to post this. The Parameter class was something introduced with the new data binding infrastructure for ASP.NET 2.0. There are some classes that derive from the Parameter class like ControlParameter, CookieParameter, SessionParameter, etc. providing the developer with a good set of parameters to play with. Also, you can derive from the Parameter class in order to create your own parameters. Everything looks cool and extensible.
 
What is the problem? Imagine you create a new class, MyParameter, that inherits from the Parameter class. Probably, you will want to use that parameter in other places, probably in a ParameterCollection. However, if you go to the designer and try to add a parameter to a parameter collection you won’t see your parameter, only the predefined parameter types. You can expect that, as you haven’t code anything for design time, but you hope that it will be easy to extend the default parameter editor to support your parameter.

The surprise come when you try to extend the default parameter collection editor. The ParameterCollectionEditor delegates all the functionality to the ParameterEditorCollectionForm class, an internal class. The ParameterEditorCollectionForm uses the ParameterEditorUserControl class (this is a public class) to edit a parameter.

The ParameterEditorUserControl contains a UserControl for each type of parameter it supports. The method InitializeParameterEditors and CreateParameterList are private,  so you can’t extend it in any way. When you change the type of parameter you are editing using the combo box, the SetActiveEditParameterItem method gets called to set the proper editor for the current parameter. This method contains some if else statements to select the proper editor based on the current parameter. Of course, the SetActiveEditParameterItem method is private too, so there is no way to extend the parameter editor in design time.

So, as you have seen, just to add design time support to another parameter you have to rewrite a lot of classes. With just a few tweaks to the existing classes, you would only need to override a couple of methods to point to your editor for the new parameter class you have created. If a class is a clear candidate to extending like the Parameter class, the design time related classes also have to be extensible. It is so frustrating to see this in several places...

It would be cool to have several ASP.NET team members to study how to redesign their code in order to make it truly extensible.

A couple of days ago a customer told me that he was using the ExtendedObjectDataSource without problems with telerik’s RADGrid for quite some time. However, when he tried to bind two ExtendedObjectDataSource controls using the master/detail mode of the RADGrid, it didn’t work. He asked the Telerik guys for help on this and they send them an example telling him that it was working with the ObjectDataSource, so it was a problem with the ExtendedObjectDataSource.

I found a problem in their test case so I told them that it wasn’t my fault although I couldn’t understand why it did work for the ObjectDataSource.

They modified their test case to overcome the problem I exposed, so the new test case worked for the ObjectDataSource and it didn’t work for the ExtendedObjectDataSource. Something really strange was happening.

I spent some time carefully reviewing my code but I didn’t found any problem. I had no previous experience with the RADGrid (an excellent control BTW) but I loaded the evaluation version in reflector and I stumbled upon the following code:

If you know about DataSource controls and their infrastructure the problem is clear. Telerik’s RADGrid gets the control bound to the grid (using the DataSourceID property). If it is a SqlDataSource or an ObjectDataSource, it gets the SelectParameters. After that they try to find a parameter in the SelectParameters that matches the field used to traverse from the master object to the detail object and if they found it, they set the DefaultValue of the parameter to the associated key.

However, they are ignoring ALL DataSource controls but the SqlDataSource and ObjectDataSource. This is not a nice way to play with others!
 
I told them to please add more generic code to support more data sources. Something like adding a property SelectParametersPropertyName with a default value of “SelectParameters” and using reflection to get the property from the control will do the trick. I don’t know how they have changed it but at least they sent a fixed private version to my customer. With a bit of luck they'll add the modification to the next public release.

I can’t compare with Telerik in any way as they are one of the most important component vendors in the .NET market, they have an amazing quantity of controls and they have a lot of people working for them… Anyway, nothing like being right against Telerik to make my day.

I have updated my Membership and Role provider that use NHibernate for data access. The changes are minimal. Now I'm using NHibernate 1.2.0 GA and a minor fix. The instructions and the code can be found here

This will be my last post until I return from London. Excuse me if I'm unable to reply to non critical emails in the next few days.

I have heard of this problem very often:

I’m using a DataSourceControl (for example, an ObjectDataSource) and a GridView. I have a read only property and when I try to update an item, I get an exception because the DataSourceControl attempts to set the read only property. What is happening?

Let see an example. In this particular example I’m showing the content of a shopping cart. The GridView has the following columns:

Note that all the columns for the GridView are read only except the ProductUnits. The only read only property for a shopping cart item is Total.

If we try the sample, when updating an item in the cart, an exception is thrown because the underlying DataSourceControl tries to update a read only property (Total).  The first reaction is to blame the DataSourceControl for the error but after some findings the problem resides in the GridView. The DataSourceControl receives a keys dictionary, a values dictionary and an oldValues dictionary in an Update operation. If the data it receives is wrong, then don’t blame it if the operation does not work.

What is the problem? Well, I thought that a BoundField was a shortcut to save time and space to bind a property. That it generates a Label in normal mode and a TextBox in Edit mode. The label will show the value of the DataField and the TextBox has two way data binding for the specified DataField. If you select a BoundField column and then click on “Convert this field on a TemplateField”, you can see that the generated templates match what was expected.

If the BoundField has the property ReadOnly set to true, you expect that in Edit mode a label will be shown instead of a TextBox. If you use select that BoundField and then click on “Convert this field on a TemplateField” you’ll see that the generated templates match what was expected too.

With this configuration that only uses TemplateFields instead of BoundFields:

The update operation doesn’t give any problem with the read only property “Total”.  Why?

Imagine, I’m updating the units from 1 to 5 for a shopping cart item with the values ProductId=1, ProductName=”Product 1”, ProductUnits=1, ProductPrice=2, and Total=2.

When I use the above configuration for the GridView, it calls the Update method on the DataSourceControl with the following parameters:

Keys

Values

oldValues

If I use the initial configuration using BoundFields, the oldValues dictionary is different:

When the GridView is in Edit mode and the data binding is performed, it fills a private dictionary called BoundFieldValues. In the HandleUpdate method, the oldValues dictionary that will be passed to the DataSourceControl is filled with the BoundFieldValues. However, the BoundFieldValues dictionary is populated using a template method of the DataControlField class called ExtractValuesFromCell. For a TemplateField, the ExtractValuesFromCell adds the value extracted from the Bind expression (see this post for more information) to the dictionary. If a cell uses an Eval expression instead of a Bind expression, the value doesn’t get added to the dictionary. However, for a BoundField, the ExtractValuesFromCell adds the value to the dictionary even if it is read only, because it is called with a parameter includeReadOnlyFields = true.

The values dictionary is filled calling ExtractValuesFromCell to the current row being edited, but this time, the includeReadOnlyFields is false for the BoundField.

The keys dictionary is filled with the data from the DataKeys property.

If you use this configuration for the GridView:

The oldValues dictionary is the identical to the one obtained using BoundFields instead of TemplateFields.

A DataSourceControl usually combines the data from the keys, values and oldValues dictionary to make an update operation, so to make the operation work as expected you should know in advance what values you want to send to the DataSourceControl.

I checked some advanced grid controls and found that Telerik’s RadGrid have more control about this extraction process. This is from the manual of the RadGrid:

Telerik RadGrid can extract values even from columns that are set as read-only, if the column's property ForceExtractValue is set to:

• "InBrowseMode" - when deleting records
• "InEditMode" - when inserting/updating records 
• "Always" - for all modes

The default value for this property is "None", i.e. the extraction of the default values will not be performed only for read-only columns.

To finally answer the question, for an ObjectDataSource, probably you want all the values except the Total to be present in the final update operation, so this configuration is the one you’ll use:

Hopefully this post has clarified a bit the problem, the possible options and the implications, when working with a GridView and a DataSourceControl.

Something that is really annoying is the list of little bugs or problems that pollute the .NET Framework and doesn’t seem to get fixed (mostly because of remotely backward compatibility reasons). Others problems are simple solved as “won’t fix“, without giving any explanation.

For example, take a look at this one:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=94108

If you use a TreeView, invalid XHTML gets generated because a script tag is added without specifying the type. They only need to add type="text/javascript" to the generated script. It is clearly a bug and it won’t break anything. However, it is marked as “won’t fix”. WTF?

Sometimes one can be lucky and they actually fix the bug (or at least they told you that they will fix it) but this seems to be the exception rather than the rule. For example, I submitted this bug some time ago and it seems it will be fixed:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=265321

However, the list of unresolved issues that clearly need to be fixed is big and growing, but a lot of them aren't addressed. IMHO this should change. I prefer to have a remote possibility of having something that works to stop working because of bug fixes than keep going with thousand of bugs and work arounds for not solving them. Also, I'd like to have updates more often. To wait a year for a service pack for the framework is too much.

In previous posts about MS AJAX, we have been studying the new elements introduced in the web.config for a new project that uses Microsoft ASP.NET AJAX Extensions. The last thing we have to study is the ScriptModule HttpModule:

The ScriptModule is necessary to provide 3 features needed by the MS AJAX:

• To allow page redirection in a partial page update.
• To be able to call page methods instead of web service methods.
• To serve some files to the users skipping the standard authorization mechanism.

Let’s see how those features are implemented. The ScriptModule handles three HttpApplication events:

• PreSendRequestHeaders
• PostAcquireRequestState
• AuthenticateRequest

The PreSendRequestHeaders event is raised before the server sends the headers to the browser, and it is the last chance to modify them. The ScriptModule handles this event, and checks if the current response code is 302, emitted when you call to the Response.Redirect method.

As we will see when we study the UpdatePanel, it allows partial page updates, generating XMLHttp requests. A partial page update has a request header of type "X-MicrosoftAjax" with a value of “Delta=true”. However, as the response of this request is handled internally by the MS AJAX runtime instead of the browser, the redirect wasn’t working. The ScriptModule fixes this problem, because when a redirect is found for a partial page update request, it clears the response (headers and content), maintaining the cookie collection and returning a string as the content of the response. The content of the response is obtained by calling the EncodeString method of an internal class called PageRequestManager. This class plays a key role in the MS AJAX infrastructure and will be studied in detail in future posts. For now, we’re only interested in the EncodeString method, that has 3 main parameters (type, id and content) and generates a string that looks like this:

Length + ‘|’ + type + ‘|’ + id + ‘|’ + content + ‘|’

Encoding the characters “\u0000” and “\u00ff”.

In the client side, when the response has been received, the _onFormSubmitCompleted method of the PageRequestManager class checks the type of command specified, and acts accordingly.

When a redirect is found in response for a partial page update, the ScriptModule generates a string of type “pageRedirect”, where the redirect location is stored in the content. The client side handles this command as shown below:

making the redirect work as expected.

One thing to point is that the ScriptModule checks if a rest call has generated a redirect, throwing and exception in that case. This is done for security reasons.

The PostAcquireRequestState event is raised after the session data has been obtained. If the request is for a class that implements System.Web.UI.Page and it is a rest method call, the WebServiceData class (that was explained in a previous post) is used to call the requested method from the Page. After the method has been called, the CompleteRequest method is called, bypassing all pipeline events and executing the EndRequest method. This allows MS AJAX to be able to call a method on a page instead of having to create a web service to call a method.

The AuthenticateRequest event is raised after the identity of the current user has been established. The handler for this event sets the SkipAuthorization property of the HttpContext for the current request. This property is checked in the authorization module to see if it has to omit authorization checking for the requested url. Usually an HttpModule use this property to allow anonymous access to some resources (for example, the Login Page if we’re using forms authentication). In our scenario, the ScriptModule sets the SkipAuthorization to true if the requested url is scriptresource.axd or if the authorization module is enabled and the request is a rest request to the authorization web service.

As you can see, the ScriptModule isn’t terribly complicated but it is necessary to have the MS AJAX infrastructure working properly.

If we check the AJAX ASP.NET Extensions server side source code, we have now studied about a 33% of it and we haven’t done anything more than study the new infrastructure elements provided for a MS AJAX application in the web.config. The most interesting stuff is to come.

In the next posts I’ll talk about the ScriptManager control.

Where were we?

In my previous posts about MS AJAX Extensions I talked about the additions to the web.config, Serialization, proxy generation, and ScriptHandlerFactory, that is the factory that handles *.asmx requests and *_AppService.axd requests. To refresh memory, what the ScriptHandlerFactory does is to check if the request has application/json ContentType (a REST method request) or the request path ends with /js or /jsdebug (a REST client proxy request). If it is a REST method request (http://localhost/AJAXServerSide1/AjaxWebService.asmx/GetModifiedUser), it gets the web service data, calls the requested method and returns the result. If it is a REST client proxy request (http://localhost/AJAXServerSide1/AjaxWebService.asmx/js), it returns the generated client proxy. If it isn’t a REST method request or a REST client proxy request, it delegates the request to the “normal” *.asmx HttpHandler.

The  HttpHandler for *_AppService.axd exists to allow the developer to use some application services with AJAX. The only available application services available in v1.0 are Profile_JSON_AppService.axd and Authentication_JSON_AppService.axd. The profile service exposes the methods:

• GetAllPropertiesForCurrentUser
• GetPropertiesForCurrentUser
•  SetPropertiesForCurrentUser.

The authentication service exposes the following methods:

• Login
• Logout

To use the services, we have to enable them in the web.config. For the profile service, we have to set the properties that can be read and write by MS AJAX. For the authentication service we can specify if it requires SSL or not.

There is a role service that exposes the method GetRolesForUser but it isn’t enabled in the current version.
The default implementation of the services can be changed, but I won’t be touching that until we study the ScriptManager.

The last HttpHandler that MS AJAX adds to the web.config is the ScriptResourceHandler, for the path ScriptResource.axd. Lets study it in more detail…

ScriptResourceHandler in detail

The main function performed by the ScriptResourceHandler is to load scripts from resources stored in the assembly and adding localized resources to the scripts.

A request to the ScriptResource.axd must be done at the root level for the application (~/ScriptResource.axd). The request has the information needed to process it encrypted in the query string (the encryption and decryption process is done using the EncryptString and DecryptString methods of the System.Web.UI.Page class). The decrypted format for the query string is:

“d=” + 1 character that indicates additional processing + assembly name + ‘|’ + resource name + ‘|’ + cultureName.

The first character can be ‘u’, ‘U’, ‘z’ or ‘Z’. An uppercase character indicates that the feature is enabled and the lowercase character indicates that the feature is disabled. The ‘Z’ indicates that the resource has to be compressed (using GZip). The ‘U’ indicates to add some code to the end of the script, to notify the MS AJAX runtime that script has been loaded. The code that gets added to the script is:

The assembly name and the resource name must be specified. If not, an error 404 (page not found) will be returned. The culture name is used to set the CurrentThead.CurrentUICulture property. If no culture is specified, the invariant culture is used.

To expose resources stored in an assembly, the assembly level attributes ScriptResourceAttribute and WebResourceAttribute have to be used.

The ScriptResourceAttribute has 3 important properties: ScriptName, ScriptResourceName and TypeName. The ScriptName property will be compared to the requested resource name. ScriptResourceName points to a resource file that contains strings. The TypeName property specifies a script type that will be created containing the localized strings (of the CurrentUICulture, or the default ones if no CurrentUICulture specific resources exist) present in the resource specified by ScriptResourceName.

The WebResourceAttribute has 3 important properties: WebResource, ContentType and PerformSubstitution. The WebResource property will be compared to the requested resource. ContentType specifies the type of data stored in the resource and will be used to write the ContentType for the response. The PerformSubstitution property is used by the ScriptResourceHandler in order to convert expressions like:

To the URL of the resource. If WebResource is used, the generated URL will start with “WebResource.axd?d=”. For ScriptResource, the generated URL will start with “ScriptResource.axd?d=”. The substitution is performed using regular expressions.

When a resource in an assembly is requested, the assembly is inspected for the assembly level attributes ScriptResourceAttribute and WebResourceAttribute. Information about the requested resource is stored in the class ScriptResourceInfo, that has the properties of ScriptResourceAttribute and WebResourceAttribute combined. For the same resource name, we can have a ScriptResourceAttribute and a WebResourceAttribute. If only ScriptResourceAttribute is specified, the default content type is "application/x-javascript". The ScriptResourceInfo is cached using the assembly and resource name as the cache key.

When a resource that ends with .debug.js is requested, the release mode resource (resource name that ends with .js) is also requested. At least one of those resources has to exist.

If we have set the property EnableCaching for the ScriptResourceHandler in the configuration section, the response will be cached using the ASP.NET output cache by the server for a year.

The response will be generated in 3 steps:

• The requested resource will be read using the GetManifestResourceStream method from the Assembly class.  If PerformSubstitution is enabled, the substitution explained above is performed.
• If the ScriptResourceAttribute is used, a ResourceManager for the resource file with the localized resources is obtained, and some script is added to save the resources (see the code below)
• If the MS AJAX runtime has to be notified of the loading of the script, add the script line shown above.

Example

If we have the following assembly level attributes:

The file MyResources.JScript1.js is like this:

The file MyStrings.resx has the string named String1 = “This is a test”, when the resource “MyResources.JScript1.js” is requested, the response content is:

If you add another resource file to localize the resources for spanish (MyStrings.es-ES.resx) and configure the application to use the Spanish UI culture, the response for the resource “MyResources.JScript1.js” is:

That's all for now. In a next post I'll finally finish explaining all the elements present in the web.config for an asp.net ajax application.

Usually, the built-in providers for ASP.NET do not integrate very well with existing applications. The membership provider has a very complex structure that in most cases is not needed at all. The following diagram shows most of the tables and relations for the built-in ASP.NET providers:

The membership related tables are selected in red and the role related tables are selected in blue. The default membership and roles provider have support to store data for multiple applications using the aspnet_Applications table. I think this table was introduced because some portal frameworks like dotnetnuke needed the ability to store membership and role data for multiple users in a single store because they support multiple portals. If you don't need this scenario (and most applications do not need it), this only complicate things.

Also, the built-in providers use tables that are not part of your application tables, and some of those tables have quite a few columns, and probably some are not needed by your application.

If you do not use SQL Server, you can not use the default providers, so that is a big showstopper.

To overcome all of this problems I have created a custom membership and role provider that use NHibernate and can be easily integrated with existing or future applications using your own tables.

The reference book about providers is:

Professional ASP.NET 2.0 Security, Membership, and Role Management.

I suggest you to read it if you really want to get deep into providers as it is an excellent book.

The NHCustomMembershipProvider uses NHibernate to do all membership related database operations so it should work on all databases supported by NHibernate. The membership data will be stored and retrieved from a table configured in the provider section in the web.config so you can map it to an existing table like users. The column names for your user table can also be configured in the provider section. The cool thing about the provider is that it adapts its behaviour to the number of columns supported by your data store. For example, if you use the provider and map it to your users table where you only have the membership data for userId, userName, password and email, it will work without any problem. If your data store supports more advanced options of the membership provider like account lockout, password question and answer, password salt or last activity date, that advanced functionality will be automatically available, but it is not required.

The provider knows what functionality to offer based on the number of columns that are mapped to your data store. To support account lockout when the user do not supply a valid password after some tries in a predefined period of time you need to map the isLockedOutColumn, failedPasswordAttemptCountColumn and failedPasswordAttemptWindowStartColumn to columns in your data store.

The default configuration for the provider is to use integer identities or sequences for the user identifier, but that can be changed using the userIdType and idGeneratorClass properties in the provider configuration section.

If you use the provider with an existing user table, probably you will create the users manually without using the CreateUser method from the membership provider. The provider exposes the methods CheckPasswordPolicy, ValidatePassword, EncodePassword and GenerateSalt to allow manual creation of the user in case you need it, without sacrifying password strength.

To finish with the custom membership provider lets see an example. If you want to use the membership provider with a table like this (that has columns for all supported functionality):

The configuration section for the membership provider will be something like this:

   
The column sizes are optional but it is a good practice to fill them.

The built-in provider raises events after a succesfully or a failed login. However, ASP.NET 2.0 does not allow to create or raise built-in health monitoring events, so I had to use reflection in a private method in order to raise the same events. That means that the provider will not run in medium trust if it is not installed in the GAC if you want to raise the system events. As this can be a showstopper to some people I have added an option to disable system events generation (raiseSystemEvents).

The provider reads the config section and programatically generates a mapping for the specified columns in the ConfigureNHibernate method. The provider expects that you have configured NHibernate in the web.config to work. If you need extra configuration for the provider you can inherit from the provider and use override the ConfigureNHibernate method, modifying the Configuration object that the base class returns.

The NHCustomRoleProvider is also configurable in order adapt to your own tables. It only needs a Users table with id and user name columns, a roles table with id and role name columns, and a join table used to store the information for the many-to-many relationship between the users and roles.

For example, if we the previous user table with the following tables (FKs omitted for brevity):

The configuration section for the role provider will be something like this:

Note that the id columns in the join table need be named as in their respective tables in order to work.
   
Programatically creating the mapping using the CreateMappings for something more complex than a single table seems to be something very tied to the NHibernate implementation so I opted to create a XmlDocument with the mapping read from the configuration settings as it seems to be the best thing to do in complex cases.

One of the problems I faced with the NHCustomRoleProvider is that some times I wanted to save or delete data from one side of the many-to-many relationship but in some cases I wanted to use the other side. If you know a bit of NHibernate you know that the inverse attribute controls what side of the relationship has to be used in order to have changes persisted. As I was generating the mapping dynamically I created two session factories, one with the inverse set to true on one side and the other with the inverse in the other side. That way I open a connection in the session factory that has the mapping with the inverse in the side of the relationship I want.

I'd appreciate usage feedback, suggestions, bug reports, etc. I have only tried these providers with NHibernate 1.2.0 GA and the MsSql2005Dialect so let me know if it works in other configurations.

Please do not store the providers in your server. Link to this page instead. Updates to the providers will be posted in this page.

History

v1.0 - 08/04/2007

v1.1 - 21/06/2007

• Now using NHibernate 1.2.0 GA
• Some minor fixes

v1.2 - 12/10/2007:

• Fixed an important bug that didn’t prevent locked out users from login in.
• Added a CreateUserWizardEx control that allows creating a user with extra information in an easy way.
• Added auto unlock support.
• Fixed some minor bugs/typos.

For more details about the features introduced in version 1.2 take a look here.

v2.0 - 01/08/2008:

For more details about the features introduced in version 2.0 and a sample of its usage take a look here.

NHCustomProviders_bin.zip (67 KB)
NHCustomProviders_source.zip (122 KB)

In a previous post I said that the ObjectDataSource can handle generic types using the backtick (`) notation, even if the ObjectDataSource doesn't have any design time support for this.

This works because the ObjectDataSource internally calls to Type.GetType to resolve type names to Type objects. As the Type.GetType method handle generics transparently, the ObjectDataSource does not have to do anything special to support it at runtime. Supporting generic types at design time is more complex so they fiter out generic types in the "Select Type" wizard step.

For generic methods things change. There is some inconsistency in generics handling in the .NET Framework. If you get the type of a class like List<Customer>, its Name is List`1[Customer]. However, if you have a method like Customer Get<Customer>(int id), the method name is Get. IMHO, to have an orthogonal implementation, the method name should be Get`1[Customer]. Also, the GetMethod method should understand the backtick notation for methods and retrieve the specified method properly but it isn't supported for now. I have requested an improvement for the next version of the .NET framework here. Probably they won't fix it but it would be nice if you vote for it.

Returning to the ObjectDataSource... When the ObjectDataSource tries to find a method, it call the GetMethods method and compares the method name with the expected name, filtering out generic methods.

So, I think Microsoft didn't bother to add support for generic types or generic methods, and if generic types work at runtime is by luck (because of the GetType behaviour).

As more developers are using generics, there is a need to properly support generic methods and generic types. The next version of the ExtendedObjectDataSource (that will be released next week), will have full generics support, at design time and at runtime.

It wasn't easy to add design time support for generics as several problems appeared:

* Generic type expressions and generic method expressions can be arbitrarily complex (like MyGraph`2[[Utilities.Set, Utilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a7a65c534534e209],[Utilities.Graph, Utilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a7a65c534534e209]], MyGraphLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2134afb4534e209), so I had to write a parser for both kinds of expressions.
 
* At runtime, specifying "__code" for the assembly name gets traslated to the dynamically generated assembly (as explained in the previous post). However, at design time this translation has to be done manually.
 
* I had to rewrite the select type wizard step and select method wizard step as the code was getting harder to maintain with generics.

* Showing and choosing generic methods and types is half of the problem, after choosing them you have to create the generic type or the generic method based on the generic type definition and the generic method definition.
 
Lets see an example of what can be accomplished now with the CompatObjectDataSource.

Imagine that we want to be able to register some objects at the start of the application in order to used later using a registry.

The registry can be implemented like this:

   
Some of the data stored in the registry when the application starts is a list of all available countries (for example, retrieved from the database):

The Country class is very simple:

If we want to show all the countries in any webform we can use an CompatObjectDataSource. After dropping one to the toolbox we configure the type:

And then we can see the list of methods compatible with the Select operation (GetObject and GetObjectList):

As both methods are generic method definitions, after selecting one of them, we have to specify the generic parameters. In our case, we stored the countries using a string key, and we stored a List of Country objects so the generic parameters for the method are System.String, Manu.GenericTests.Country. After clicking in "Make Generic Method" we have the data source configured properly:

If we take a look to the ASPX we can see the following code:

The SelectMethod is saved as "GetObjectList`2[System.String, [Manu.GenericTests.Country, __code]]" and the TypeName is saved as "Manu.GenericTests.Registry, __code".

The only thing to do now is to set the DefaultValue property for the key parameter to countries. Now the CompatObjectDataSource has enough information to call to GetObjectList<string, Country>("countries") from the Registry class and retrieve the countries.

The only thing I'm missing in the CompatObjectDataSource/ExtendedObjectDataSource is support for Bind expressions for nested properties (<%# Bind(Address.PostalCode) %>), but unfortunately, the framework can not understand those expressions so nothing can be done ast the moment. I wrote an email to ScottGu about that and got this reply from Shanku Niyogi:

"This is definitely a doable thing - we'll add it to our list of items we're considering adding for an upcoming release."

So keep your fingers crossed.

I'm open to suggestions in what to functionality you would like to see in the ObjectDataSource/CompatObjectDataSource/ExtendedObjectDataSource.

In my last post about MS AJAX I gave a brief explanation about the web.config changes needed and explained the serialization process.

Now, I'm going to explain how a client proxy is generated. As I told in the last post, the WebServiceClientProxyGenerator.GetClientProxyScript method was were all the job was done.

There are a few classes involved in the client proxy generation:

• WebServiceTypeData, that is used to store type information about the web service to call.
• WebServiceMethodData, that is used to store information about a web service method (parameters, return type, caching, etc), and it has the functionality to invoke the method.
• WebServiceParameterData, used to store information about a parameter of a web service method.
• WebServiceData. This class uses the previous classes and has a lot of logic. Basically a WebServiceData instance is created for each web service to call (for each instance there is an associated WebServiceTypeData instance). When the web service methods are required, the EnsureMethods method uses reflection to obtain all WebMethods from the type (and its ancestors).

By default, a web service can't be called from client script. To change this, the web service needs the ScriptServiceAttribute applied to it.

To be able to call a web method from client script, the parameters and return types of the web method have to be available in client script, and the web service needs to have the WebMethodAttribute (the ScriptMethodAttribute should be used only to override the default invocation method and respone format, that is HTTP POST and JSON). If a web service method needs a parameter of a custom type, we have to use the GenerateScriptTypeAttribute attribute in the method or in the web service so MS AJAX will automatically generate a client side class for that type.

So when the methods are processed, the ClientTypes property will be filled in the ProcessClientTypes method with a list of the types that need to be available in client script.

However, the automatic type generation has some limitations, as the GenerateScriptTypeAttribute can not be applied to types implementing IEnumerable or IDictionary, interfaces, abstract classes, types without a public parameterless constructor, and generic types with more than one parameter.

The WebServiceData class also inherits from the JavaScriptTypeResolver class to provide string to type conversion (and viceversa) for the serialization/deserialization process. You may be wondering why the SimpleTypeResolver isn't used, but as the GenerateScriptTypeAttribute has a property called ScriptTypeId that modifies the __type field stored in the JSON, another type resolver was needed.

As you can see, the WebServiceData class does a lot of work, so to get WebServiceData instances the static method GetWebServiceData is used because it caches instances by URL.

If you don't want to create a new class for a few methods, you can add them to your ASPX page and call them directly. For this to work, the methods should be static and have the WebMethodAttribute attribute applied.

The ClientProxyGenerator class uses a WebServiceData instance and generates the client proxy code, although the code calls to the static method GetClientProxyScript of the WebServiceClientProxyGenerator class to get the generated client proxy code, because it performs caching based on the web service type and the modified time of the associated assembly.

For the following web service:

the User and Address classes were introduced in the previous post.

the generated proxy is:

The generated proxy class is called like the web service, and inherits from the Sys.Net.WebServiceProxy class, which has the functionality to invoke a web service. The class have some properties set in order call the specific web service that it is proxying, and the web methods exposed (GetModifiedUser in our case).

After the class to call the web service, the User and Address classes are created and registered to be used by client code (thanks to the GenerateScriptTypeAttribute). However, no property of the original classes is generated in client script. The core of this client classes is the call to the Sys.Net.WebServiceProxy._generateTypedConstructor method. This method creates a new class that accepts an object as a parameter for the constructor. The constructor of the class will iterate through the members of the object passed as the parameter and copy them to the current instance.

So you can create an instance of the Address class that has 2 fields (propertyOne and propertyTwo) like this:

and accessing to Address.firstField will return "firstValue".

So if you want to call the previous web service from client script you can do something like this:

when the User instance is created it contains no members, but you keep adding them in each assignment (this is how JavaScript works). You can even add nonexisting members like user.Foo = "This property doesn't exists in server code" and they will be ignored on the server side in the deserialization process.

When the GetModifiedUser method is called from client script, it generates an asynchronous HTTP request to the web service (http://localhost/AJAXServerSide1/AjaxWebService.asmx/GetModifiedUser in my case) with the following posted data:

that is passed to directly the User constructor in order to generate the returned value from the web service.

In my next post about MS AJAX I'll sumarize what we have learned and how it applies to the ScriptHandlerFactory, the application web services, and then continue with the next HttpHandler, the ScriptResourceHandler.

Some time ago I started bloging about the Client Side OOP Features of Atlas (now the Microsoft AJAX Library. The posts are here and here).

As I think that most ASP.NET developers will use mainly the server side AJAX extensions I'll start covering the internals of the server side additions to ASP.NET to support AJAX.

If you create a new Web Site in VS2005 using the "ASP.NET AJAX Enabled Web-Site" you'll see that the web.config file for this web has quite a few additions to the default one related to AJAX. The additions to the web.config are:

1) Added some custom sections handlers to configure the new AJAX features

2) Configured the "asp" tag prefix for controls in the AJAX implementation assembly:

3) Added the AJAX assembly reference to the compilation process:

4) Modified the HTTP Handlers:

5) Added an HTTP Module:

6) Added the configuration sections to configure ASP.NET AJAX (the section handlers were registered previously as explained in point 1).

The most important additions to the web.config to support the Microsoft ASP.NET AJAX Extensions (MS AJAX from now on) are point 4 and 5. As the ASP.NET HTTP pipeline is very configurable, those additions can have severe implications on how request are handled, so I'll start with them.

In the HTTP handlers section, the first line removes the default handling for the asmx extension, and the second one registers a new handler for the asmx extension. This simple changes makes that any call to a web service doesn't work as we are used to. The asmx requests now will go through the ScriptHandlerFactory.

Usually in the HTTP handlers session we register a class that implements the IHttpHanlder interface. The ProcessRequest method will be called to do all processing.

However, we can also register a class that implements an IHttpHandlerFactory. In this case, the method GetHandler will be called in the factory, returning an IHttpHandler that will handle the request. This is used when you want to return different IHttpHandler instances depending on some conditions of the request.

When a request that is handled by the ScriptHandlerFactory arrives, it checks if the request is a REST request (REST is a way to transmit data over HTTP without using any additional messaging layer. Consult wikipedia for more information about it). If it is a REST request, the RestHandlerFactory (a MS AJAX class) will take care of the request. If it isn't, the WebServiceHandlerFactory will take care of it. Probably the class WebServiceHandlerFactory won't say much to you, but this is the class that handles ASMX request in the ASP.NET 2.0, so when an ASMX request isn't a REST request, it is handled in the same way as we're used to. 

What is a REST request for MS AJAX? A REST request is an HTTP request that has the ContentType property set to "application/json" (this is called a REST method request) or an HTTP request whose path ends with "/js" or "/jsdebug" (this is called a REST client proxy request).

The RestHandlerFactory checks if the request is for a client proxy or for a REST method. If the request is for a client proxy, a RestClientProxyHandler is created and servers the request. The RestClientProxyHandler figures which client proxy has been requested, gets the client proxy and sends it. All the hard work is done by the WebServiceClientProxyGenerator.GetClientProxyScript method. Before entering in detail how the client script proxy is generated, lets see how MS AJAX handles serialization.

Data types are exchanged between client side and server side using JSON (JavaScript Object Notation). To send data to the client side from the server, the data is serialized, and to receive it from the client, the data is deserialized in the server.

The main class responsible for this serialization/deserialization process is JavaScriptSerializer. The public member for the class are:

The serialization fails if there are more nested objects than RecursionLimit or if the length of the serialized object is MaxJsonLength.

A serialized object can optionally include type information. The type information is provided by a class that inherits from JavaScriptTypeResolver, that has the following methods to get a type from a string and viceversa:

The serializer will add the type information in a field called __type if it has an associated JavaScriptTypeResolver.

As the JavaScriptSerializer can not serialize/deserialize all types, you can supply a custom class to support types not directly supported by the JavaScriptSerializer using the RegisterConverters method. A converter has to inherit from:

and it has to implement the Serialize and Deserialize methods, as well as providing the list of supported types.

The standard MS AJAX distribution doesn't have any converter, but you can find a DataSet, DataTable and DataRow converter in the ASP.NET AJAX Futures release.

The other methods of the JavaScriptSerializer class are just serialize/deserialize variants, and the ConvertToType method that will be explained later.

The serialization of the basic types is as follows:

null or DBNull.Value -> "null"
bool -> "true" or "false"
char -> if it is '\0', "null", like a string if not
float, double -> ToString("r", CultureInfo.InvariantCulture)
DateTime -> "\/Date(number of milliseconds elapsed since midnight 1970/01/01 UTC)\/"
string -> quoted string
Guid -> "\" + ToString() + "\"
Uri -> "\" + Uri.GetComponents(UriComponents.SerializationInfoString, UriFormat.UriEscaped) + "\"
other primitive types and Decimal -> IConvertible.ToString(CultureInfo.InvariantCulture)
Enum -> serialize the integer value of the enum
IDictionary -> JSON object
IEnumerable -> JSON array

A custom object is serialized as a JSON object with the optional member "__type" : typeName obtained using the JavaScriptResolver, where the other members are obtained from the public instance fields and public instance properties without the ScriptIgnore attribute applied.

for more information about JSON take a look here.

A Hashtable that compare references is used to throw an error if there is any circular reference.

Lets show an example of the serialization process. I'm going to use this User and Address class:

With the following code:

The SimpleTypeResolver inherits from the JavaScriptTypeResolver class explained before, converting a Type a string using the AssemblyQualifiedName and viceversa.

Is serialized as:

Note that the FullName property of the User is not serialized because the ScriptIgnore attribute.

The deserialization process is delegated to the JavaScriptObjectDeserializer class. This class uses the JavaScriptString and the ObjectConverter class. The JavaScriptString class is a helper class used to tokenize the JSON data. As when the data is serialized all types are converted to JSON types (strings, numbers, JSON objects and JSON arrays) some kind of conversion back to the original type must take place. The JavaScriptObjectDeserializer does some simple conversions like checking if a string is a character, a boolean, a date or a null value, most significant conversions are handled by the ConvertObjectToTypeInternal method of the ObjectConverter class.

The ConvertObjectToTypeInternal uses the __type field, source object type and destination type to perform the convertion. If the source data is of type IDictionary it tries to create an object of the destination type and sets its fields and properties with the values stored in the dictionary. If the source data is of type IList, it tries to create a collection of the destination type and adds each of the items of the list to the collection. If the collection is a generic collection, it extract the item type of the collection and tries to convert the items as they're added to the collection.

If the source type isn't neither an IDictionary nor an IList, it gets the TypeConverter for the destination type and check if the source data can be converted to that type. If the source type doesn't have a conversion to the destination type, it converts the source type to a string and then tries to convert that string to the destination type (all of the conversion that involve the TypeConverter use the InvariantCulture).

If everything fails, a conversion exception is thrown.

To continue the previous example, this converts the string obtained from the Serialize method back to an User instance:

When comparing the initial User instance with the deserialized one, the CreationDate is different by one hour (at least in my machine), so there is a bug in the MS AJAX code that handles DateTimes :-(

One curious thing about serialization is that the property names are case insensitive when deserializing an object, as the AssignToPropertyOrField method uses the BindingFlags.IgnoreCase to retrieve properties and fields. However, when an object is serialized, the properties for the client code are case sensitive.

I have run out of time for this week but soon I'll continue with the internals of the additions of MS AJAX to the web.config.

The ObjectDataSource supports using generic classes in the TypeName property although it doesn't provide any support for it. Usually you'll see that the TypeName property stores the name of a type (i.e. CustomProject.MyDAL), but it can store the type's full assembly qualified name (i.e. CustomProject.MyDAL, CustomProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a7a65c534534e209).

The type's full assembly qualified name can be quite complicated and it is described by the following grammar:

TypeName := NamespaceTypeName | NamespaceTypeName ',' AssemblyNameSpec
 
NamespaceTypeName := NestedTypeName | NamespaceSpec '.' NestedTypeName
 
NestedTypeName := GenericTypeName | NestedTypeName '+' GenericTypeName

GenericTypeName := IDENTIFIER | IDENTIFIER '`' Number '[' GenericTypeArgList ']'

GenericTypeArgList := GenericTypeArg | GenericTypeArg ',' GenericTypeArgList

GenericTypeArg := NamespaceTypeName | '[' TypeSpec ']'
 
NamespaceSpec := IDENTIFIER | NamespaceSpec '.' IDENTIFIER
 
AssemblyNameSpec := IDENTIFIER | IDENTIFIER ',' AssemblyProperties
 
AssemblyProperties := AssemblyProperty | AssemblyProperties ',' AssemblyProperty
 
AssemblyProperty := AssemblyPropertyName '=' AssemblyPropertyValue

For more details about the grammar for type's full assembly qualified name in .NET Framework v1 take a look here

If you look in detail the grammar, it accept generic type names, that have a '`', then the number of generic argument and then the generic arguments inside square brackets.

So the following are valid type names: 

System.Colllections.Generic.List`1[System.Int32], mscorlib

MyGraph`2[[Utilities.Set, Utilities],[Utilities.Graph, Utilities]], MyGraphLibrary

MyGraph`2[[Utilities.Set, Utilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a7a65c534534e209],[Utilities.Graph, Utilities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a7a65c534534e209]], MyGraphLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2134afb4534e209

So if you want to use a generic type in the ObjectDataSource you just have to specify it using the syntax explained above. Be sure to add the assembly names if you use generic types.

What happens if the generic type you want to use is in the App_Code folder? The code in the App_Code folder gets compiled into a dynamically generated assembly with a random name so it is impossible to know it. Fortunately, you can use __code as the assembly name and it will work. Why does this work? When the framework can't resolve an assembly, the AppDomain AssemblyResolve event is fired. The BuildManager class (that is a helper class for ASP.NET compilation), captures this event and checks the specified assembly name. If it is __code, it returns the dynamically generated assembly for the App_Code folder. Returning App_Code also works (and you save executing a few instructions).

As an special case, you can use VB, C# or other .NET supported language in the same web application if you place the code for each language in a different folder. For example, if you want to use VB and C# you have to create these folders:
App_Code/VB
App_Code/CS

and add this to the web.config:

<codeSubDirectories>
    <add directoryName="VB"/>
    <add directoryName="CS"/>
</codeSubDirectories>

If you use this configuration two assemblies will be dynamically generated for your code behind classes, one for each folder. If you want to reference it in the TypeName of the ObjectDataSource or where the framework expects a fully qualified name you have to use App_SubCode_VB or App_SubCode_CS.

Of course, the ObjectDataSource doesn't have design time support for this. In fact, the ObjectDataSource choose type dialog filters out the generic types, the interfaces and the types registered in the GAC.

The ExtendedObjectDataSource will have full design time support for generic types and more control about the types that are filtered in the next version:

When you select a generic type, a textbox and a button appear. You can use the textbox to specify the type of the generic parameters and click in the button to select the generic type. Also, there are some checkbox to have control over what types get filtered.

The above dialog has some little positioning issues that I think are caused by Windows Vista, because the dialog was defined as:

In a future post I'll talk about generic methods. 

Another year ends and a new one comes. Life goes as fast as usual and we’re keep on our way. It’s time to think about it… our actions, hopes, wishes, mistakes, etc.

I usually listen to a special song a few minutes after the start of the year. In the last few years I have been choosing "Aerosmith – Full Circle" because it has special connotations for me.

I wish you the best in the coming year.

I haven’t paid too much attention to WPF but after the first CTP of WPF/E I was curious to see what is the status of WPF/E (mostly, because I had a project in mind that needed some vector graphics and I was going to use SVG to do it) so I installed it and take a quick look at it.

You can install it here:

http://go.microsoft.com/fwlink/?linkid=77791&clcid=0x409

And an introduction video can be watched here:

http://channel9.msdn.com/showpost.aspx?postid=263358

The truth is that I am a bit dissapointed with it, but don’t get me wrong. WPF/E is a cool idea in the initial stages of development, so with a bit of luck it can evolve to something really useful. However, this initial release lacks a lot of stuff:
- there isn’t any direct pixel manipulation method available making this a very limiting factor for games.
- there isn’t any input control.
- missing keyboard support.
- Also there isn’t a linux version yet.
- The SDK samples aren't as good as the ones shown in the video.

Hopefully those problems will be addressed in future releases if Microsoft wants to create something that can replace flash in a lot of scenarios. Currently is only usable for displaying charts, shapes and video.

Also, as a MSDN professional subscriber, I’m a bit pissed of because the Microsoft Expression suite isn’t available to us, but that’s another story…

I couldn’t resist to improve StructsViz in order to add support for trees. Even if everybody has his own tree implementation, we can come up with a common agreement:

A tree is a collection of nodes, where each node has zero or more child nodes. Each node has zero or one parent. The only node that doesn’t have a parent is the root node.

So based on the previous definition, I have defined this interface that is mandatory to implement in order to visualize a tree node in StructsViz:

I think that any tree node implementation can easily implement this interface.

With that interface implemented, StructsViz will be able to draw your tree node.

I have been playing a bit with automatic layout positioning for trees, and with different kind of connections:

The pictures show debug information of the subtree areas needed to position the elements properly using a recursive algorithm. For example, the rectangle labeled as ST 2, is the subtree area for node 2, and it is calculated based on the ST 6 and ST 7 (subtree areas for node 6 and 7 respectively). With ST 1, ST 2 and ST 3, we can properly position node 0.

I’m giving the final touches to this and it will be included in the next StructsViz version.

Visual Studio.NET 2005 has a really cool feature called debugger visualizers. When you are inspecting an object while debugging, there are times that the standard inspection of fields and properties of the debugger is not the best way to check if the internal state of the object is correct. For example, a DataSet is very difficult to debug, because the data is stored in a long hierarchy of objects. A debugger visualizer is a viewer of objects of a predetermined type that presents the object to the developer using a custom UI that helps debugging it.

The debugger visualizer executes on a different application domain than the application we’re debugging so to access the object being inspected the data needs to be sent from one application domain to the other application domain. This implies that the object we’re inspecting needs to be serializable or we need to create a serializable proxy in order to visualize it.

There are quite a few articles on the web about debugger visualizers so I will not enter in detail in the process of writing a visualizer, but I’ll explain the basics. As I explained before, the visualizer runs in a different application domain than the process we’re debugging. To communicate those application domains, an object that inherits from VisualizerObjectSource is created. The visualizer inherits from the DialogDebuggerVisualizer class and has to implement the Show method, showing a custom dialog. Before showing the dialog, the visualizer usually retrieves data requesting it to the VisualizerObjectSource using an intermediate object that implements the IVisualizerObjectProvider.

The main method of the VisualizerObjectSource is GetData, where the object being debugged should be sent through a stream. If the object being debugged is big, this could be a long operation so a thing that can be done is to send a simplified object in the GetData method, and when the user wants to see more detail of the simplified object, transfer a more data using the TransferData method.

A data structure is something that is better represented graphically so I spent some days writing a bunch of visualizers for all the .NET System.Collections.* classes. Here you have some pics of it:

I had to write a basic diagramming engine in order to get some nice results. Writing the diagramming engine was the funniest part. I wanted a lot of flexibility so I end up implementing absolute and relative element positioning, cascading styles, shape composition, expandable elements, automatic layout adjustment, zooming, etc. I think that the resulting object model was pretty good even if it isn’t a complete diagramming engine.

After some work with the debugger visualizers, a big limitation surfaces. You can only attach a visualizer to classes and not to interfaces. I think Microsoft should change this is the next version as this is severely limiting the power of the visualizers.

Also, it is a shame that the .NET framework doesn’t include more complex data structures like a Tree or a Graph. A visualizer for a Dictionary, a List or a Queue can be useful, but a visualizer for a Tree and a Graph is very very useful. Every developer has to code his own Tree and Graph, so creating a viewer for them will make the developers to use my implementation if they want to visualize it because of the limitation of the debugger visualizers, and that can’t be done in a lot of cases.

You can read more about the visualizer pack here:

http://www.manuelabadia.com/products/StructsViz_features.aspx

You can take a look to the evaluation version here:

http://www.manuelabadia.com/products/Purchase.aspx

I have spent most of the last weeks changing some designs to use pure CSS layouts instead of table based designs and having to support IE 5.0+.  So you can imagine my frustation level. It’s really sad to see the required work to make a complex design work in IE 5.0, IE 5.5 MAC IE 5, IE 6, IE 7, Firefox, Safari and Opera. IE versions prior to IE 6 are really terrible in CSS compliance and you need to have solid IE bug theory to fix those limitations.

It is really sad that here (in Spain) and maybe in other countries too, there are still a significative percentage of users using IE 5.0 and IE 5.5. IMO there should be some kind of movement to delete old browsers from the earth. For example, in Europe there will be an analogic TV shutdown before 2012. There should be something similar periodically for old browsers. For example every year most of the webpages should use an updated script to completely fail in browsers older than 2 or 3 years, forcing the people to upgrade because most of the webpages they visit will not work for them (as some people will only upgrade for that reason).

Talking about browsers, it is sad to see that IE 7 does not pass the ACID2 tests. Also Firefox, the browser that claimed to be more standard compliant than IE and that will save our souls, doesn’t pass the ACID2 tests either (in the 2.0 release). The first version of Firefox was very good compared to the browsers out there but now they haven’t improved it very much lately. Anyway, the developer extensions for firefox are so good that it is a must have. I was very surprised with Opera 9 because it passed ACID2 tests, has finally added support for rich text editing so things like R.A.D. editor (www.telerik.com) finally works and it has an excellent zoom tool, not like the Firefox one that the only thing that does is to break all pages when you zoom a bit.

But to be fair, a big part of the problems are because of the lack of a reference implementation by the W3C. CSS will be better designed and more trouble free with a reference implementation so the people defining and implementing the standard can play with. It won’t be too difficult to produce automated tests to compare rendered web pages with different implementations of the standard using a common set of stylesheets and fonts, so a pixel perfect comparision will be possible if the rendering engines do not employ any dithering. Having a reference implementation to play with will also help in making a more robust and useful specification (why is so complex to align something vertically in CSS when aligning it horizontally is trivial?).

Will this situation change some day? It is changing slowly but with some help it will be able to change faster and let us focus in real problems and not in stupid incompatibility problems that only causes us headaches and slow down web evolution.

Note: Bertrand Le Roy has confirmed that the next Microsoft AJAX Library release will use the prototype based approach instead of the closure approach (really great news!), and clearly explains the differences:

http://weblogs.asp.net/bleroy/archive/2006/10/11/From-closures-to-prototypes_2C00_-part-1.aspx

In part 1 we saw how the inheritance infrastructure worked, how to create namespaces, and how to create classes. Now it is time to continue with the other stuff.

Interfaces

To create an interface is similar to create a class, but we use the registerInterface method instead and we define the methods to be abstract. For example:

We can define the interface using the prototype method instead of the closure method:

The registerInterface method (defined in the Function type) just set the _typeName of the type where the method is invoked, and sets the boolean properties _interface, _abstract and _sealed to true.

Enumerations

There are two kinds of enumerations that we can create. One where the enumeration items act as flags so we may want to combine them and the other type is where we can’t combine the enumeration items.

The first type is created using the createFlags method and the second one is created using the createEnum method (of the Type class). The parameters for those methods are:

Type.createFlags(enumerationName, enumerationItems)
Type.createEnum(enumerationName, enumerationItems)

Where enumerationName is the name of the enumeration, and enumerationItems are a variable number of parameters that specify the different enumeration items. Each item in the enumeration is specified as two parameters, the first is the string with the item name, and the second the associated value.

The common methods are:
• toString: converts the value passed to the method to a string.
• parse: converts the string passed to a value.
• getName: returns the name of the enumeration

The enumeration where you can use the items as flags has a method called isFlags that return true. The other enumeration type has a method called isEnum that returns true, and a method called getValues that returns a hashtable with the items of the enumeration.

An example follows:

The values of the variables after execution are:

val = 1
str = “enum_item1”
valaux = 2
val2 = 5
str2 = “enum_item1 | enum_item3”
val2aux = 6

Both kinds of enumerations are implemented the same way. A hashtable with the same name as the enumeration is created, and each enumeration item name is stored as a key of the hashtable and the enumeration item value is stored as the associated value for the key.

From now on, when showing a class or an interface, I’ll be using C# syntax to show it instead of the JavaScript version of the class for clarity. The naming convention for the JavaScript classes is distinct from the C# naming convention so if a property is called Text in C#, the equivalent getter and setter will be get_text and set_text instead of get_Text and set_Text, so don’t get confused.

Attributes

In .NET is very common to decorate classes, properties and methods with attributes that provide useful information about them. The Microsoft AJAX library adds this extension to JavaScript.

The attributes are very important to generate reusable code. The xml-script parsing process and the validation controls use it.

An attribute is a static property of the class Sys.Attributes. The class has a method called defineAttribute that creates a new attribute:

After having created the attribute we can reference it using Sys.Attributes. 'MyCustomAttribute. The attributes can be associated to a class or to a property as we will see in the next section.

Reflection

Even if JavaScript has some flexibility that can be used to perform some tasks similar to what reflection does (retrieve all fields from an object, retrieve a field from an instance using a string with the property name, invoke a method from an object based on the method name, etc), as the Microsoft AJAX library added OO features to it, it has to provide a way to interact with all the new OO infrastructure generically and more .NET friendly.

These features are provided by the Sys.TypeDescriptor class. Most of the classes in the library implement the interface ITypeDescriptorProvider:

The only method present in the interface returns the TypeDescriptor for the class implementing the interface.

The TypeDescriptor class is like this:

A class implementing ITypeDescriptorProvider returns a new instance of the TypeDescriptor class where all the attributes, properties, methods are events supported by the class have been added using the AddXXX instance methods. The CreateParameter method is used with the AddMethod method to specify the parameters for the method.

The information about a particular instance is stored in four dictionaries (_attributes, _events, _methods and _properties). The static methods AddType and GetType are used to register types and to get information about the registered types in the system. The TypeDescriptor class has a static field called _registeredTags (of type hashtable), where it stores a hashtable of typeNames and its associated type, using the tagPrefix as key. This is mainly used by the xml-script infrastructure as we’ll see in a future post. The Unload method erases the information stored in the _registeredTags hashtable.

The other methods are self explanatory.

Events

The event mechanism implemented by the library is very reminiscent of the .NET one, although it has some differences.

An event is an instance of the Type.Event class:

An event is declared like this:

And to subscribe to the event we have to write the following code:

the onPropertyChange method will be called when the event is fired. The method should have a signature like this:

And the first parameter will be the object that fired the event, and the second parameter will be the arguments specific for the event.

The arguments are an instance of the class EventArgs or any of its subclasses:

Note that the EventArgs class implements the ITypeDescriptorProvider interface explained before.

The Event class implements the IDisposable interface that is like this:

yes, the same as .NET.

The Event class has methods to add and remove event handlers and also to add and remove actions. What is an action? Actions will be covered in more detail in a future post but for now think of them as tasks that can be executed before the event handler is called or after the event handler is called.

The Event constructor takes a Component as the first parameter, because actions operate on components. The autoInvoke parameter is used to call to a handler when adding it to the event if the event has already been fired. This is useful because some critical methods should be called in response to events that may happen before the full Microsoft AJAX Library has been initialized.

Additions to the default JavaScript objects

The library adds some methods to the default JavaScript objects to make them more .NET alike:

Boolean -> parse
Number -> parse
String -> startsWith, endsWith, lTrim, rTrim, format, localeFormat
Array -> add, addRange, cloar, clone, contains, dequeue, indexOf, foreach, insert, remove, removeAt, parse, get_length, get_Item. Also, Array implements the IArray interface (get_length, get_Item).

RegExp -> parse

Error -> createError (that is the replacement for: throw new Exception(…) in the .net framework.

Date -> toFormattedString, serialize

In the next post I’ll talk about the Component class and related classes. There is a lot of theory behind it to fully understand all the details involved…

The health monitoring in ASP.NET 2.0 is a framework to generate and capture events during the life of the application. The health monitoring uses the provider model. A health monitoring provider can capture events and do any processing with them (log them, send them by email, etc). There are a lot of predefined events and we can create our custom events. As we will see, it is very easy to use the health monitoring system, but we need a solid understanding of the different elements involved.

To configure the health monitoring system we have to use the web.config. The health monitoring section has to be placed inside the <system.web> section and has the following structure:

The healthMonitoring element has two attributes:
• enabled: specifies if the health monitoring system is enabled or not.
• heartbeatInterval: the system will raise WebHeartbeatEvent with the frequency specified here (more on this later).

Buffer modes:

There are some events that can be buffered so the provider saves some events in memory before doing some work with them. The buffering options are specified in the providers in the bufferModes subsection, and then a buffered provider points to a buffer mode in order to use buffering. The buffer mode specifies the number of events of the buffer and the flushing frequency and intervals.

The default buffer modes are (extracted from the global web.config):

The name attribute is used to associate a buffer mode with a provider. The maxBufferSize attributes specifies the maximum number of events that can be buffered before flushing them.

Usually, events are flushed at constant intervals specified by the regularFlushInterval. However, some times is better to flush events more quickly than the regularFlushInterval. When the number of buffered events is greater or equal than the urgentFlushThreshold, the events will be flushed at an interval specified by the urgentFlushInterval.

The maxFlushSize specifies the maximum number of events to process when flushing.

The maxBufferThreads attribute specifies the maximum number of threads used for flushing.

For example, suppose we are using a provider that saves the events to a DB using the “Logging” buffer mode. The buffer can hold up to 1000 events. Usually, the events will be saved every 30 minutes, but if there are 800 or more events waiting to be logged, they don’t have to wait 30 minutes to be saved, they will be saved at 5 minutes intervals, until there are less than 800 in the buffer, as the provider will save only 200 events at a time.

Providers:

A provider is a class that inherits from System.Web.Management.WebEventProvider. In the providers configuration subsection we can add the providers that we want in order to process the captured events. However, the association of providers and events to capture is made in the rules section that will be explained later. The provider has 2 common attributes, name and type. Each specific provider can have more attributes needed for its respective tasks. The name type is used for referencing the provider in different sections and the type specifies the class and assembly where the provider is located.

This class diagram shows the available providers:

The available providers are:

• SqlWebEventProvider stores events in a Sql Server database.
• EventLogWebEventProvider stores events in the windows event log.
• TraceWebEventProvider passes events to the Trace object.
• WmiWebEventProvider maps events to WMI events.
• SimpleMailWebEventProvider sends emails with event notifications.
• TemplateMailWebEventProvider uses a template to format the emails that sends with event notifications.

To configurate the Sql Server database for the SqlWebEventProvider take a look here.

The WebEventProvider class has 3 abstract methods:

The buffered event providers (Sql server provider and the mail providers) inherit from the BufferedWebEventProvider class that provides the basic infrastructure for a buffered provider:

A buffered provider has two extra parameters, buffer and bufferMode. Buffering is only used if buffer=”true”. If buffering is used, bufferMode links the provider with a buffer mode that was explained in the previous section.

The default configuration for the providers is (extracted from the global web.config):

Profiles:

Some events should be always logged using a provider, but sometimes, an event can happen a lot of times per second if an important error surfaces, so the profile subsection can help to configure if we have to log all events received or if we can ignore the same event for a short period of time.

A group of events can be assigned a concrete profile in the rules section as we’ll see soon.

The default configuration for the profiles is (extracted from the global web.config):

The name attribute is used to associate an event with the profile. The minInstances indicates the minimum number of occurrences of an event before the event is logged. The maxLimit is used to stop logging an event after the number of occurrences of the event is greater or equal to this value. The minInterval can be used to avoid logging events if the interval between events is less than the minInterval.

The custom attribute can be used to do more complex evaluations to check if the event should be sent to the providers. See the IWebEventCustomEvaluator interface for more information.

As you can see, there are two predefined profile modes: the Critical, that logs every event without exception; and the Default, that avoids logging the same event twice in a minute.

Event Mappings:

In this configuration subsection, we associate a name with an event or group of events.

Without knowing a bit of the event types we can’t understand the health monitoring system, so here it is an introduction to the different event classes:

The WebHeartbeatEvent event can be raised periodically to give information about the status of the application (thread count, managed heap size, number of app domains, requests queued, requests executing, request rejected, information about the working set, etc).

The WebApplicationLifetimeEvent represents an important event in the application life cycle (application start, application shutdown, etc) and the information that can give you is very important, as you can analyze why your site is shutting down. For example, these are some constants that specify the shutdown reason:

ApplicationShutdownUnknown
ApplicationShutdownHostingEnvironment
ApplicationShutdownChangeInGlobalAsax
ApplicationShutdownConfigurationChange
ApplicationShutdownUnloadAppDomainCalled
ApplicationShutdownChangeInSecurityPolicyFile
ApplicationShutdownBinDirChangeOrDirectoryRename
ApplicationShutdownBrowsersDirChangeOrDirectoryRename
ApplicationShutdownCodeDirChangeOrDirectoryRename
ApplicationShutdownResourcesDirChangeOrDirectoryRename
ApplicationShutdownIdleTimeout
ApplicationShutdownPhysicalApplicationPathChanged
ApplicationShutdownHttpRuntimeClose
ApplicationShutdownInitializationError
ApplicationShutdownMaxRecompilationsReached

The WebRequestEvent event is raised at every request and contains information about the IP of the user that makes the request, URL of the request, etc.

The WebBaseErrorEvent class is the base class for all events that report error conditions. The WebErrorEvent event is raise when configuration or code problems arise (for example, when the code throws an unhandled exception). The WebRequestErrorEvent event is raised when there is an error with a request (for example, a deserialization error in the ObjectStateFormatter).

The WebAuditEvent class is the base class for success (WebSuccessAuditEvent) or failure (WebFailureAuditEvent) of security related operations. When an user try to log in the web application, a WebAuthenticationSuccessAuditEvent WebAuthenticationFailureAuditEvent if the login process completed successfully or not. If the view state has been altered, the WebViewStateFailureAuditEvent will be raised.

The default event mappings are (extracted from the global web.config):

The name attribute is used to associate a rule with a provider and a group of events as we’ll see in the rules section. The type specifies a class of event that is mapped to the event group. Note that all derived classes are also mapped by the same event group.

The startEventCode and the endEventCode attributes are used to specify a range of event codes. The event code is also saved with the event and helps in the identification of the event.

As a summary, the default web.config has this mapping:

All Events -> WebBaseEvent
Heartbeats -> WebHeartbeatEvent
Application Lifetime Events -> WebApplicationLifetimeEvent
Request Processing Events -> WebRequestEvent
All Errors -> WebBaseErrorEvent
Request Processing Errors -> WebRequestErrorEvent
All Audits -> WebAuditEvent
Failure Audits -> WebFailureAuditEvent
Success Audits -> WebSuccessAuditEvent

Note that the constructor for these events is protected so you can’t create instances of the predefined events. Instead you should create your custom event inheriting from the appropriate event class.

Rules:

This configuration subsection is where all the associations and entities seen earlier take place.

The default configuration for the rules is (extracted from the global web.config):

The attributes for each rule are:
 * name: a string representing the name of the rule.
 * eventName: associates an event group with this rule.
 * provider: the provider to use to log the events generated of the eventName group.
 * profile: associates a profile with this rule (this isn’t required).
 * minInstances, maxLimit, minInterval and custom: have the same meaning than in the profile configuration subsection, but if you set its value, these settings override the settings of the profile.

For example, the first rule is called “All Errors Default”, and captures all events from the “All Errors” group, that is, all events derived from WebBaseErrorEvent, to the EventLog provider. The events are logged starting with the first event, but only the first event is saved if there are similar events in the same minute.

The second rule (called “Failure Audits Default”) saves events from the “Failure Audits” event group (events derived from WebFailureAuditEvent, that gets triggered in an unsuccessful login operation) to the EventLog provider, with the same profile properties as the previous rule.

Note that minInstances, maxLimit, minInterval and custom are redundant here because the Default profile has the same attributes.

Example of use:

To use the SqlWebEventProvider in our own application we have to create the necessary tables and stored procedures. One way is to use the aspnet_regsql.exe application. If we have direct access to the server (remote connections are allowed) we can use this:

aspnet_regsql -S MyServer -d MyDataBase -U MyUserName -P MyPassword -A w

If our server doesn't allow remote connections, we can generate the a script to run using:

aspnet_regsql -d MyDataBase -U MyUserName -P MyPassword  -A w -sqlexportonly addwebevents.sql

Another option to generate the required sql infrastructure if we're running in full trust is to execute this code:

After the required sql infrastructure has been created, you have to configure the health monitoring system using the web.config. An example of the configuration to log appliaction lifetime events and errors is:

If you have used another event logging library like log4net or the enterprise library you may wonder if it is better to use them instead of the health monitoring system. My advice is that your project has only a web scenario and you don’t have to maintain legacy code that uses log4net or the enterprise library, just use the health monitoring system. Otherwise use log4net, the enterprise library or any other logging solutions that you want.

I think this is enough for an introduction to the health monitoring system. I may post more in depth information about it in a future if time permits.

I have started to look at Atlas. The first thing I have played with is the layer to provide better OOP features for Javascript.

Note: this is based on an early version of the product (July CTP), so this information can change for the final release.

Javascript OOP features

Javascript is a prototype-based object oriented language. This means that every object has a prototype, an object from which it inherits properties and methods. The prototype is a shared property of the class that can be accessed like this:

myClass.prototype

As Javascript is an interpreted language, when the interpreter founds an expression like:

myObject.myProperty

first it checks if the object instance “myObject” has a property called “myProperty”. If not, then it tries to find that property in the prototype object of that class (myClass.prototype.myProperty). This prototype relationship is recursive, because the prototype is an object that can have a prototype, so this recursion ends only when Object is reached, the superclass of all objects.

In Javascript, a class is defined by a function (the constructor) and its prototype (that defines the properties and methods that each object instance has by default, because of how the interpreter evaluates the expressions).

So, to define a class in Javascript we have to do this:

If we want to add a method to the class we can do it like this:

Or like this:

What's the difference? Consider the following class:

If we instantiate two objects of the class TestClass, we can see the difference:

This diagram shows the internal representation of the object:

As you can see, the method declared using the prototype is shared between instances of the class. However, the method added in the constructor is created for each instance. So:

objTestClass1.method1 != objTestClass2.method1
and
objTestClass1.method2 == objTestClass2.method2

Basically, the prototype is the only “object oriented mechanism” present in Javascript. As you can see it is not an usual object oriented language. Using the prototype you can come up with your own solution to simulate a more complete object oriented language (inheritance, virtual methods, calling the base method, etc).

Atlas OOP features

Atlas adds some valuable features to provide a more natural object oriented programming models. What Atlas offers is:
• namespaces
• inheritance
• properties
• defining virtual methods
• calling base methods
• interfaces
• enumerations
• attributes
• reflection

Namespaces

To create a namespace in Atlas you have to write something like:

Internally Atlas adds a Type property to the window object (the default Javascript context), and assigns it the Function built-in type. Atlas adds a lot of methods and properties to Function, as we’ll see later.

The registerNamespace function splits the namespace by the dots and creates a hierarchy of objects in the window object that resemble the namespace. For example, for the namespace Manu.Atlas.Tests the following properties are created:

Inheritance

Atlas theorically supports multiple inheritance, but in the July release it isn’t working properly. Anyway, multiple inheritance support will be removed before the final version, so don't count on it.

A class in Atlas has to be registered to work properly. The syntax to register a class is:

FullClassName.registerClass(typeName, baseTypes, interfaces)

Only the first parameter is mandatory. The second parameter specifies the base class or base classes if multiple inheritance is used. The second parameter could be a reference to the base class or an array of type names for the base class (or classes). The third parameter is the interface implemented by the class (if any). A class can implement multiple interfaces so you can call registerClass with more than 3 parameters. Any extra parameter should be an interface that is being implemented by the class.

Atlas adds some information to each class type it creates to provide the necessary machinery for the object oriented features:

• _typeName field: with the name of the type (the function getTypeName returns it).
• _baseType field: a reference to the parent type (the function getBaseType returns.
• _basePrototypePending property: a boolean that is used to know if the class has been initialized (more on this later).
• _interfaces: an array with references to the interfaces implemented by the class.
• bases: an array with references to the parent classes.
• _interface, _sealed and _abstract boolean properties to give information about the type.
• _baseMethods: a hash table where methods that can be called by child classes are stored.

The core of the inheritance mechanism is handled by the initializeBase function that has to be called in the constructor of a derived class. The syntax is:

FullClassName.initializeBase(instance, baseArguments)

Where the first parameter is the instance to be initialized and the second parameter is an array of arguments to pass to the base constructor.

The initializeBase method starts calling the constructor for each interface in the class (stored in the _interfaces collection). Then calls the _setBases method and finally calls the _callBaseConstructors method.

The _setBases method does an important job. If the class inherits from another class, the method iterates through all the base classes, filling the bases collection, and recursively calling the _setBases method on the base classes. After the _setBases method has been called for a base class, the _copyProps method is called. The _copyProps method iterates through all properties and methods stored in the prototype of the base class and stores them in them in the prototype of the subclass. So, after the call to _copyProps, the subclass also has the properties and methods specified in the prototype of the base class.

The _callBaseConstructors method iterates through the bases array, calling the base constructor with the current object instance.

So, after calling the initializeBase method, the object has all the properties and methods of the base classes, giving the illusion of inheritance.

If we declare the methods and properties in the prototype, they will be created in the child classes in the _copyProps method. If we create the properties and methods in the constructor, they will be created in the child classes in the _callBaseConstructors method.

An example of a class B that inherits from A is:

Note that we have created the properties and methods using the prototype in order to save memory. We can declare the A class like this:

And it will be functionally equivalent although it will be more expensive in memory terms as each object instance will have 4 methods instead of sharing them (as explained before). This mode of creating a class is called the closure model. The previous one is called the prototype mode.

If we create an object of type B, we can call the base properties. In the following sample, the last line evaluates to 3:

There are more functions to register a class, depending on the behaviour of the class:
registerSealedClass and registerAbstractClass. The name clearly shows when to use them although they just set a property and call to the registerClass method. If a class is registered using registerSealedClass any class inheriting from it will not have its members copied because the _setBases method will not be called although no error will appear.

The Function built in type is also extended with some methods to check interface implementation, inheritance and type:
• implementsInterface
• isImplementedBy
• inheritsFrom
• isInstanceOfType

Properties

As javascript doesn't have properties like C#, the recommended approach (and what is used in the atlas library) is to provide a getter and a setter method for properties with the signature get_propertyName set_propertyName as we did earlier for the Manu.Atlas.Tests.A class. It is really important that the getter starts with "get_" and the setter with "set_" as this is mandatory for integrating our custom components into the Atlas framework as we will see in a future.

Methods

The initializeBase method provided most of the machinery for the OOP with Atlas, but there is something missing: how to call a base method from an overridden method.

Atlas provides 3 methods related to this problem:
• registerBaseMethod
• callBaseMethod
• getBaseMethod

The first one is saves a method in the _baseMethods hash table, in order for a child class to call to the base class implementation. The child class has to call to the callBaseMethod for this, and the implementation of callBaseMethod uses the getBaseMethod method in order to obtain a reference to the base method.

There is no need to call to the registerBaseMethod if we define our methods using the prototype because the getBaseMethod searchs the method in the prototype if it isn’t found in the _baseMethods hash table.

An example of a class with a method that calls the base method follows:

The Function built in type is extended with two static functions to help when creating a class or an interface:
• abstractMethod: method that throws an exception if called.
• emptyFunction: the name says it all.

I’m running out of time now so in another post I’ll finish talking about the OO features of Atlas.

I was going to start posting about Atlas, but as you have probably read here, now Atlas has a new name and the next version will have some changes to reflect the new product name.

I think it is better to wait for a few days to see if a new Atlas version gets released in order to create samples that work with the latest version. If the next version does not get released soon I'll start posting about atlas anyway so stay tunned.

The NDoc creators where spending a lot of time with the project with very little (if any) economic reward as it is happening in most open source projects (my personal experience with M.A.M.E. was even worse, because us (the developers) didn’t get a buck but a lot of people outside the team were getting tons of money, illegally selling it in cabinets or creating commercial console (or computer) arcade packs using the MAME source code without permission…) So, they have discontinued NDoc.

As Visual Studio 2005 didn’t come with a documentation generator (as Visual Studio 2003 had) this was a big problem for the dot net community, but Microsoft reacted quickly and created SandCastle, a cool documentation project. The problem is that SandCastle is in beta stage and it doesn’t have any GUI yet so you have to run several executables one after another to get the documentation. You can download the current version here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=E82EA71D-DA89-42EE-A715-696E3A4873B2&displaylang=en

And there is a nice blog about information in how to use the executables to get the documentation done here:

http://blogs.msdn.com/sandcastle

As most people (myself included) don’t want to spent a lot of time and neurons in order to build a CHM documentation file, Eric Woodruff has provided a nice GUI that makes using SandCastle straightforward (and it’s very similar to the one provided by NDoc):

http://www.codeproject.com/useritems/SandcastleBuilder.asp

If you are curious, here you have a screenshot of the generated CHM file using the most common settings:

And talking about sandcastles… here are two from my visit to Torrevieja (Spain) this summer:

As always the holidays seem to be too short, especially after the incident with my ankle that made me lost 2 weeks. This situation made me spent a lot of time reading some books I didn’t expect to read until the end of the year or beginning of 2007. The books I read were related to the new business intelligence features of SQL Server 2005:

In general terms the books were good, although in my opinion the part that talks about creating custom integration services components was too short. I haven’t finished the book about analysis services (I only read the first 9 chapters) and will not do it yet. The books assumes that you have a data warehouse to use as a base for analysis services but it didn’t explain how to build one so I think I’ll have to buy a good book about that. I have been told that The Microsoft Data Warehouse Toolkit does a good job so I’ll be purchasing it as soon as possible.

Something that I’m still thinking is how easily Reporting Services has become a better product than Crystal Reports even the second one has a lot of years in the market.

I’m interested in seeing what comes up when I put everything to work in a real project…

I’ll start to look deeply into Atlas this month so I hope I can find some free time to post some detailed posts about it.

I'm going on vacation until the end of august.

I'll be here and here most of the time.

Unfortunately I don't have internet access available but I'll be checking my email from time to time.

Of course I take a computer with me so I'll be learning something new this holidays (maybe Atlas or SSIS).

If you can understand portuguese I recommend you to take a look at Luis Abreu's webcasts about Atlas.

Have a nice month ;-)

The last post completed what I wanted to explain about data source controls.

As a summary, here is a full list of the posts about data source controls of the last months:

I explained the generalities of data source controls here:
* Data Source Controls - Under the hood (1/4)
* Data Source Controls - Under the hood (2/4)
* Data Source Controls - Under the hood (3/4)
* Data Source Controls - Under the hood (4/4)

The theory about designers is here:
* Introduction to designers
* ASP.NET designers. The ControlDesigner class
* ASP.NET designers. The DataSourceDesigner class
* DataSourceDesigners... Non visual controls?

A custom data source control sample with full design time support:
* A custom DataSourceControl sample
* Creating a custom DataSourceDesigner

I hope you find them useful.

We will create a designer for the CustomDataSource we created here.

As we explained in a previous post about the DataSourceDesigner class, the main tasks that have to be performed by a DataSourceDesigner are:
• configuring the data source
• exposing schema information

Also, we have to expose at least one DesignerDataSourceView (A DataSource control exposes one or more DataSourceViews and a DataSourceDesigner exposes one or more DesignerDataSourceViews):

As you can see the code is very similar to the one used in the custom data source to expose the custom data source view. As our data source will only retrieve data, the default implementation of the DesignerDataSourceView is enough for all CanXXX properties.

In order to quickly configure our custom DataSource we’ll provide a GUI that will let us choose the TypeName and the SelectMethod using DropDownLists:

In order to be able to show the Configure Data Source dialog we need to override the CanConfigure property and implement the Configure method:

As the GUI will change several properties at a time we have to create a transacted change in order to provide undo functionality.

The form fills the first dropdownlist with all available types using the type discovery service instead of reflection. Why? Because using reflection we can only get all types of the compiled assemblies. However, we can add more types without having compiled the project or we can have types that don’t compile and the type discovery service will also show them, so it is a lot better to use the type discovery service instead of reflection.

In the code we haven’t removed types that probably will not be candidates for our TypeName property (generic types, interfaces) in order to keep code as simple as possible:

The TypeItem class is a class used to store types in the dropdownlist.

When a type is selected from the first dropdownlist, the other dropdownlist gets populated with the methods of the selected type:

To quickly get and set the TypeName and the SelectMethod from and to the form we have defined those properties in the form as follows:

Note that to simplify code when the SelectMethod property is set, the selected method from the dropdownlist will be the first method with the same name as the SelectMethod (no parameters are checked to simplify code, but for production code you’ll probably want to check that the parameters match).

In the FillMethods method, the type is obtained using the GetType method that used the resolution service (for the same reasons we specified before for using the type discovery service). In order to simplify the code we have not removed some methods that certainly will not be the proper method like property getters and setters or abstract methods.

When the user clicks the Accept button in the Configure data source form, the code that gets executed is:

We save the Type and the SelectMethod and refresh the schema.

To provide schema information, we have to return true in the CanRefreshSchema method and we have to implement the RefreshSchema method. When we provide schema information the controls can provide field pickers (i.e. columns for a GridView) and generate templates based on the schema information (i.e. a DataList bound to our data source control). However, we can not return true for the CanRefreshSchema, because we can return schema information only if the user has configured the data source:

To implement the RefreshSchema method, we need to extract the schema information and generate the SchemaRefreshed event. If a data source control can provide schema information, the schema information will be retrieved from the property Schema from the underlying DesignerDataSourceView. However, the SchemaRefreshed event doesn’t have to be raised everytime, only if the data source returns a different schema. To see why this is important think about this: if the data source is bound to a GridView, every time the RefreshSchema event is raised, the designer will ask if it has to regenerate the columns and the data keys. So we’re interested in raising the SchemaRefreshed event only when the schema changes. We use the designer state to store the previous schema, and when the RefreshSchema method is called, we will check if the schema has changed, raising the SchemaRefreshed event only in that case.

The code related to the RefreshSchema method is:

As you can see, we get the MethodInfo for the SelectMethod and get the return type. All hard work to expose schema information is done by the framework helper class TypeSchema that was explained in the post about DataSourceDesigners. The DesignerDataSource view exposes the saved schema:

The last thing that needs clarifying is that we have overridden the PreFilterProperties method in the CustomDataSourceDesigner class in order to modify how the TypeName and SelectMethod properties work, because when any of those properties change, the underlying data source and schema will probably change, so we have to notify it to the associated designers:

The full source code of the designer and the data source control are in the files at the end of this post. As you can see, adding design time support to a data source control is not terribly complicated but you have to write quite a bit of code (1300 lines in this sample) even for simple data sources. The more complex is your data source, the more code that you will have to write.

The design time support covered here for this data source is the most common scenario: the data source control doesn’t render any HTML at run time and it only exposes a form to configure the data source. However, a data source control can also render HTML in some cases (take a look at the PagerDataSource) being not only a data provider but also a data consumer. If you want to render HTML with your data source control you have a lot of work to do as the framework doesn’t have any base classes for data source controls that also render HTML.

CustomDataSourceDesigner.zip (13.5 KB)

CustomDataSourceDesigner_sampleweb.zip (26.77 KB)

Here are some common questions and answers about the ObjectDataSource.

Why my SelectCountMethod needs a StartRowIndex and MaximumRows parameters in order to work properly?

The answer is that they are not needed. However, the ObjectDataSource will call the SelectCountMethod with all the parameters present in the SelectParameters collection. If you have enabled paging in the ObjectDataSource, the StartRowIndex and MaximumRows parameters will be added to the signature of the SelectMethod even if they are not in the SelectParameters collection. Usually the StartRowIndex and MaximumRows parameters will be set automatically by the control bound to the ObjectDataSource so there is no need to have them in the SelectParameters collection so if you remove them the SelectCountMethod will not need them. The same happens to the SortParameter. Most examples take the StartRowIndex and MaximumRows because when the method is selected in design time, all the parameters are persisted as parameters in the SelectParameters collection.

Can I use an interface as the TypeName in the ObjectDataSource?

The ObjectDataSource designer will not let you choose an interface in the first step of the wizard, and if you have specified the TypeName in the ASPX and you then run the designer, the methods associated to the interface will not be shown, so if you want to use interfaces with the ObjectDataSource you lost design time support. If you configure the ObjectDataSource to use the methods from an interface a runtime error will happen:

Cannot create an instance of an interface.

because the ObjectDataSource will try to create an instance of the Type specified in the TypeName property (if the method to call is an instance method). However if you handle the ObjectCreating event, you can create an instance of an object that implements the interface specified by the TypeName property and assign it to the ObjectInstance property of the event arguments. That will make everything will work as expected.

I have a GridView bound to an ObjectDataSource. I have a SelectParameter for the sorting with a DefaultValue specified. However, when the page initially loads the DefaultValue is never used. Why?

When the GridView needs data, a select operation is performed in the underlying data source control. Before this operation is performed, a method called CreateDataSourceSelectArguments is called on the GridView. This method creates the arguments that will be passed to the Select method of the ObjectDataSource, which in turns calls the method specified by the property SelectMethod. In the CreateDataSourceSelectArguments method, the SortExpression is set based on the GridView’s state and the ObjectDataSource just assign that value to the sort parameter. So, as you can see, the DefaultValue is never used for the sort parameter.

Being able to dynamically call an arbitrary method on an object or the ability to get/set any arbitrary property by name at run time is very important when it comes to do some generic stuff. In .NET Framework 1.x the only way to do that was using reflection and that means to do it slow. For simple things or if we don’t have a lot of concurrent users we can live with it, but sometimes the performance is important and reflection isn’t an acceptable solution.

Fortunately, the .NET Framework 2.0 introduces a new class that let us to quickly call an arbitrary method without the overhead of a reflection call. How? Well, the idea is to generate the same MSIL as the compiler generates when calling a function but on the fly, and then we obtain a delegate that when called will execute the MSIL we have just created. This is really useful in a lot of scenarios!

I read something about this in Marc’s blog (http://musingmarc.blogspot.com/) but I didn’t have time to look at it in more detail in that moment. Today I read an article at codeproject that talked about this (http://www.codeproject.com/useritems/FastMethodInvoker.asp) so I finally forced myself to spend some time playing with dynamic MSIL code generation and I’m quite impressed with the possibilities.

If you want to play with this you should download an excellent debugger visualizer that will let you show the MSIL generated by a DynamicMethod:

http://blogs.msdn.com/haibo_luo/archive/2005/10/25/484861.aspx

I have made a little helper class (based on the codeproject article) that can be used to replace MethodInfo.Invoke, PropertyInfo.GetValue, PropertyInfo.SetValue and Activator.CreateInstance that are the reflection methods that I use most often. In order to use it in your own projects, remember to cache the delegates obtained because every time you call the CreateDelegate the MSIL generation takes place and that takes some time.

I have also created a simple test to show a comparison between direct calls, reflection calls and dynamic method calls. The results are here:

------ Object Creation ------
direct - object creation: 63ms
dynamic method - object creation: 86ms
reflection - object creation: 391ms
------ Property Get ------
direct - property get: 21ms
dynamic method - property get: 81ms
reflection - property get: 1849ms
------ Property Set ------
direct - property set: 21ms
dynamic method - property set: 67ms
reflection - property set: 2476ms
------ Instance Method Call ------
direct - instance method call: 24ms
dynamic method - instance method call: 154ms
reflection - instance method call: 3266ms
------ Static Method Call ------
direct - static method call: 36ms
dynamic method - static method call: 157ms
reflection - static method call: 3139ms

To summarize:
• For object creation, using reflection is 6.2 times slower than direct object creation. With DynamicMethods is only 1.3 times slower than direct object creation. Using DynamicMethods is about 4.5 times faster than using reflection.
• To get a property using reflection is 90.1 times slower than direct property access. With DynamicMethods is only 3.8 times slower than direct property access. Using DynamicMethods is nearly 23 times faster than using reflection.
• To set a property using reflection is 117.9 times slower than direct property set. With DynamicMethods is only 3.2 times slower than direct property set. Using DynamicMethods is about 37 times faster than using reflection.
• For instance method invocation, using reflection is 136.1 times slower than direct method call. With DynamicMethods is only 6.4 times slower than direct method call. Using DynamicMethods is about 21 times faster than using reflection.
• For static method invocation, using reflection is 87.2 times slower than direct method call. With DynamicMethods is only 4.3 times slower than direct method call. Using DynamicMethods is about 20 times faster than using reflection.

I’m going to modify my ExtendedObjectDataSource to use DynamicMethods in order to gain a 20x speed increase compared to reflection calls.

The code used for the tests and the helper class for the DynamicMethods are shown here and can be downloaded at the end of this post: