ASP.NET – Converting C# String to JSON String

Most web applications display messages to users. Displaying messages is the most effective way to inform user about errors and warnings or to simply display info or success status.

I also believe that most of those web applications renders user messages using HTML elements such as Div, Span or Label.

The others, mainly because their complex layout or business rules, have to render those messages using a different approach: they render each display message as a Javascript function call where the message itself is a function parameter.  Such call could be simply like this:

string.Format("top.addMessage("{0}");", message)

Those of you that already faced this problem won’t learn nothing new but I hope to alert the others and avoid them to face a problem that usually is only detected in advanced develop stage or even production environment.


The problem turns visible when the display message contains some special characters that prevent the function call to execute and trigger javascript errors.

Typically the characters are “ and ‘ but there are more.

Well, that is not completely correct, only the character “ is problematic, since he is the JSON string delimiter character, but, javascript engines also accept the character ‘ as a delimiter. The best way to avoid problems with ‘ is to ensure that the correct delimiter is used.

By now, you should be thinking that your applications are immune to this problem. Tell me, do you use string Resources? Most of us use, it’s a best practice and a smart choice. Also tell me, do you manage production string Resources? Most of us don’t. In fact, the application owner or sponsor can change it completely outside of your control scope.

String Resources are one of the major vectors of this problem but you can get this problem simply by trying to display an exception message:

string.Format("top.addMessage("{0}");", exception.ToString())


What we are needing is an JScript.Encode method or similar that encode a C# string in such a way that it becomes a JSON encoded string.

Such method is not available on NetFX but, fortunately, Rick Strahl made a great post about this problem and made available a method that fits perfectly our needs.

Now that you know about it … use it.

ASP.NET Controls – Validators problem (NetFx 1.1 versus NetFx 2.0 or higher)

It is not a secret that I have a passion related to ASP.NET Controls ID and all related subjects.

This time I’ll write about a problem I found while migrating a NetFx 1.1 application to a new server.

The problem is about Validators and how they render the data needed to validate Client-Side.

Scenario NetFX 1.1.4

All data is rendered thru attributes and this way they must only follow the attributes naming conventions.

Scenario NetFX 2.0 or higher

Most required data is rendered thru Expando attributes. This means that an javascript object is created to host the required data.

At first look this seems quite the same, only with a different storage  approach, but it hides one tricky issue related to naming convention differences between Html attributes and Javascript variables.

The tricky issue

I believe that most of us tries to follow the best patterns and naming conventions and if we all did this on old applications this wouldn’t be a problem.

While migrating an old .Text v0.91 application to a new server, without NetFX 1.1 installed, I found that all pages with Validators raise a javascript error.

Digging into it I found the error in this line:

var ctl00_pageBody-2_RequiredFieldValidator1 = document.all ? document.all["ctl00_pageBody-2_RequiredFieldValidator1"] : document.getElementById("ctl00_pageBody-2_RequiredFieldValidator1");

The problem is obvious, the character ‘-‘ is a javascript operator and cannot be used in a variable name . The javascript parser after finding the ‘-‘ say that an ‘;’ is expected after ‘ctl00_pageBody’.

So … Why this didn’t occurred in the old server? What lead us to this point?

As I noticed before, in NetFX 1.1 this object didn’t exist, all data were simple rendered as attributes.

I didn’t find any good reason for naming a control like this but in fact this is a absolutely valid control ID.


There are two approaches, we can either force the validator to render attributes or change the ID value to remove unwanted characters.

The first is obviously the better one but as you will see is a global application change.

Instruct the validator to render attributes

The validator controls are ready to work in a legacy mode, but to enable that mode we need to change the all behavior of our application. We can do that adding the following web.config data:

    <xhtmlConformance mode="Legacy"/>

While this solution is the one I like the most I choose to use the other simply because I don’t know exactly the potential side-effects, and I need to made a chirurgical change minimizing impacts.

Change the controls ID

This approach requires you to change all controls ID in the validators hierarchy to prevent javascript naming problems. It could take some time but, usually, it should present no problems.

That is not my case. It took me some time to find where the pageBody-2 control.

I ended up finding that it was an UserControl, loaded dynamically and its ID was also composed dynamically. Unfortunately, this was all done in a private method belonging to an internal base class and the only practical solution was to override the Page Render method and replace the pattern ‘_pageBody-‘ with ‘_pageBody_’.

I know it is a dirty solution … I don’t like it … but this is a short term solution before migrating the application to CommunityServer.

Mental note

Never use the ‘-‘ to name your controls ID property. Try the ‘_’ or any other without special meaning in Javascript.