Just signed up for 70-515

Just signed up for my next Microsoft exam on Friday: TS: Web Apps Development with MS .NET Framework 4. I’m actually excited about this one–it leverages a lot of what I use in my every day work flow, so it shouldn’t be as much of a challenge as my last exam. If I don’t post about how it went, it’s most likely because I failed it and feel ashamed. Here’s to hoping I post!

A potentially dangerous Request.Form value in Castle MonoRail or MVC 2 & ASP.NET 4.0

I’m working on a project with Castle MonoRail, and got stuck on a problem for several hours. After a lot of useless reflecting and forum trolling, I eventually narrowed it down to a breaking change in ASP.NET 4.0.

Short answer: ASP.NET 4.0 validates every request by default, which means it can ignore your overriding @Page directive validateRequest=”false” or controller [ValidateInput(false)] attributes. Go back to the 2.0 behavior by adding this to your web.config’s system.web configuration section:

<httpRuntime requestValidationMode=”2.0″ />

I was getting the following exception when submitting a textarea in which the user could enter HTML:

MonoRailException: Error building method arguments.

With the following inner exception:

HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client.

Usually I can get around this by following one of several methods:

1. <%@ Page ValidateRequest=”false” %> in .aspx-file.
2. <pages validateRequest=”false” /> in web.config.
3. [ValidateInput(false)] on controller’s action (ASP.NET MVC 2).
4. [SkipFilter(typeof(RequestValidatorFilter))] on controller’s action (Castle MonoRail)

But none of this stopped the exception.

Finally I narrowed it down to a breaking change in ASP.NET 4.0, found here: http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes#0.1__Toc245724857

The solution? Go back to the 2.0 behavior by adding this to your web.config’s system.web configuration section:

<httpRuntime requestValidationMode=”2.0″ />

After you do this, you can use any of the existing options for overriding the default .NET behavior for validating requests.

BEWARE! Only do this if you’re aware of the consequences. You could be making your site vulnerable by following these instructions!

LINQ to XML Jump Start

Here’s a jump start on the primary LINQ to XML tasks:

1. Getting an XDocument:

XDocument document = XDocument.Load(“uri to your xml document);

or

XDocument document = XDocument.Parse(“a string containing XML; read from a database or downloaded from a server, perhaps?”);

2. Finding element(s):

IEnumerable<XElement> elements = document.Descendants(“node name, like channel or items”);

or

XElement element = document.Element(“some sub element, like title or description”);

or, if you have namespaces (elements with a “:” in the name):

XNamespace geo = “http://www.w3.org/2003/01/geo/wgs84_pos#”;

XElement element = document.Element(geo + “lat”);

3. Getting values out of elements:

string value = element.Value;

or

string attributeValue = element.Attribute(“some attribute, like width”).Value;

Streaming huge results from ASMX

Turns out streaming lots of data from an ASMX web service isn’t too hard. I have to update upwards of 46,000 products from one web site to another over an ASMX service. Initially, I was getting a lot of exceptions:

The request channel timed out while waiting for a reply after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.

But that’s easy to fix. In my web.config, I boosted the timeouts from 00:01:00 to 00:10:00. This led to my next exception:

The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

I tried to fix this by increasing the maxReceivedMessageSize to 2147483647 (the max size of a signed integer–Int32). But I was still getting weird exceptions, so I knew I hadn’t actually fixed it. The exceptions weren’t showing up until I made my next web service call:

The communication object, System.ServiceModel.ChannelFactory`1[Custom.BLL.Rms.ItemManagement.ItemManagementSoap], cannot be used for communication because it is in the Faulted state.

Turns out this has an easy fix. The problem was that, by default, my binding was using a transfer mode of “Buffered”. This limits the maxReceiveMessageSize. I changed the transferMode to “Streamed”, and boosted the maxReceiveMessageSize to 9223372036854775807 (Int64′s max size).

After updating that, I was able to blissfully make my massive call.

Literal content is not allowed within a ‘skin file’

We use skin files in our CMS. When I was building today, I hit a compile error that looked like this:

Error 5 Literal content (‘<asp:LinkButton SkinID=”CheckoutWithPaypalButton” CssClass=”buttons”  />’) is not allowed within a ‘skin file’. C:\_code\Web\App_Themes\KLT\Buttons.skin 16

Turns out our problem was simple: It was missing the runat=”server” attribute. I added the attribute, and that took care of the build problem. Swoosh.