Forms authentication failed for the request. Reason: The ticket supplied was invalid.

When was the last time you saw this message ??? (just kidding)

If you drill down to the EventViewer logs you"ll probably see this code

Event code: 4005 Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.

Now most people think that this is due to the machine keys in the machine.config file but actually this is due the expiration of a valid ticket which was for a short duration.

After the expiration, the users would need to again sign-on and this makes the user experience even worse. To fix this issue, you need to increase the validity of the ticket by using the sample below

FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(1, "usercookie", DateTime.Now, DateTime.Now.AddMinutes(120), false);

Difference between Thread and ThreadStart delegate

I have been working since .Net 1.1, the way we create/spawn threads is

1. Create a ThreadStart delegate for parameter less target method or Create a ParameterizedThreadStart delegate for target accepting parameters. 2. The next step was to create a Thread object and pass this delegate. 3. Lastly call the Start method to execute the thread.

This was the norm till .Net 2.0. What seems confusing now is that, from ver. 2.0 we can directly pass the target to the Thread's constructor and call the Start method !!!

Well this is due to the enhancement which .Net 2.0 onwards have to offer. Instead of going the way we did above in 1.1, the compiler now invokes the appropriate delegate based on the target passed.

So technically speaking both the approaches below are the same.

1. ThreadStart ts = new ThreadStart(Somework); // .Net 1.1 way of creating threads Thread t = new Thread(ts); t.Start();

2. Thread t = new Thread(Somework); // .Net 2.0 onwards way of creating threads t.Start();

Happy coding :)

How to access files, folders and other local resources through .net

Applications these days may require to access local resources such as folders on disk, creating/deleting files, etc. I came across one such scenario wherein the application had to create a file on remote location and then periodically delete the file(2 days after file creation).

In this scenario, assume without the application in picture, an user creates a file. This seems pretty much simple though, but what I want to tell here is the sequence of events.

1. An user navigates to the location ( a folder on remote machine)
2. Create a file
3. Save the file.

These 3 events though straightforward, make an important assumption, and that is, the user is having access to create file.

When it comes to your .Net application, the application is running under the user of a lesser privilege (that's CAS for you) or Code Access Security. So most of the times it won't have the privilege to create a file.

To fix this either you have to grant the application account with the required privilege OR you can MAKE the application run on the privilege of a specific user.

So under which username does the .Net app really work ??-- Its Network Service for remote apps and ASPNET on local machines.

As discussed you can grant these users, depending on the scenario, access to the required folders and you're done. But theres a trap... All the .Net apps will now have access to this folder since all of them run by Network Service/ASPNET accounts.

It may happen that you have to restrict the access to such folders, then, you have only one option...execute the application under the context of a specific user who has access to only that location. To get this done, you need to explore WindowsImpersonation class. Below is the link with code sample

WindowsImpersonation class

With this class you can provide the username/password of the specific user account you want the application to execute and then reset the identity so that the rest of the application code works under the restricted .Net account.

Happy Coding :)

How to Format Date in CustomCalendarExtender control

The default date format for the CustomCalendarExtender is MM/dd/yyyy which is typically US date format. To change this format, you need to set the Format property of the control.

For UK based date format you can set this to dd/MM/yyyy which would display date as 19/03/2011 instead of 03/19/2011 (default format)


Happy Coding :)

Implementing Transactions in WCF

In synchronous communication (request-response-acknowledge) we generally refer to the response HTTP code to determine a successful transaction. But in some cases it might happen that an acknowledgement be sent to the server which will store this value in the database.

A typical scenario would be of file download process wherein the client needs to send the acknowledgement which stored in database for future use. For this you need to implement Transaction in WCF. To do this, you can use the TransactionScope class or you can use the OperationBehaviour attribute in WCF as below

[OperationBehavior(TransactionScopeRequired = true)]

This would require your web-method to execute as a part of transaction. Having done that, you can now return a Boolean value (True/False) as a result depending on the status of the download process. This value can then be stored in the database in Boolean/Bit format for future reference.

Happy Coding :)

Configuring your web application for Windows domain users

To provide authentication mechanism on Intranet websites is pretty easy. Use LDAP and all the users accessing your application on the Intranet get authenticated automatically. But how to achieve this in the internet scenario ??

It might happen that your application needs to be SCALABLE to allow your Windows domain users to access the website from internet. To achieve this, you just need to tweak the webconfig a bit with the entries shown below

Happy Coding :)

Solution for System.IO.IOException: The device is not ready. error

Many times our applications refer a file on disk. At the time of development, most of the developers refer to the file by it's absolute path.

The trap here is, the absolute path on the development environment most of the times differ from the path on the deployment server. So though you're able to build and ship the DLLs you will always encounter a runtime error. Thats simply because the AppDomain is not able to locate the file from the path you mentioned. Moreover, the path does not exist in itself :P

So to get rid of this scenario always use Server.MapPath which would resolve the file path on the server. Also refer the url below for code snippets.
Server.MapPath example

Happy Coding :)