Easily Work With Differing Time Zones In An ASP.NET 3.5 Application

When working with ASP.NET applications, time zones are often a problem when dealing with
DateTime structures. There are two different common scenarios that a developer is likely
to encounter. The first is that you are placing the application on a hosted server
that is in a different time zone than the business you are trying to operate. The second
is that you have users from different time zones and would like to display the date and time
to the user in their local time zone rather than the server’s time zone.

Hosted Time Zone addresses this problem by providing two settings. ApplicationTimeZone sets
the time zone to be used by the entire application. ThreadTimeZone sets the time zone to be
used by the currently running thread, which defaults to the ApplicationTimeZone if no time
zone has been specified on the thread. If you are using ThreadTimeZone then you need to be
sure to set the value for each request made to the server. You will usually do this in your
global.asax file, such as in the Application_BeginRequest handler.

To actually perform the conversions you can call the ToAppTime, FromAppTime, ToThreadTime, or
FromThreadTime static methods on the ApplicationTimeZone class. Additionally, extension methods
have been declared for the DateTime and DateTimeOffset classes that perform the same functions
more cleanly. In order for the extension methods to work you must import the HostedTimeZone
namespace.

You should note that there are not any overloads for FromAppTime or FromThreadTime for the
DateTimeOffset class. This is because the ToLocalTime method of DateTimeOffset performs the
same function, so they would be redundant.

This library requires the TimeZoneInfo class, which is not available until the .NET Framework 3.5.
Therefore, it is not compatible with ASP.NET 2.0 or earlier.

Hosted Time Zone 1.0.0.0

Using URL Rewriting With Web Parts

Web parts are a great new system for allowing personalization of web sites by end users that
was introduced in ASP.NET 2.0. However, it isn’t useful when used in combination with
URL rewriting.

URL rewriting allows you to respond to requests from dynamic URLs by redirecting the handling
to a different .ASPX file on your server. This can be used to make your URLs more readable
and improve your search engine optimization (SEO), instead of using long query parameters.
Some example systems for implementing this are UrlRewriter.net and UrlRewriting.net.

When you use web parts in combination with a rewritten URL, the web parts will all be shared by
all of the URLs that are rewritten to the same .ASPX file. This library corrects this
by replacing the WebPartManager with RewritableWebPartManager and the SqlPersonalizationProvider
with RewritableSqlPersonalizationProvider.

It also provides additional functionality in the form a personalization levels. This allows you
to share common personalization settings amonst multiple URLs. When a user is browsing, if no
personalization is specified at a particular level, the personalization defined at a higher level
is displayed instead. For example, in a web store scenario you can allow the store operators to
provide shared personalization that all users will see. Using levels, they can set personalization
that will appear on all item pages, such as a disclaimer, and then override that personalization
with a different disclaimer on a specific item’s page.

More information can be found in the readme file included in the download.

Rewritable Web Parts Library 1.0.0.0

Forcing 32-bit Execution in .NET

Sometimes when developing .NET applications it becomes necessary to force an application to run in 32-bit mode, even on a 64-bit processor. One scenario that I’ve run into is when you’re using Crystal Reports embedded in the application. I’m not sure about newer versions, but for Crystal Reports XI R2 it won’t work in 64-bit mode.

In order to get something like that to work, you must force 32-bit execution on the executable. Forcing it on a DLL assembly in your application won’t help, then it won’t be able to load that DLL either. It needs to start in 32-bit mode from the beginning. If you can make the change in the development environment before compilation, just set the flags on the assembly there and everything will be great.

However, if you need to make the change to a compiled assembly it’s a little more difficult. To do so, use the corflags command-line utility. This program is included in the Windows SDK. To do so, simply run “corflags program.exe /32BIT+”.

If the assembly is strongly-named, then you must do a little more. First, you must add a /force flag, running “corflags program.exe /32BIT+ /Force”. Then, you must rehash and resign the assembly, using “sn -Ra program.exe key.snk”. In this case, key.snk is your key file for signing the assembly.

Hope this helps!