ASP.NET 2.0 Security... Damages Layer Separation

I have been reading about "The Demise of the Security Application Block" and I quote:

"Specifically, the factories, interfaces and providers for authentication, roles and profile have been removed. Equivalent functionality is provided by the new System.Web.Security.Membership class and System.Web.Profile namespace."

I think that is a really big mistake architecturally speaking... why? well because System.Web.Security.Membership class and System.Web.Profile are for
WEB applications, not for WindowsForms.NET applications, and authentication and authorization should be services independent of the presentation
mechanism, the Security Application Block should wrap the System.Web.Security.Membership class and System.Web.Profile namespace functionalities
and allow the developer to work in a presentation independent way (or Microsoft should change System.Web.Security.Membership class and System.Web.Profile and make them
System.Security.Membership class and System.Profile)

I think the easier thing to do is to bring back the the factories, interfaces and providers for authentication, roles and profile of the Security Application Block that provided this services without violating layer separation (following the good example of JASS).

And perhaps, in the future the "revived" Security Application Block should be merged with .NET code... or a new presentation independent API named ".NET Authentication and Authorization Service" (NASS?) should be created...

What do you think?

Layer Separation Violation: Web Configuration Manager... one of ASP.NET 2.0 mistakes?

The management of configuration in .NET applications was improved in .NET 2.0, now it is easier to have custom configuration sections, and we even have pre-built configuration section for Connection Strings (very useful for ADO.NET applications)

But... there are some design decisions I just don't get... "Configuration" is a separate concern from presentation (configuration can be used to set UI behavior, but in my opinion, configuration is in a lower layer), but now we have the WebConfigurationManager for web applications and the ConfigurationManager for client applications ...

From MSDN website:

Using WebConfigurationManager is the preferred way to work with configuration files related to Web applications. For client applications, use the ConfigurationManager class.

First, I thought... "this is going to be a problem", now I won't be able to read configuration in the lower layers (business facade, business rules, data access) without having to use my own proprietary "trick" to hide the fact that for those layers it is irrelevant whether the application has a WebUI or a WinUI... how could the .Net team make such a bad decision?

But then I realized... that i can use the ConfigurationManager from an WebUI (ASP.NET Application) without any problem... so my lower layers don't suffer from contamination from the presentation mechanism...

But now i am wondering... If the ConfigurationManager works perfectly... and doesn't tie my code to a particular presentation code... why should I use the WebConfigurationManager.... in fact... why should anyone use the WebConfigurationManager ? I just haven't figured out that...

The Tao of the Software Architect

Today I read about the Software Architect role in the SEI website, and I found a lot of very useful information:

• Books that an architect should read
• Essays
• Ways to become certified or accredited as a person than can create or evaluate architecture.

And, the essay that I liked the most was "The Tao of the Software Architect" (That can also be found in IBM website)

From the "The Tao for the software architect" I specially liked this part:

When the process is lost, there is good practice.
When good practice is lost, there are rules.
When rules are lost, there is ritual.
Ritual is the beginning of chaos.

I have seen places where ritual has taken control of everything, and people there believe they are doing things right, because they are following the ritual, but they don't realize that they are in chaos,  because they no longer understand why are they doing what they do... and that is really bad, because they don't look for ways to get out of the chaos, because they think that what they do is fine, because they are following the ritual (even if the ritual  doesn't achieve anything valuable for the organization)

Another part i also liked a lot is this:

If you want to be a great leader,
stop trying to control.
Let go of fixed plans and concepts and
the team will govern itself.
The more prohibitions you have,
the less disciplined the team will be.
The more you coerce,
the less secure the team will be.
The more external help you call,
the less self-reliant the team will be.

I believe I have that problem, sometimes I become a "control freak" and want everything to be built the way I say it, in the time I say it, exactly as I say it... but, as I gain experience I am starting to realize that is not the way to build a system, to be a good architect I have to help set a process that will be used to build the system, and make sure that the process is followed and that the processes evolves with the team and the system being built and at the same time get out of the way and let the team flourish...

As with most of this Zen-like things.. the truth is somewhere in the middle:

Too little control and you will have chaos, too much  control...specially just for the sake of following the ritual... and you will negatively affect the team motivation, creativity... and productivity.

I guess I need to find the Middle Path for Software Architecture...

Administering an ASP.NET WebSite

Hi! One of my friends showed me how to access the ASP.NET Administration WebSite without calling it from within VS.NET:

• Create a virtual directory ASP.NETWebAdminFiles in IIS that point to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ASP.NETWebAdminFiles

• Open properties windows of the new virtual directory, make sure that it is configured to run with ASP.NET 2.0, and in Security tab, uncheck Anonymous Access, check Integrated Windows Authentication. After that, you will be able to connect to WebAdminTools using the following syntax http://localhost/ASP.NETWebAdminFiles/default.aspx?applicationPhysicalPath=XXX&applicationUrl=/YYY in my case, it is: http://localhost/ASP.NETWebAdminFiles/default.aspx?applicationPhysicalPath=D:\Tasks\Libranyon\Photonyon\&applicationUrl=/Photonyon

Although I don't recommend to do it, if you want to access WebAdminTool from other computer, open WebAdminPage.cs from (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ASP.NETWebAdminFiles\App_Code) and comment the following code block

if (!application.Context.Request.IsLocal) {

SecurityException securityException = new SecurityException ( (string) HttpContext.GetGlobalResourceObject( "GlobalResources", "WebAdmin_ConfigurationIsLocalOnly" )); WebAdminPage.SetCurrentException(application.Context, securityException); application.Server.Transfer("~/error.aspx");

}

WebAdminTool still be protected by Integrated Windows Authentication, so you still some have some defense here. I have found this same instructions here, so I guess my friend got them from there.

Refactoring Bug in VS.NET 2005

Every time you modify the name of an element in a webform, it triggers refactoring
and checks all the project... and that is just plain not necessary... it is a
really really annoying bug! Perhaps they will fix it in a future release.... I just
hope I could turn off all VS.NET refactorings... (and let Reshaper do the job)