ross dickinson: web and desktop software developer

If you're trying to run a script using Internet Explorer's ActiveX interface(such as the WebBrowser control in .NET, or using WatiN), you might stumble on this error when trying to run arbitrary scripts through the interface. Either ActiveX or Internet Explorer itself does not like scripts with carriage returns for some reason. It might not solve your problem but worth checking out.

Submitting a Nested Form in ASP MVC3

by Ross on February 3, 2012 at 7:06 PM under .NET | ASP.Net | MVC

In case you're using the jQuery unobtrusive ajax library with your ASP MVC3 site, you'll probably find that it can be difficult to submit a nested form in certain situations. The problem comes from this bit of code:

$("form[data-ajax=true]").live("submit", function (evt) {
    var clickInfo = $(this).data(data_click) || [];
    evt.preventDefault();
    if (!validate(this)) {
        return;
    }
    asyncRequest(this, {
        url: this.action,
        type: this.method || "GET",
        data: clickInfo.concat($(this).serializeArray())
    });
});

When your nested form's submit event gets raised, it bubbles up to the parent form as well. You can fix this in two ways. The easiest way is to modify the code above to look like this:

$("form[data-ajax=true]").live("submit", function (evt) {
    if (evt.currentTarget != evt.target) { return; }
    var clickInfo = $(this).data(data_click) || [];
    evt.preventDefault();
    if (!validate(this)) {
        return;
    }
    asyncRequest(this, {
        url: this.action,
        type: this.method || "GET",
        data: clickInfo.concat($(this).serializeArray())
    });
});

This stops the unobtrusive ajax library's handler from submitting the wrong form.

Another way is to add your own submit handler to your nested form that calls evt.stopPropagation(). This tells the event to stop bubbling up and calling other event handlers. This can be tricky, though, because you have to ensure that your handler is called before the unobtrusive handler.

What's ASP.Net's Request Validation Doing?

by Ross on January 12, 2012 at 4:16 PM under .NET | ASP.Net

I'm sure you've seen this before:

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

Ugh! Annoying. So what's dangerous about the request? Could be anything, but let's break down what ASP does in the background when it actually validates the request.

1. Checks postback keys

This is almost inconsequential, but something worth pointing out. The HttpRequest class has a private method called ValidateNameValueCollection that determines whether or not a postback value should be be validated.  Oddly enough, this has nothing to do with checking whether the developer's supplied a way to bypass validation(like by using the ValidateInputAttribute in MVC). All this method does is make sure that that all of the keys are validated, unless the key begins with "__". I'm assuming this is here so fields like "__VIEWSTATE" don't break the validation.

2. Validate input

After the key's been checked, if the matching value isn't null, it's then passed to a series of a functions that check that the value

  1. Doesn't contain any text with an < followed immediately by any letter, !, ?, or / symbol. 
  2. Doesn't contain the text "&#"

That's it.

That's all it does.

I actually think catch-all validation like this is fairly useless for anyone with a little experience in web development, because trying to throw an exception when html tags are sent to the server isn't necessarily going to prevent them from being rendered back out to the client. The values should be sanitized before being sent back to the client, instead.

Operation could destabilize the runtime

by Ross on December 2, 2011 at 3:54 PM under .NET

If you've been using linq to sql then you may have come across this baffling error before:

[VerificationException: Operation could destabilize the runtime.]
Read_SomeEntityClass(ObjectMaterializer`1 )
System.Data.Linq.SqlClient.ObjectReader`2.MoveNext()
System.Linq.Buffer`1..ctor(IEnumerable`1 source)
System.Linq.Enumerable.ToArray(IEnumerable`1 source)

It would be a little nicer if the error message explained what operation could destablize the runtime and why, but alas, it does not.

So, what's causing the problem?

At least in some instances, this error will pop up because your entity class has a readonly field being used for storage. When linq to sql attempts to set a value on that field, it can't, so that error is thrown. If you want to be technical about it, you can set a readonly field's value through reflection, but it's bad practice. It's a good thing linq to sql doesn't do that, but the error it throws could be far more helpful.

ASP.Net 4 ClientIDMode and Validators

by Ross on March 24, 2011 at 1:51 PM under .NET | ASP.Net

Just a quick note. ASP validators(like RequiredFieldValidator) do not work when validator's ClientIDMode is set to a value other than AutoID. This happens either by explicitly setting a value, or the validator inheriting it from a parent control. The only work around, so far, is to make sure your validator has AutoID set.

VirtualPathProvider and ScriptManager conflict.

by Ross on January 25, 2011 at 8:05 PM under .NET | ASP.Net | Programming

I spent this afternoon working on a custom VirtualPathProvider for two websites we have at work. We need to share resources(master pages, themes, scripts, etc) between the two and I figured embedding resources in a separate project would be the best bet. The VirtualPathProvider implementation takes any old path its given(like "/resources/style.css") and looks to see if there's an embedded resource that matches. This worked out great after I got around some annoying implementation details(MSDN documentation on VirtualPathProvider is kind of terrible).

Then I got stumped. On some pages everything would work as expected. The page would include all the referenced embedded resources and load without a hitch. On other pages, though, the same reference would result in an "Directory not found" HttpException for no apparent reason. After tearing my hair out trying to find something wrong with my VirtualPathProvider, I went to look at the full stacktrace of what was wrong. I probably should have done that in the first place seeing as my problem wasn't specifically being thrown by my VirtualPathProvider class.

[HttpException (0x80070003): Directory 'C:\Solutions\Website\Resources\Dir' does not exist. Failed to start monitoring file changes.]
System.Web.FileChangesMonitor.FindDirectoryMonitor(String dir, Boolean addIfNotFound, Boolean throwOnError)
System.Web.FileChangesMonitor.StartMonitoringPath(String alias, FileChangeEventHandler callback, FileAttributesData& fad)
System.Web.Caching.CacheDependency.Init(Boolean isPublic, String[] filenamesArg, String[] cachekeysArg, CacheDependency dependency, DateTime utcStart)
System.Web.Caching.CacheDependency..ctor(String[] filenames)
System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods, Boolean inlineScript)
System.Web.Script.Services.PageClientProxyGenerator.GetClientProxyScript(HttpContext context, IPage page, Boolean debug)
System.Web.UI.ScriptManager.RegisterServices()
System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e)
System.Web.UI.Page.OnPreRenderComplete(EventArgs e)
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

What's ScriptManager doing? Beats me, but I looked into it and came across this: HttpException when serving a page with a ScriptManager using a Virtual Path Provider

It turns out that, prior to ASP 4.0, the ScriptManager control has a bug that causes it to ignore any custom VirtualPathProvider classes whenever it does whatever it does internally. This only happens when the ScriptManager's EnablePageModes property is set to true. Setting this to false immediately fixed my problem. That may not solve everyone's problem, though. There's a hotfix available for this specific issue, though I can't vouch for it.

 

Always Use Caution When Using MemberwiseClone

by Ross on December 8, 2010 at 1:04 PM under .NET

I guess it goes without saying, though some people may not realize just how careful they need to be if they're using the MemberwiseClone protected method on .Net objects.

Always remember that MemberwiseClone will copy *everything* from one object in to another. There's not much to worry about with value types, because those get copied into new values no matter what. Reference types, though, have their references copied. You might think, "Hey, great, I don't have to copy over my various reference type properties". What you always need to keep in mind, though, is this copies private fields and other references you may not have in your control.

This bit me when I was using MemberwiseClone on a very basic object I'd made that implemented INotifyPropertyChanged. No problem there right? Wrong! If I had any attached event listeners to the object's PropertyChanged event, those listeners got attached to the new copy as well. If I attempted to remove the handler from the original object, it would not be removed from the copy(and vice versa).

End point: You should probably avoid MemberwiseClone if at all possible and either manually set the properties that are needed, or come up with a better way to automate the cloning process.

About the author

rossisdead is a 26 year old web and desktop software developer from New Jersey. He has two cats and likes long walks on the beach.

On Stackoverflow

On Stackoverflow Careers

On Codeplex

On Github