Slight delay posting this, had a little trouble with the wireless in my Amsterdam hotel, and have been flying for a day to get back home!

I have resource sites related to the topic of this session, they are listed here in my post from Tech Ed San Deigo.

Thanks so much for the great feedback I received so far on this talk. I will be posting an update to my sample code in a few days, as soon as I get caught up on some seriously pressing deadlines. Right now, the code sample has everything I demonstrated with the exception of the HTTP handler that forces "Save As" download for configured resources such as XML files.

If you have other ideas for modules, handlers and SOAP extensions you are completely welcome to ask me, I may have some code lying around that I haven't cleaned up and posted yet!

Cheers!

Thank you for attending this chalk talk yesterday! Feel free to send me any further questions beyond what we had time to cover in the session :)

I will clean up and post my slides here shortly. Also in a previous blog entry I provided the link to my MSDN article that discusses some of the architectural benefits of Enterprise Services for building scalable ASP.NET applications. This blog entry also provide an updated code sample with more detailed installation instructions.

Thank you for attending my session last evening. As I mentioned, I gave this talk previously at Tech Ed San Diego, but since then I have actually added some more code samples and discussion points that I unfortunately didn't have time to explore during the session.

My globalization resource page can be found here:
http://www.dotnetdashboard.net/sessions/globalization.aspx

Look for a new sample with a script for versioning and deployment shortly. I'll update this blog entry when it is finally there. Thanks for coming to the session!

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.