>
 Friday, July 02, 2004

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.

7/2/2004 7:30 AM Architecture | ASP.NET | Speaking/Events  | Comments [9]  |  View reactions  |  Trackback
 Thursday, July 01, 2004

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!

7/1/2004 8:45 AM .NET | Globalization | Speaking/Events | TechEd  | Comments [71]  |  View reactions  |  Trackback
 Thursday, June 24, 2004

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...

6/24/2004 12:37 AM Speaking/Events  | Comments [1]  |  View reactions  |  Trackback

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...

6/24/2004 12:25 AM .NET | Globalization  | Comments [2]  |  View reactions  |  Trackback
 Tuesday, June 22, 2004

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.

6/22/2004 3:30 PM .NET | Security | Speaking/Events  | Comments [5]  |  View reactions  |  Trackback
 Monday, June 21, 2004

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.

6/21/2004 11:18 AM ASP.NET | Security  | Comments [42]  |  View reactions  |  Trackback
 Friday, June 18, 2004

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.

6/18/2004 6:45 PM .NET | What The?  | Comments [2]  |  View reactions  |  Trackback

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!

6/18/2004 5:06 PM .NET | What The?  | Comments [3]  |  View reactions  |  Trackback

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?>

6/18/2004 3:30 AM .NET | What The?  | Comments [9]  |  View reactions  |  Trackback
 Thursday, June 17, 2004

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 :)

Cheers.

6/17/2004 4:51 PM Architecture | Indigo | Web Services  | Comments [16]  |  View reactions  |  Trackback
 Wednesday, June 16, 2004

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

6/16/2004 9:41 AM Architecture | ASP.NET  | Comments [20]  |  View reactions  |  Trackback
A few months ago, CoDe Magazine published an article I wrote on WSE 2.0. The code sample for this article has now been updated here to reflect the release of WSE 2.0. Enjoy.
6/16/2004 8:02 AM Web Services | WSE  | Comments [3]  |  View reactions  |  Trackback
    ON THIS PAGE
    SEARCH
    CATEGORIES
    ARCHIVES
    BLOGROLL

Designed by NUKEATION STUDIOS