For today's webcast, my resource page is:

http://www.dotnetdashboard.net/sessions/globalization.aspx

I have new samples to post here, and shortly a whitepaper on ASP.NET 2.0 localization features, so keep an eye on this link for changes in the next few weeks!

Thought I'd christen my newly repaired blog (crossing fingers) with a new post about Service Pack 1 for the .NET Framework 1.1 - which has been available for over a month now (yes, I have been busy):

SP1 - http://www.microsoft.com/downloads/details.aspx?familyid=A8F5654F-088E-40B2-BBDB-A83353618B38&displaylang=en

Yesterday I finally had a chance to update my machines and take a closer look. Ironically, on the same day I had a fantastic conversation with Vivek Nirkhe from the VS 2005 Team System group ( http://lab.msdn.microsoft.com/vs2005/teamsystem/ ) on the issues of versioning; updating assembly version versus file version; and best practices for build process to handle distribution during development, the pass to QA and final release. He was kind enough to provide feedback on some of my concerns about SP1.

Much to my surprise, SP1 doesn't version the updated .NET Framework assemblies, which happen to contain a long list of fixes. My immediate thought was:

Why aren't they versioning their assemblies and shipping a publisher policy?

A publisher policy makes it possible for you to deploy updated assemblies to the GAC, and all installed applications will automatically bind to those updated assemblies. UNLESS, they override policy in their own app.config file. Therein lies the problem, according to the following blog post by Junfeng Zhang on the subject: 

http://blogs.msdn.com/junfeng/archive/2004/10/11/240822.aspx

In summary he states:

1. The service pack is security related, and we don't want customers to opt-out by publisher policy override
2. The main reason for the concern in #1 is because through publisher policy override you must specify which assembly to override. Since SP1 includes multiple files, it is possible that applications will forget to include ALL of the assemblies in the override, and thus create a situation where some assemblies are 1.1, others SP1.

Ok, so this is a good call, because we all know this would happen and create a support nightmare. But, this exposes an inherent limitation to assembly versioning in .NET 1.1, which I have spoken about in some of my talks on the subject.

Assembly redirection, publisher policy overrides, and related assembly binding concepts can be configured in XML, through the local app.config or web.config for particular applications and subdirectories. But, you have to specify individual assemblies one-by-one even if you are configuring a single policy that should apply to multiple assemblies. If you miss one, time to trouble-shoot. But, if all SP1 files all carry the same version number, and no other group of updates carry that number, then shouldn't it be possible to specify a publisher policy override in one fell swoop, by identifying the version number the override applies to? 

My wish list on this subject:

1. Make it possible to deploy a publisher policy-like DLL to my local app.config, that supplies a binding policy that could group a number of assemblies and policies in a single DLL. Easier than an open XML config file that can be edited, and less error prone because it can be tested and deployed to clients.
2. With this, SP1 could have updated version, shipped a publisher policy, and provided a publisher policy override in assembly format for anyone to override just in their application. They might need to do this, if for example they need some time to update fixed to their application for the service pack. I know, it is supposed to be backward compatible, however sometimes clients depend even on bugs in previous versions, for their code to work...strange and lame, but true.
3. With this, deployment of fixes to local applications not installed in the GAC could include policy DLLs instead of hand-rolled updates to the local app.config/web.config. What if the customer has edited those config files? That means our installations have to edit the config, not ship a new one. This is painful. Let me ship a DLL that specifies a policy.

We don't have these options today, readily available, so they made the right choice for SP1 and vendors will have to make sure their apps function against it. And, there are plans to improve the versioning and deployment of framework vs. application assemblies in the future. Find out more in this insightful article by Cathi Gero and Jeffrey Ritcher:

http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVersioning

So, the dogfood is just ok, and that's why with SP1, MSFT opted out of eating it. For single-assembly updates, it tastes a little bit better.

Ok, I have no idea what happened to it, but all of the blogs I host, including this one, were returning junk to the Web browser at random. Except, it started not to be so random of late. What happened? I have no freaking idea. I rebuilt this blog with the latest dasblog files, and I removed the log files, and it works.

If you see any strange behavior...let me know. Oh, wait, if you see strange behavior, you won't be seeing this entry will you...so, you'll have to memorize my email address from this blog, and keep it with you at all times, in the event you see any strange behavior, aside from the lengthy useless entry this is turning out to be...

Kinda like when people say “to make a long story short” but really, they just made the short story longer...

I'm working on a problem that this blog has been having, displaying junk characters intermittently. Stay tuned...sorry for any inconvenience.

Hey guys, these webcasts are FREE, and there are a lot of really great topics being covered this week. Apparently you have to register soon because they have limits on the number that can participate live! I'm doing a new and improved version of my favorite talks on ASP.NET on Oct 21 and 22 first thing in the AM (see level 200 in the links below)....don't miss!

Here's how you register:

Now I can say I'm non-fluent in one more language, Italian. What a fabulous place, too bad my site went down while I was gone and unable to grab email depite numerous efforts. Sigh...back to work...alora, no me piache...

Thanks to everyone that attended this on Thursday night, it's one of my favorite topics! I mentioned several resources you could access now, and that I'm adding some new content for an upcoming article and an advanced presentation at Dev Connections.

For now, get my latest version of these resources here:

http://www.dotnetdashboard.net/Resources/wse.aspx

I will be updating this site with more in late October, when I formalize my new code samples. That will include my password hashing example.

Thanks again!

This entry has references for both of my talks at SD Best Practices (www.sdexpo.com) in Boston this week. I apologize that the slide decks are not on the conference CD, however I was invited to cover another speaker, therefore my materials were not part of the materials submission deadline as they were different talks from those originally scheduled.

I have added some supporting resources to the link below, related to security as well. Enjoy!

http://www.dotnetdashboard.net/resources/scalability.aspx

THank you for attending both talks, and please email me with any questions we could not get to within the timeframe.

Before I get to the resources for this event, I have to tell you about the events surrounding it...just for fun. I landed in Boston Sunday at 4:30pm last Sunday, took a beautful drive to Richmond, VT to present at the .NET user group run by Julie Lerman. The drive from Boston to Richmond was really beautiful, and, even as the night fell the moonlight accentuated the walls of trees around the otherwise pitch-black highway. When I arrived a Julie's, starving, she was the most fabulous host - she had a home-cooked meal waiting in the oven, and a freshly made (delicious) apple pie saved for us (Julie, her husband and myself) to eat afterward. Yum. The next morning, we each worked and chatted for a while, then went for a 2 hour hike up one of the many mountain trails (I can see why you'd want to be an outdoorsy person in VT, really really beautiful views) and some lunch, before getting ready to go to the user group. I thoroughly enjoyed myself, thank you so much Julie, for the great hospitality and for taking time off to show me around a little bit :)

Thanks also to the group for coming out for this talk. It seemed like the topic was really well appreciated, and that always makes me a very happy camper.

Ok, so I have a few relevant resource pages for this talk here:

http://www.dotnetdashboard.net/sessions/handlers.aspx

http://www.dotnetdashboard.net/sessions/soapext.aspx

I am always updating these pages, so please do check them periodically for updates (I try to mark the date of each updated sample).

I'm having a deja-vue here, because I think I've answered this question a number of times, pre-blog. However, since I once again have received the question, I'll go ahead and answer it once more, here.

The question: How do I invoke a Web service that supports session state, and maintain the session across posts?

The answer: The Web service proxy class, which derives from SoapHttpClientProtocol, has a property called CookieContainer. If you intialize this to an instance of the System.Net.CookieContainer type, it will store cookies returned to the client. When the same proxy, with the same instance of the cookie container, is used to invoke service methods, the proxy serializes cookies in the cookie container with the reqest, as a properly formed HTTP header. Before calling methods that support session state, be sure to create the CookieContainer and initialize the proxy like so:

System.Net.CookieContainer cookies = new System.Net.CookieContainer();

localhost.SessionService1 svc = new localhost.SessionService1();

svc.CookieContainer = cookies;

svc.UpdateHitCounter();

For a working demo, download this example, WSSessionCookie.zip.  Be sure and note that a single instance of the cookie container is scoped for the lifetime of the application. If you assign a new cookie container to the proxy, previously stored session ID (or, other cookies) will not be passed with the request.

NOTE: I don't generally recommend using session state with Web services. The typical argument for its use is to support login-once scenarios. However, to maintain a logged in state this way, there isn't sufficient security to prevent replay attacks or sniffing session ID from the wire. OASIS WS-Security specifications describe how to safely pass tokens, including session-based tokens that have adequate expiry rules. Furthermore, they describe how to encrypt and sign the message to be sure no tampering has been done. For other types of session-based tokens, see WS-SecureConversation, WS-Trust and SAML specifications.