Error during serialization or deserialization using the JSON JavaScriptSerializer

Today one of the internal web applications that we have wouldn't run properly on my development machine (it works fine on the production server). When opened it would produce the following exception:

Error during serialization or deserialization using the JSON JavaScriptSerializer. The length of the string exceeds the value set on the maxJsonLength property.

It seems that the production server has a higher maxJsonLength value in its machine.config than my development machine. To solve this problem, add the following in your web.config.

The Null coalescing operator

It seems that a lot of people do not know of the existence of this handy little operator, so I decided to put it up here, so it may help somebody clean up their code.

Have you ever had a Nullable<...> type which you needed to read to a regular value type, but needed a "default" value for when it was NULL, as the regular value type cannot handle it?
Chances are, you've written it in one of the following ways:

int? i = null; // please note that Nullable<int> is the same as int?
int a;
if(i.HasValue) // equal to: if(i != null)
  a = i.Value;
else
  a = -1;

or

int a = i.HasValue ? i.Value : -1; // This is already a bit shorter!

But using the NULL coalescing operator, you can simply write:

Entity Framework: duplicate rows in resultset from a view

After including a view I have in my database in an Entity Framework data model, I noticed that for some strange reason, the result was showing duplicates. When a set should have for instance 10 different rows, it might contain only 4 different rows, some of which were duplicated so it was still a total of 10 rows.
The view itself showed the correct results, but when called from code using the Entity Framework, it once again showed the wrong results.
After some testing I found out that the rows that were duplicated, were rows that shared certain values with the rows that were replaced by it. After checking this in my Entity Model, I soon found at that the Entity Model has a strange way of handling rows with equal primary key values.

I'll try and explain my findings:

Windows Task Scheduler error 2147942667

If you have created a task within Windows Task Scheduler, you might encounter a task that does not run properly. When you look into the history of the task, you might find the following error message:

Task Scheduler failed to start instance "<guid value>" of "<task name>" task for user "<user name>" . Additional Data: Error Value: 2147942667.

The reason for this error is the fact that you have put quotes (") around the value in Startup Path. Strangely, the executable may have quotes surrounding it (e.g. "C:\Path to\Executable.exe"), but the Startup Path may not, even when there are spaces in the Path (which makes the use of quotes for the executable necessary).

Remove any quotes you have in the Startup Path value and try again.

See also this Microsoft Support Article:
Windows Vista onwards scheduled tasks fail to run if the path in "Start in (Optional)" field has quotes

aspnet_regsql.exe doesn't work with SQL Azure

If you want to create the database structure for using Forms Authentication in your Windows Azure hosted ASP.Net application, you'll probably have noticed that running aspnet_regsql.exe on your Azure database doesn't work.
I have tried merging a local database using Red Gate SQL Compare 9 (you can of course also use the SQL Azure Migration Wizard), but that also gave me some errors regarding some elements in the resulting update statement that were not supported in SQL Azure.
I have looked into these errors and found that it was relatively easy to fix these. If you take a look at the Stored Procedure called aspnet_Membership_GetNumberOfUsersOnline in a "regular" SQL server, you'll see that it contains a couple of (NOLOCK) statements in it's SELECT statement.

Thread.Sleep(1) waits approx. 15 ms in stead of 1

Ever noticed how the time Thread.Sleep(int x) waits is not equal to x? I just noticed it happening with 2 threads with different values for the sleep, yet they were running just as quick.
After some research I discovered that the .Net runtime and Windows map this to a lower resolution in time, due to the way they handle threads. According to some sites it is 15.6 ms.
This means that any x between 1 and 15 will have your thread wait 15.6 ms (give or take, as it might be that your thread has to wait a bit more because of other calculations your CPU is processing). Any value between 16 and 31 will have your thread wait 2 x 15.6 ms (i.e. 31.2 ms) etc. The documentation also states that Thread.Sleep(int x) does not wait exactly x milliseconds, but rather "at least" x milliseconds.
For me, this is not a problem, I have just set the thread that was supposed to go slower to a different value, to make sure it actually runs slower. But just out of curiosity I have done some more research into how to solve it if you really want to have your thread sleep for a more precise period of time.
It seems the MultiMedia API's can help with that. I have tested the following code and it allowed me to set the sleep to a millisecond precisely.

ThreadAbortException on Response.Redirect(), Response.End() and Response.Transfer()

If you have ever used a call to Response.Redirect("url"), Response.End() or Server.Transfer() within a try block, you will probably have noticed that these calls always throw a ThreadAbortException.
This is normal behaviour, but can mess up your program if the corresponding catch is executed unexpectedly.
To avoid this, catch the ThreadAbortException in a separate catch, or write a try/catch around the call.
For instance, if you have:

try

{

    Do something here;

    

    Response.Redirect("some url");




    Do some more work;

}

catch(Exception ex)
{
    Do something useful with the excepion here;
}

You can rewrite it like so: