I hit the road again tomorrow, heading to Tech Ed EMEA (Amsterdam) to present a few talks on globalization architecture for .NET, advanced ASP.NET pipeline extensions (modules, handlers, SOAP extensions), a cool .NET myths panel with David, Juval, Clemens, and Rafal, and the Women in Technology panel with my buddy Kim again (plus a few other respected women who I look forward to meeting).

I'll post updates to my talks when I return...but for the next few weeks I'll be busy keeping up with my other deadlines between sessions and on plane rides...lots to do...

Some of you may know I have a minor in internationalization, meaning, although it is not my primary focus, I spend a good amount of time exploring answers to challenges my clients and readers face. Well, a new blogger focused 100% on this topic has gone live. Meet Achim Ruopp from Microsoft...

While Kimberly Tripp enjoys a pleasant day on the beaches of Croatia, most of us have to work. I, for one, am presenting at the Security Summit San Fransisco today, and in honor of that event I have posted some new samples to my resource site.  

See my original post for the link.

When I presented the Security Summit in Anaheim earlier this month, one of the attendees asked me how to override the 50 year authentication ticket. That's right, FormsAuthenticationTicket.Expiration is set to DateTime.Now.AddYears(50) by default. This propagates to the HttpCookie returned with the response as well.

Well, I don't know about you but I'm highly doubting that I'd need a ticket to last me 50 years, so here is the code to workaround this (rather lame) default setting.

Dim redirectUrl As String = FormsAuthentication.GetRedirectUrl(userName, False)
Dim authCookie As HttpCookie = FormsAuthentication.GetAuthCookie(userName, True)
authCookie.Expires = DateTime.Now.AddMinutes(20)
Response.Cookies.Add(authCookie)
Response.Redirect(redirectUrl)

I'd probably go ahead and externally configure the 20 minute timeout interval as well. Oh, and I believe this also resolves the incompatibility issue with other browsers that don't quite know what to make of the 50 year token.

In the code sample that started these recent blog posts, I was using GetHashCode() to display a unique value for a thread in a simple example, for visually unique identifier for a thread, without bothering to set the Thread.Name property. For this simple type of example, GetHashCode() has always done the trick (and I've always referred to this as the logical thread ID) because I didn't care if I was displaying the physical (Win32) thread ID, accessible via AppDomain.GetCurrentThreadId(). In an application that requires maintenance of a list of running threads, I usually set the Name of each thread (better for debugging as well) and hold on to each Thread reference:

ThreadStart del = new ThreadStart(Start);
Thread t = new Thread(del);
m_newThreads.Add(t); // ArrayList scoped globally
t.Name="Thread #" + m_newThreads.Count;
t.Start();

To display thread information:

this.listBox1.Items.Clear();
foreach (object o in m_newThreads)
{
 Thread t = (Thread)o;
 this.listBox1.Items.Add(t.Name + ": " + t.GetHashCode());
}

Notice that from each thread reference t I cannot access the physical thread ID since such a property doesn't exist on the Thread type. If I required this information I could always create a thread wrapper class that returns this information using AppDomain.GetCurrentThreadId().

This sample demonstrates this and a few other things related to the subject of process and thread identities. For example, you'll note that the process identifier accessed through Process.GetCurrentProcess().Id always returns the same process ID, whereas Process.GetCurrentProcess().GetHashCode() returns a different value for each thread. This is not because they are running in a different process but because the underlying code for GetCurrentProcess actually creates a new Process object reference based on the actual physical process:

return new Process(".", false, NativeMethods.GetCurrentProcessId(), null);

Of course, consistent with the purpose of GetHashCode() discussed in Lazy Blogger's references, this generates (you guessed it) a new hash code for the object reference.

Ok, per my last post, James points out the following hilarious truth, that there is actually a setting in Visual Studio to prevent people from getting scared of methods and properties they don't understand:

Now I am really laughing my head off! I had no idea this option existed, thanks James!

And so I add a new category to my blog...titled: what the? Because sometimes, you just have to ask the question...WHY?

<what the?>
One of the main draws of the .NET Framework is that regardless of language preference, we can all share a common object model to access core features. So why did I just waste 5 minutes hunting down how to get the thread ID using VB.NET? Because instead of using GetHashCode() which I'm accustomed to in C#, I have to use the oh-so-convenient AppDomain object's GetCurrentThreadId() method. I mean seriously, it is not even available from the Thread object?

Granted, Thread.ThreadID might have been a nice property, to replace GetHashCode(), but what's good for the goose...oh, I get it...this:
AppDomain.GetCurrentThreadId()

Is much easier to understand than:
Thread.CurrentThread.GetHashCode()

That is, if you can find it...
</what the?>

In many presentations of late I have mentioned to folks the preference of Enterprise Services over .NET Remoting. In part to reduce the risk associated with rolling your own security model across boundaries (among other things), and due to the fact that the Indigo team at Microsoft recommends Enterprise Services as the way to build your component architecture today, to better migrate to Indigo tomorrow.

Here are some references I found on the subject on Rich Turner's blog (he's a PM) and a video on the MSFT site. If I find more, I'll add to comments. If you have your own proof, or have questions/concerns on this subject, YOU add to comments :)

• http://blogs.msdn.com/richturner666/archive/2004/03/05/84834.aspx
• http://blogs.msdn.com/richturner666/archive/2004/03/05/84771.aspx
• Indigo Migration Webcast

Cheers.

I wrote this article describing how to leverage Enterprise Services for a scalable Web application:
http://msdn.microsoft.com/asp.net/community/authors/mlb/default.aspx?pull=/library/en-us/dnaspp/html/aspnetscal.asp

In the article post on MSDN, the SQL script is missing from the installation so, I reviewed the sample tonight, and decided to write up some instructions to help you run the code as well. Download this here:
ASPNETScalability.zip

Ok, so there isn't much here yet, but after that really long stretch of no sleep preparing for the interoperability event I pulled together last month finally the blog site www.interopwarriors.com is now live. Now we have a home for our random thoughts on the things we learned, and things we'll do before the next event. You can expect code, but not really soon, how about in July? After another long rush of deadlines is over?

Thank you to everyone who attended the Security Summit in Anaheim this past Tuesday.

I promised you some links to resource sites, and here is my page devoted to the event:

http://www.dotnetdashboard.com/sessions/securitysummit.aspx

Here you will find links to the official Microsoft site for the event and the resources provided by Microsoft. I pulled some of the Microsoft links for topics mentioned throughout the day and put them on this site so you can find them more easily.
In addition, I have supplied a number of my own resource sites that will lead you to code samples I presented, in addition to more advanced samples.

If you have any questions, let me know!

A the Security Summit this week, several people asked me about the .mspx extension Microsoft uses for some of its resources. You can create a custom HTTP handler to process requests for custom extensions. That means you first have to register IIS to pass request for that extension to ASP.NET. This article mentions how to do this. Then, you create a custom handler to process the request, by registering an HTTP handler or handler factory (see more resources on handlers and factories) to do the work. The handler factory's job is to return the right HTTP handler for the request, so ultimately, you are building a handler. The handler might even generate HTML on the fly.

In the case of .mspx extensions, Microsoft uses this extension to generate XML-driven HTML content. This article talks more about the architecture.

http://www.microsoft.com/backstage/bkst_column_46.mspx