I have been running into some situations WCF barfs on calls where the message body is very large:

"The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 3, position 9381."

Took a little poking around to see what exactly was going wrong here, but a couple of posts got me going in the right direction. In fact, this is a real excellent exception message in that it tells me exactly what I need to do to resolve the issue: increase the MaxStringContentLength property on the XmlDictionaryReadersQuotas object that the BasicHttpBinding class is using. 

According to MSDN the MaxStringContentLength property:

 "Gets or sets the maximum size for a message that can be received on a channel configured with this binding."

The purpose of this restriction being the possiblity of DoS attacks on a publicaly exposed service caused by arbitrarily large messages. Since I am using TransferMode.Buffered, the message size is bound by the size of the MaxReceivedMessageSize by default.

This is the end result:

I needed to update a utilities class I have been using to support XDocument (not just XmlDocuments) when I hit upon creating an extension method instead of the typical static utility class/method approach. Extension methods are a simple and powerful means of adding behavior to existing classes without breaking encapsulation. I was initially skeptical of the idea, but they have turned out to be rather nice and syntically better than static utilities classes.

The XDocument class is key part of the LINQ to XML API released with .NET Framework 3.5. Essentially it's a 'next' generation replacement for the XmlDocument class with added functionality for easily modifying in-memory Xml documents. Overall I prefer XDocument over XmlDocumentfor various reasons, but learning a new API can be a bit frustrating; it takes time to build a knowledge base of all of the 'gotchas' and 'hacks' ;)

Anyways, here is the final result:

Note that by convention I named the class after the class I was extending and added the 'Extensions' post fix. This makes things a little easier to manage. Here is the usage:

 

I was trying to test a IEqualityComparer implementation today, when Resharper kept crashing:

 

I tried rebooting, rebuilding everything. I finally clicked 'Debug' and waited...nothing happened after a few minutes, so I tried re-installing Resharper to no avail. By this time I was bruning through  my day, running out of time (deadlines, blah).

I clicked 'Debug' again and once again nothing happened....for awhile. I got up and ran a few 'errands' and came back an viola, I found my problem:

 

It was just a StackOverFlowException caused by my poor implementation of IEqualityComparer. Once I saw this I knew immediatly what was going on and how to resolve it. Of course, Resharper stopped crashing after I fixed the bug.

The big issue was why Resharper didn't handle this and just display the stacktrace as usual. It might be related to the fact that the exception was generated in TypeMock.dll, AFAIK I was not using TypeMock for this Unit test and there are no references to it in my project...weird

I was writing some unit tests for a project I am currently working and kept getting the following non-useful exception:

I have seen the error before many times in the past, but I could not put my finger on what was causing it. The code is pretty simple, it just creates and instance of an object that implements IXmlSerializable passing in a stream which internally adds additional chicled object to the stream and then loads the result into a XmlReader. The the XmlReader then outputs the results to the standard console (note that a little later I add assertations to validate that the data was 'extracted' correctly):

 

Needless to say, this code failed every time on XDocument.Load with the 'Root element missing' exception.  I vaguely remember getting this error sometime in the past, but couldn't put my finger on it. I finally ran across this blog post and a light bulb went off.

After writer.Flush() is called the position of the stream is EOF. Before you can read the stream you must set the position of the stream to the begining. Note that calling writer.BaseStream.Position = 0 does _not_ work. You must call writer.BaseStream.Seek(0, SeekOrigin.Begin) to reset the streams position before creating the reader and loading the XDocument object. Also, note that the error only occurs because the XDocument object thknks the XML stream is invalid.

ASP.NET MVC introduces the notion of partial views, which either allow specific Actions to be called on a Controller and the resulting view outputted as HTML or allow Model Data to be passed from the current view to another, child view.

Calling Actions on a Controller and returning “sub” Views is incredible useful in situations were Ajax type behavior is required, since the resulting output is simply raw HTML. The HTML can then be appended to a DOM element via JQuery, some other JavaScript library or simply with straight JavaScript.

Unfortunately if you are still working on Web Forms projects or you have no need or desire to drink the kool-aid of MVC, you are pretty much out of luck for similar functionality built into Web Forms. However, it is fairly easy to implement this sort of behavior within the context of a Web Forms environment and then use a Ajax to render pure HTML from these “partial views.”

The code for doing this is surprising simple and was adapted from a Scott Guthrie posts a few years back:

In this case I allow a Dictionary containing the name value pairs of the properties on the View that will be loaded to be passed in as well. The key must match the name of a Property on the View and if it does the Property is set with the value of the key. This is useful in cases were you would like a parent View to pass data to a child View for initialization situations, etc.

I also have a static collection of Views defined which map a View’s name to a path in my applications root directory. RenderView looks up its path and loads the control before setting the Views data. In my case I load this from a table via a Data Access Object (DAO) in the Global.asax on Application_Start:



The PageUserControlDAO loads the View definitions from the database once when the application is started or the App Pool is restarted/refreshed.

Rendering the View involves calling the RenderView method and passing in the appropriate View name and a Dictionary containing the data to into the view:

In this case I used Page_Load to render the View into a panel (div) which isn’t too exciting. The really useful aspect however is when you combine JQuery and Web Services to render the View on demand from the client.

Rendering Views from the Client Using JQuery and Web Services

The Web Service:



The JQuery code to load the view and attach it to the DOM:

In the JavaScript above, renderView takes three parameters: the name of the View to render, the data to pass to the View, and the DOM container to load the view into. The $.ajax(..) method is a JQuery method that specifies the WebService to use, the method to call (RenderView) and the content type to specify in the request header.

When the method is called like so from the client:

 

The WebService method is invoked, which renders the view and returns pure HTML that is then appended to the DOM element $view (a simple div or span).

Got the call from my father today, that our family dog was not eating, unresponsive and breathing heavy. Bad signs. I drove to his house and poor Max was looking real bad. We drove him to the vet and they showed me several lumps on his stomache and side - I gave him a bath last month and didn't notice anything out of the ordinary. She said his temperature was over 107 (102 is expected, 103 is a fever in dog world).

Anyways, Max was a wonderful loving, protector of our family (he was family) for 13 years and we will miss him. Miss you buddy.