.NET 2.0

ConfigurationErrorsException - The configuration is read only.

Steve Michelotti — Wed, 15 Aug 2007 02:23:29 GMT

The .NET 2.0 Configuration API is a huge step up from the previous versions of the framework rendering many other previous configuration framework (Enterprise Library Configuration block, etc.) virtually obsolete. However, one thing that can trip people up is when they try to assign to a configuration property at run-time you can get a ConfigurationErrorsException - The configuration is read only even when a setter is defined on their property:

[ConfigurationProperty(item1Property, DefaultValue = 1, IsRequired=true)]
[IntegerValidator(MinValue=1, MaxValue=100)]
public int ConfigItem1
{
get { return Convert.ToInt32(this[item1Property]); }
set { this[item1Property] = value; }
}

The ConfigurationSection inherits from ConfigurationElement which defines a virtual method for IsReadOnly(). If you want to avoid this exception and actually assign your values at run-time simply override this method in your ConfigurationSection or ConfigurationElement class like this:

public override bool IsReadOnly()
{
return false;
}

WinDbg real world example

Steve Michelotti — Wed, 15 Aug 2007 01:16:01 GMT

I recently had to debug a problem for my current client which was exceptionally weird and I was able to utilize WinDbg to help get to the bottom of the problem relatively quickly. Basically the application in question is an asp.net application that takes a custom object and puts in in an MSMQ message (which currently uses the default binary serializer). The class in question is marked with the Serializable attribute, has a couple of primitive members (e.g., ints, strings) and a couple of NameValueCollections. One of the NameValueCollections is assigned directly from the HttpRequest.Headers NameValueCollection like this:

myObject.Headers = request.Headers;

One day we started getting this error:

System.Runtime.Serialization.SerializationException: Type 'System.Web.HttpHeaderCollection' in Assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.

This made absolutely no sense since, like my class, the NameValueCollection class was also marked with the Serializable attribute. Not only that, but where was the System.Web.HttpHeaderCollection coming from?

So since I was already debugging, I took a memory dump of the asp.net process from the command line like this:

cscript.exe adplus.vbs -hang -p 1808 -quiet -o c:\temp

The "1808" was simply the PID of my w3wp.exe process and I output the dump to the c:\temp directory.

I then launched WinDbg and opened the crash dump that was produced in the previous step. First, you have to run (the sos extensions is what allows WinDbg to understand .NET 2.0):

.loadby sos mscorwks

So the first thing I wanted to see was all the types in memory and their corresponding method tables so I ran:

!dumpheap -stat

A snippet of the results:

00000642802ae6c0 5 320 MyNamespace.Foo

(just using Foo here for the class name. The real output included the fully qualified namespace with correct object name). The 00000642802ae6c0 is the method table for my Foo object. The 5 shows that we currently have 5 of my Foo objects loaded into memory. The 320 is the total size (320/5 tells me each of my objects is taking up 64 bytes).

Now I can narrow in on my issues a little bit. This shows me all 5 of the memory addresses for my Foo objects:

0:000> !dumpheap -mt 00000642802ae6c0
------------------------------
Heap 0
         Address               MT     Size
total 0 objects
------------------------------
Heap 1
         Address               MT     Size
00000000c0012e18 00000642802ae6c0       64
total 1 objects
------------------------------
Heap 2
         Address               MT     Size
000000010053b830 00000642802ae6c0       64
total 1 objects
------------------------------
Heap 3
         Address               MT     Size
0000000140235c60 00000642802ae6c0       64
0000000140430fd8 00000642802ae6c0       64
00000001405275d0 00000642802ae6c0       64
total 3 objects
------------------------------
total 5 objects
Statistics:
              MT    Count    TotalSize Class Name
00000642802ae6c0        5          320 MyNamespace.Foo
Total 5 objects

So now I'm going to pick one of these five objects and drill down further. I'll pick the one highlighted in blue that resides at 00000001405275d0:

0:000> !do 00000001405275d0
Name: MyNamespace.Foo
MethodTable: 00000642802ae6c0
EEClass: 00000642802baf08
Size: 64(0x40) bytes
(C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\e22c2559\92c7e946\assembly\dl3\fed41db4\000e24c3_21cac701\MyAssemblyName.DLL)
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
0000000000000000 4000028        8                       0 instance 0000000140527610 requests
0000064274e85620 4000029       10 ...meValueCollection 0 instance 0000000140528d60 headers
0000064274e85620 400002a       18 ...meValueCollection 0 instance 0000000140527838 extraRequestData
0000000000000000 400002b       20                       0 instance 0000000140527a38 userStateData
000006427881edc8 400002c       28        System.String 0 instance 0000000000000000 endOfLineData
0000064278825318 400002d       30       System.Boolean 0 instance                0 isOptOut

So I know the "headers" member is the one I want for focus on so I inspect that next:

0:000> !do 0000000140528d60
Name: System.Web.HttpHeaderCollection
MethodTable: 00000642bcefad78
EEClass: 00000642bcf3be38
Size: 120(0x78) bytes
(C:\WINDOWS\assembly\GAC_64\System.Web\2.0.0.0__b03f5f7f11d50a3a\System.Web.dll)
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
0000064278825318 4001165       44       System.Boolean 0 instance                1 _readOnly
00000642788426f0 4001166        8 ...ections.ArrayList 0 instance 0000000140528f78 _entriesArray
000006427881f650 4001167       10 ...IEqualityComparer 0 instance 00000000ffffc148 _keyComparer
00000642788448c8 4001168       18 ...ections.Hashtable 0 instance 0000000140529000 _entriesTable
0000064274e82360 4001169       20 ...e+NameObjectEntry 0 instance 0000000000000000 _nullKeyEntry
0000064274e9e7e8 400116a       28 ...se+KeysCollection 0 instance 00000001405481c0 _keys
0000064278857210 400116b       30 ...SerializationInfo 0 instance 0000000000000000 _serializationInfo
000006427882b338 400116c       40         System.Int32 0 instance               10 _version
000006427881d280 400116d       38        System.Object 0 instance 000000014054ad48 _syncRoot
000006427881f748 400116e      a70 ...em.StringComparer 0   shared           static defaultComparer
                                 >> Domain:Value 0000000000136900:NotInit 0000000000177700:00000000ffffc110 <<
00000642788d8ba8 4001179       48      System.Object[] 0 instance 0000000000000000 _all
00000642788d8ba8 400117a       50      System.Object[] 0 instance 0000000140548160 _allKeys
00000642bceef310 400101b       58 ...m.Web.HttpRequest 0 instance 00000001405265f0 _request
00000642bceef7b8 400101c       60 ....Web.HttpResponse 0 instance 0000000000000000 _response
00000642bcf3ad30 400101d       68 ...IIS7WorkerRequest 0 instance 0000000000000000 _wr

And NOW we see something extremely interesting. The headers member was supposed to be a NameValueCollection so why is my !do showing it to be an HttpHeaderCollection and what is this HttpHeaderCollection anyway and how is this System.Web DLL even compiling? So at this point, it's time for us to crack open trusty old Reflector and find its class definition:

internal class HttpHeaderCollection : HttpValueCollection

So this is an internal class to the System.Web DLL but it's being returned for a NameValueCollection property. Also notice that it is NOT marked with the [Serializable] attribute (which was our problem to begin with). It inherits from the HttpValueCollection (which is yet another internal class) and the HttpValueCollection (while it DOES have the Serializable attribute) inherits from the NameValueCollection object and THAT is how the code is compiling because of course this is a perfectly legal use of polymorphism.

So...in the end, all of these classes are marked with the Serializable attribute except for the HttpHeadersCollection (which I believe to have been an oversight on Microsoft's part) which is causing our serialization problems and we cannot control the internal code of System.Web. The fix ends up being pretty trivial - just iterate the NameValueCollection and adds the string primitives so that all serialization is happy.

But the real moral of the story is that this is a good real world example that shows how to debug an issue that, at first glance, seems impossible. Using WinDbg like this is a very repeatable process that can help you get to the bottom of memory issues (and others) quite fast.

WinDbg / SOS Cheat sheet

Steve Michelotti — Wed, 15 Aug 2007 00:30:28 GMT

This is a great post that anyone who works with WinDbg should check out:

http://geekswithblogs.net/.netonmymind/archive/2006/03/14/72262.aspx

Bookmark it - it will come in handy anytime you're debugging with WinDbg.

Build 64-bit MSI file on Cruise Control

Steve Michelotti — Sun, 18 Mar 2007 00:44:00 GMT

There is a known bug when trying to build 64-bit MSI files. That is, the wrong InstallUtilLib.dll is embedded in the MSI. A workaround to that problem is to use Orca to manually manipulate the MSI file in embed the correct version - the workaround is documented here. However, what if you want to automate this process on your build server? Orca is a windows appication requiring user input.

To automate this from the command line, you can leverage a few lines of VBScript code that essentially duplicates the Orca functionality. Specifically, what we are trying to do is embed the 64-bit version of InstallUtilLib.dll into the MSI so that the BadImageFormatException does not rear its ugly head. The key line of the VBScript is the SetStream method of the Record object. The complete VBScript solution is shown below and can simply be invoked from CCNet using a standard command line task such as the Exec MSBuild task with the appropriate command line arguments.

Option Explicit
On Error Resume Next

Const msiViewModifyInsert         = 1
Const msiViewModifyUpdate         = 2
Const msiViewModifyAssign         = 3
Const msiViewModifyReplace        = 4
Const msiViewModifyDelete         = 6

If (WScript.Arguments.Count = 0) Then
Msgbox("No command line argument specified for MSI location. Please try again.")
Wscript.Quit 1
Else
AdjustInstallUtil()
End If

public sub AdjustInstallUtil()
On Error Resume Next

dim msiInstance : msiInstance = WScript.Arguments.Item(0)
dim installer : Set installer = CreateObject("WindowsInstaller.Installer")
dim installerDb : Set installerDb = installer.OpenDatabase(cstr(msiInstance), 1)
dim sqlCommand : sqlCommand = "SELECT * FROM Binary WHERE `Name`='InstallUtil'"
dim view : Set view = installerDb.OpenView(sqlCommand)

view.Execute()
dim record : Set record = view.Fetch()

If Not record Is Nothing Then
  const dataCol = 2
  record.SetStream dataCol, "C:\Program Files\CruiseControl.NET\64BitMSI\InstallUtilLib.dll"
  view.Modify msiViewModifyUpdate, record
  installerDb.Commit
End IF

'clean up
Set installerDb = Nothing
Set view = Nothing
Set installer = Nothing

'Error Handling
If Err.number > 0 Then
   Msgbox("Error while adjusting x64 InstallUtilLib: " & Err.Description & ": " & Err.Source & ": " & Err.number)
End If
end sub

Validation framework on CodePlex

Steve Michelotti — Fri, 24 Nov 2006 00:14:00 GMT

This past summer I had an article published in Visual Studio magazine in which I outlined a Validation framework that I created to declaratively validate business objects. Simon Cropp has taken the initiative to put the source code up on CodePlex as an open source community project. It can be found here:

http://www.codeplex.com/ValidationFramework

Error MSB6006: "aspnet_merge.exe" exited with code 1 - Web Deployment Project

Steve Michelotti — Mon, 31 Jul 2006 22:47:00 GMT

This error often rears its ugly head when compiling an ASP.NET 2.0 Web Deployment Project. At first glance, it is extremely difficult to troubleshoot because there is not much information along with the error. In order to troubleshoot this, you need to use a higher level of verbosity. If you're using MSBuild from the command line you can use the /verbosity switch like this (and then look at Output window for build):

C:\projects>msbuild YourSolutionFile.sln /t:Rebuild /p:Configuration=Release /verbosity:detailed

If you're using Visual Studio, then you can set Tools - Options like this:

Typically the problem is that when aspnet_merge merges the entire web project into a single assembly, you might find naming collisions. By default, asp.net 2005 web site applications do not put a default namespace in the class files so if you create MyPage.aspx in the root and also in a sub-folder, this would causes a conflict when merged into a single assembly for the Release build. This problem would not manifest itself during development because you're not pre-compiling the entire web site into a single DLL so there are several DLLs that make up the web project and naming collisions are avoided. To fix the problem you can obviously either rename one of the classes or provide a namespace to avoid the conflict.

Visual Studio Magazine Article on Validating Business Objects

Steve Michelotti — Tue, 27 Jun 2006 21:45:00 GMT

I just had an article published in the June issue of Visual Studio magazine. The article essentially presents a flexible framework for validating business objects utilizing attributes.

http://www.visualstudiomagazine.com

This is my first time in “print”! The direct link to my article is:

http://www.ftponline.com/vsm/2006_06/magazine/features/smichelotti/

A couple of people had trouble downloading the code from the VSM site. Alternatively, it can be downloaded here:

http://www.4shared.com/file/2397388/6e60ba0b/validationframework.html

Visual Studio Magazine Article on Validating Business Objects

Steve Michelotti — Tue, 27 Jun 2006 21:19:00 GMT

I just had an article published in the June issue of Visual Studio magazine.

http://www.visualstudiomagazine.com

This is my first time in “print”! The direct link to my article is:

http://www.ftponline.com/vsm/2006_06/magazine/features/smichelotti/

A couple of people had trouble downloading the code from the VSM site so I'm happy to provide directly. The article essentially presents a flexible framework for validating business objects utilizing attributes.

GridView - Set column properties at run-time

Steve Michelotti — Thu, 30 Mar 2006 22:51:00 GMT

An interesting issue came up today that, although it now looks simple, did not have an immediately obvious solution. Specifically, what if you want to set properties of individual columns of a GridView at run-time (via C# code) rather than at design time in the aspx code.

For example, let's say you want to set the DataFormatString property of a BoundField column. In short, it is a 2-part solution. First, you must positionally extract your column out of the GridView's Columns property while casting it to your desired type (in this case a BoundField). Second, after you have set the properties, do the databind. So if you have column that you want to format as currency, the code might look like this:

BoundField priceField = grid.Columns[0] as BoundField;
priceField.DataFormatString = "{0:c}";
priceField.HtmlEncode = false;
grid.DataSource = list;
grid.DataBind();

Note that since you're manually doing the data binding this will preclude you from using the ObjectDataSource in this case (since that happens before your user code in the Page_Load event).

Taking this one step further, you could even add columns dynamically at run-time doing this:

BoundField someField = new BoundField();
someField.DataField = "Price";
someField.DataFormatString = "{0:c}";
someField.HtmlEncode = false;
grid.Columns.Add(someField);

Note: One reason this might throw you off at first is that in the C# intellisense, BoundColumn comes up first and if you're not watching carefully you might try to use that instead of BoundField which will prevent you from compiling!

Real world example of C# Anonymous Methods

Steve Michelotti — Tue, 21 Mar 2006 12:51:00 GMT

Often when a new language features come out (in this case anonymous method) we often see syntax examples like this:

delegate void SomeDelegate();
public void InvokeMethod()
{
SomeDelegate del = delegate()
      {
       MessageBox.Show("Hello");
      };
del();
}

and we say, great but when is code like THAT ever going to be useful to me? In that trivial example, of course that's not very useful. But when you consider the power anonymous methods gives you both to pass in parameters and also make use of local objects then tons of possibilities are opened up for making code more concise and efficient. Consider a case where you're using a DataReader to read multiple result sets. Your code might look something like this:

public Person GetPerson(int personID)
{
//(Perform data access code here to create DataReader)
Person person = new Person();

if (dr.Read())
{
  person = personMapper.BuildItem(dr);
}

dr.NextResult();
if (dr.Read())
{
  person.Address = addressMapper.BuildItem(dr);
}

dr.NextResult();
if (dr.Read())
{
  person.EmploymentInfo = employmentMapper.BuildItem(dr);
}
}

This code is now littered with IF statements and dr.NextResult() method calls. To make this more concise, you could create a simple method that passes in a delegate that you can use anonymously:

public static void ReadNextResult(NullableDataReader dr, Execute execute)
{
dr.NextResult();
if (dr.Read())
{
execute();
}
}

Then the consuming code can simply look like this:

public Person GetPerson(int personID)
{
//(Perform data access code here to create DataReader)
Person person = new Person();

DataUtil.ReadNextResult(dr, delegate()
{ person = personMapper.BuildItem(dr); });

DataUtil.ReadNextResult(dr, delegate()
{ person.Address = addressMapper.BuildItem(dr); });

DataUtil.ReadNextResult(dr, delegate()
{ person.EmploymentInfo = employmentMapper.BuildItem(dr); });
}

Notice that because of the use of anonymous methods, not only can we pass in the DataReader to the method but also we can use local objects (e.g., the “mapper” objects) inside the anonymous methods. Internally the C# compiler creates private nested classes containing the delegates we want to execute that have member variables that are assigned the “local object” references which is why it's possible to pull this off in-line rather than having to create a completely separate method.