Ok, so I just had a long discussion with one of the smartest guys I know, my colleague, mentor and friend - Juval. We were talking about strong names, full trust the global assembly cache and .NET assemblies. It started out innocently enough, however as the discussion continued, we both insisted on being right...and as it turns out, we were both right...but I still lost $1 due to my own muddy description of the bet. Perhaps you've been confused by this as well? Read on...

She said:

When you deploy assemblies to the GAC, they get full trust.

He said:

No, you're wrong. The GAC has nothing to do with the assignment of privileges. You want to bet? I can prove it.

She said:

No, I'm sure of this, I do it all the time with my ASP.NET applications when I deploy business objects to the GAC. They get full trust. This is important because it is the only way I can reduce the privileges of the ASP.NET application assemblies (using the <trust> element as I discuss in my article here: http://www.theserverside.net/articles/showarticle.tss?id=SandboxingComponents), and then elevate privileges as needed to invoke assemblies that demand full trust or other permissions. The stack walk would fail, if I were not able to elevate privileges at some point, and assert to circumvent the stalk walk. I certainly don't want ASP.NET application assembly to run with full trust if I can avoid it.

He said:

Ha, I'm right. You see?

So, he demos his client app (EXE), with a dependency on another assembly (DLL) that was deployed to the GAC. He removed full trust for assemblies deployed to local machine. Then he invoked a .NET assembly that required full trust. Sure enough, the permission demand fails.

She said:

Crap. Thinking thinking thinking...Well, wait a minute, you need the policy to at least grant full trust based on the strong name or something like that? Darn it, what is it? I know there is something...ok I didn't describe this right...(fumbling)...I mean...er...I wasn't trying to say GAC = full trust, but that you need to deploy to the GAC, at least with ASP.NET...to get full trust...hmmm...ok, here's your damn dollar.

ABOUT AN HOUR LATER

She said:

Aha! I went and reread my article (above) and it jogged my memory...basically, ASP.NET runtime uses different security policies to assign permissions. Inside the security policies for ASP.NET such as web_lowtrust.config, web_hightrust.config, etc...there is a setting that pulls in full trust for GAC assemblies, automatically.

                 <CodeGroup

                                class="UnionCodeGroup"

                                version="1"

                                PermissionSetName="FullTrust">

                            <IMembershipCondition

                                    class="UrlMembershipCondition"

                                    Url="$Gac$/*"

                                    version="1"

                            />

If only I could remember these things in the heat of discussion, I would be $1 richer right now.

Ok, you were right...but so was I :) Ego somewhat repaired.

No, please, make it stop, don't make me go back, I don't want to go back...I'll never go back...ok, fine, I'll go back...for now...but I won't like it...

Well, if you haven't stated these words, or thought them, or something like them, you will...believe me. Once you get your hands on ASP.NET Beta 2, it is next to impossible to look at 1.1 again without holding back tears of pain. It's like buying a killer new outfit...you want to wear it right away, not hang it in the closet for later! Yeah, you know what I mean.

Unfortunately, there are plenty of companies out there that are not ready to embrace Beta 2 as their current development platform for new applications. Nor are they prepared to migrate all 1.1 applications just because 2.0 is cool. It's called a business decision...companies don't make money by converting code to new platforms just because. Migration and platform upgrades require planning.

So, the question is, how can ASP.NET developers lessen the pain of returning to 1.1, and better prepare to migrate their code to 2.0? Well I just happen to be updating one of my migration speeches these next few weeks, in preparation for the SDC conference I present at each May in The Netherlands. So, I'll be posting some blogs on the subject, based on the following core topics:

• Master Pages
• Navigation Controls
• Data Controls and Binding
• Security Controls and Membership API
• Configuration
• Caching
• Localization
• Personalization
• Deployment

Have any other hot points to add to the list? Let me know! Otherwise, watch for the migration blogs forthcoming...

I just stumbled upon this site where you can access all the redistributables including 1.0 (who cares!), 1.1, 2.0, Compact Framework and related service packs for each. For those interested in a quick stop:

http://msdn.microsoft.com/netframework/downloads/updates/default.aspx#.NET%20Framework%202.0%20Beta%20SDK%20and%20Redistributable

Sometimes defaults are bad. The latest Beta release has a default setting for each @Page directive, that adds the Culture and UICulture parameters as follows:

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" Culture="auto" meta:resourcekey="PageResource1" UICulture="auto" %>

At first blush this may seem reasonable, even good. However we have to consider how these settings are employed at runtime to understand the hidden issues.

Automatic culture setting (as discussed in my article here: http://msdn.microsoft.com/asp.net/community/authors/mlb/default.aspx?pull=/library/en-us/dnvs05/html/asp2local.asp) is intended to automatically initialize each request thread to the Culture and UICulture matching the calling user's browser language preferences. That's cool, really cool.

But, in a real world application, we don't just use the browser settings to determine user preferences. We usually collect user preferences in some other way, and persist them in a profile or other data store. I may want to select the default browser setting the first time the user accesses the site, but once I collect their preferences I would prefer to use those going forward.

The <globalization> setting for culture and uiCulture in the web.config is a better place to configure automatic culture selection, since it will apply to all pages in the site (why would you, after all, exclude a page from this?). 

<globalization culture=“auto“ uiCulture=“auto“></globalization>

With this configuration, the request thread's culture settings are initialized very early in the request cycle, even before we intercept the HttpApplication.BeginRequest event. That means we can modify this default, to draw from a data store, before the page handler is executed, and centralize the management of this process. 

If the page setting is also configured, guess what? It proceeds to update the request thread with those settings, before the page is processed. The best thing to do for now, is remove those parameters from your pages after you generate resources, to avoid problems.

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" meta:resourcekey="PageResource1" %>

I know the guys working on this aspect of .NET well enough to know this is probably an oversight of the beta that will be fixed before the final release. And if I'm wrong on that, I guess we will just have some manual labor but at minimum we have a workaround. This doesn't cause any insurmountable problems.

My next article on www.TheServerSide.NET will have some code samples with this solution just for you.
 

Somasegar is a VP at Microsoft, who has provided us with an honest perspective on why Beta 2 did not ship by the end of March as promised:

http://blogs.msdn.com/somasegar/archive/2005/04/18/409338.aspx

I'm personally happy to see that the focus was on making sure it could be production-ready for those go-live licenses...thanks for keeping us informed Somasgear!

Scott Guthrie has a similar post here:

http://weblogs.asp.net/scottgu/archive/2005/04/16/401381.aspx

But more importantly, you can head over to MSDN subscriptions to download now!

As I prepare a speech for Tech Ed US in Orlando, and a few new articles on the localization front for 2.0, I've noticed a few things you might want to prepare for as you migrate your code samples from Beta 1. Now, there is a site that lists some of the relevant changes from Beta 1 to Beta 2, here:

http://msdn.microsoft.com/asp.net/whidbey/beta2update.aspx

And, I'm duplicating a few of these entries just to provide you with more specifics, and also because I captured this information before I knew about the site :) Here goes...

1. @Page, @Control attribute changes

The CompileWith and ClassName attribute names have changed to CodeFile and Inherits, respectively. So, in your content and master pages you'll change this:

<% @Page Language="C#" MasterPageFile="~/site.master" CompileWith="otherResources.aspx.cs" ClassName="otherResources_aspx" %>

to this:

<% @Page Language="C#" MasterPageFile="~/site.master" CodeFile="otherResources.aspx.cs" Inherits="otherResources_aspx" %>

It looks like there is not a migration tool to automate this process for you, likely because changes between beta releases aren't worthy of a tool. So, deal with it :)

2. <localize> controls require id attribute

The message you get here might be cryptic, if the <localize> element is embedded in existing user controls consumed by one or more pages. Check your <localize> elements and provide an id for them, and magically errors should disappear.

This:

<localize runat="server" meta:resourcekey="LiteralResource1">Culture:</localize>

changes to this:

<localize id="l1" runat="server" meta:resourcekey="LiteralResource1">Culture:</localize>

3. Explicit localization expression syntax change

In previous versions you could specify a default value that would be presented in the absence of supporting .resx files. This would be useful to Web developers, enabling them to design pages without requiring access to resources. It appears the syntax has changed so that any default values specified on explicit localization expressions for shared resources, is not supported. So this:

<%$ Resources:Glossary, BlogTitle, "dasBlonde" %>

changes to this:

<%$ Resources:Glossary, BlogTitle %>

The question is, how should Web developers work with this change? What will they see in the absence of a default, or, is there another way to specify a default? I'm still looking into these details...but I wanted to get these thoughts up here right now lest I forget to blog it! Will update this entry with my findings.

4. Pages and User control class declarations require base class

Previously the partial class generated for the code file of a content page, master page or user control did not specify base class inheritance. Now this is a requirement, and the error messages can be confusing because they refer to the inability to override the base class methods such as GetHashCode() or FrameworkInitialize(). To repair the problem, specify a base class for content pages as System.Web.UI.Page, for master pages as System.Web.UI.MasterPage, and for user controls as System.Web.UI.UserControl. For example this:

public partial class loginMenu_ascx

changes to this:

public partial class loginMenu_ascx : System.Web.UI.UserControl

or, in VB.NET,

Partial Class sidebar_ascx
    Inherits System.Web.UI.UserControl

5. Localization API changes

If you use the Page level APIs to access local page resources, or shared resources, the new methods for this are GetLocalResourceObject and GetGlobalResourceObject, respectively. For example this:

 this.lnkLogin.Text = (string)this.GetPageResourceObject("Login");

changes to this:

 this.lnkLogin.Text = (string)this.GetLocalResourceObject("Login");

6. Event handlers must be protected

Previously event handler declarations were private (no accessibility modifer provided on event handlers). Even handlers must be protected to be accessible therefore a modifier is required. For example this declaration:

void dlCountries_DataBinding(object sender, EventArgs e)

now must be:

protected void dlCountries_DataBinding(object sender, EventArgs e)
  

I'm confused by this requirement, since partial classes are supposed to be "the same class" why should the event handler have to be protected? I need to look into this as well, and post my findings.

That's all for now, hope this helps you migrate more quickly! In a few weeks look for a new article on TheServerSide.NET from yours truly related to globalization. And, don't forget my globalization resource site: http://www.dotnetdashboard.net/sessions/globalization.aspx

Ciao for now!

Ok folks, it has been a phenominally long and hard few months for this little programmer chick...the clients, the speeches, the articles...oh my! So, I've been stockpiling some thoughts that I should be able to post now...a few coming your way this weekend at last!

Yesterday I whipped over to Arizona to deliver an INETA (www.ineta.org) presentation for the Arizona .NET User Group run by Scott Cates (who I didn't realize, even thought we have met several times, is the owner of www.kbalerts.com!). My fellow RD Michael J. Palermo dropped in as well, you know, the one that wrote the hilarious Valentine's Day blog:

I was shocked to arrive and find that people (like Scott) are still somehow finding my 1996 glam shot photo, the one with all the big hair, and posting it in places (like their user group site) that I'm not aware of. THis is crazy, when will that photo go away! It only demonstrates that I still had 80's hair in the 90's...how embarrassing!!! Ok, well it's not that big of a deal...but I always laugh when I see that thing...what people must be thinking!

On to more serious matters, the PDF for my presentation, and my reference materials for the group after my talk. Here are the links you are looking for.

My PDF with slides for this event: wsesecurity_arizonaineta.zip (162.16 KB)

My resource site for WSE materials is here: http://www.dotnetdashboard.net/resources/wse.aspx. You'll find links to my WSE article for CoDe Magazine and the latest code sample link which demonstrates everything I did in the talk last night and more.

WSE 2.0 is now on SP3, so you'll want to download that: http://www.microsoft.com/downloads/details.aspx?FamilyId=1BA1F631-C3E7-420A-BC1E-EF18BAB66122&displaylang=en. Not all of my code samples are yet up to date with SP3, but the larger sample for my article is up to SP2 right now, stay tuned for changes on this site as I post more samples. Easier to go forward than go back to all my past work :)

For my interop demonstration, see www.interopwarriors.com.

For information about IDesign go to: www.idesign.net. You'll be able to find a list of all my articles on the site, plus IDesign utility downloads (not specifically for WSE, but lots of other interesting things).

I had a great time, thanks for having me present! You're fantastic hosts and a great, interactive crowd. 

Brian Noyes and I delivered this full day tutorial on .NET fundamentals, the advanced concepts (oxymoron, I know). The code samples I demonstrated can be found here:

AdvancedFundamentalsCode.zip (494.75 KB)

Also, see Brian's site for more! Thanks for joining us!

http://www.softinsight.com/bnoyes/

In this talk I discussed architectural approaches to address incremental steps to scaling .NET applications.

Here are my references for this talk, thanks for coming out:

• HTTP Handler references:
• http://www.dotnetdashboard.net/sessions/handlers.aspx
• Here’s my scalability page that takes you to my MSDN article discussed in the session, and other resources on scalability:
• http://www.dotnetdashboard.net/resources/scalability.aspx
• I also wrote some articles for The Server Side.NET regarding distributing components and security. Find those and more security resources here:
• http://www.dotnetdashboard.net/sessions/securitysummit.aspx

In the short hour we had together on this subject, we looked at many features of Windows and Web localization for .NET 2.0. Big topic, so you’ll want references and code samples to ponder on, and I have collected my globalization resources here:

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

Code samples I showed in the session are related directly to samples for my articles, but keep an eye on this reference page for updates coming for Beta 2! Also, the articles will help to review things in depth that we had limited time to touch on.

Oh, and stay tuned for more samples in May/June, when I’ll be writing some new articles based on the .NET 2.0 code base. Any requests on solutions you’d like to see added to the resource page? Email me!

I delivered not one, but two talks on this subject at the conference in Orlando…the first a fundamentals session, followed by a more advanced session that ended with ClickOnce. I have written some tutorials and articles on the subject that can be found here:

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

In this tutorial I reviewed the issues we revisit with our return to building Windows client (thick client, smart client) applications, including design, deployment and versioning, automatic updates, and ultimately we discussed what ClickOnce brings to the table.

My gui samples were mostly ad-hoc, but I'll be posting more resources on this subject for you soon, for 2.0. In the meantime, the versioning, deployment and security aspects I discussed can be found here, including a full tutorial of the process:

http://www.dotnetdashboard.net/session/versiondeploy.aspx