How is the auto-generated ASP namespace realized for an ASP.NET website project, from start (build) to finish (runtime)?

The 'ASP' namespace seems to be a generated because it's not used in the website project's source code, anywhere (or at least n开发者_运维问答ot explicitly used by the programmer of the website). I would like to know how it is fully realized.

For example:

Is it the responsibility of MSBuild to drive creation of the ASP namespace and if so, where is that instruction found? I know the C# compiler won't create a namespace from nothing of its own volition, so the ASP namespace must be fed into it, even if not used by the website programmer. Maybe it's generated into the source code by a different tool. The 'Temporary ASP.NET Files' folder might have some bearing on it. As you can see, I want all the gory details in order to unlock and understand that namespace ...

Visual Studio seems to have tooling that allows the ASP namespace to be used (IntelliSense support for it) but that masks my understanding of it.

How is the 'ASP' namespace realized in a website from start to finish?

(I haven't found a good article that explains all this.)

Here the ASP namespace is shown in .NET Reflector. (This image taken from Rick Strahl's blog)

The ASP. namespace can be used to Load dynamically a custom control with more safe that the cast will works.

You can control what name the custom control can take in the ASP. namespace by placing the ClassName="ControlClass" on the declaration of the name space and the dynamic control now will have a reference to ASP.ControlClass to make a secure cast when you use the LoadControl

You can read the full steps on MSDN http://msdn.microsoft.com/en-us/library/c0az2h86(v=vs.100).aspx

When you do not use the ASP. namespace and left the control takes an automatic name, then the case may fail (I do not know why, but its fail on my sever time to time) The reference that there created are

namespace ASP
{
    [CompilerGlobalScope]
    public class Control_Class_nameByDirectory : ControlClass
    {
        [DebuggerNonUserCode]
        public ControlClass();

        protected override bool SupportAutoEvents { get; }

        [DebuggerNonUserCode]
        protected override void FrameworkInitialize();
    }
}

And when you try to make a cast like (ControlClass)LoadControl("~/module/Control.ascs") it may fail because is recognize it as Control_Class_nameByDirectory and not as ControlClass

Now if you declare the ClassName on the control header as MSD says, the result is the control to get the same ClassName as the one you have define :

namespace ASP
{
    [CompilerGlobalScope]
    public class ControlClass : global::ControlClass
    {
        [DebuggerNonUserCode]
        public ControlClass();

        protected override bool SupportAutoEvents { get; }

        [DebuggerNonUserCode]
        protected override void FrameworkInitialize();
    }
}

and here you can use the ASP.ControlClass to cast the control with out worry if its fail.

So following the steps that described here http://msdn.microsoft.com/en-us/library/c0az2h86(v=vs.100).aspx you can avoid issues like that. (and that I have face them)

The issue of failing to case a custom control with out reference to ASP. namespace have been seen both on Dot net 4.0 and 4.5 versions. And the worst is that is a random failure - meaning that some times is happens, some time not, and I was unable to find the reason.

I'm going to assume that you're looking for the prefix on server control tags... if that's not the case, let me know.

The prefix is registered in the web.config file under configuration/system.Web/pages/controls. You can modify it if you want, or register additional prefixes for your own control libraries.

MSDN info here: http://msdn.microsoft.com/en-us/library/ms164640.aspx

This namespace is used on the code that ASP.NET generates from parsing your .aspx and .ascx files.

I have no idea why you care, though. It's just a namespace. There's nothing "special" about it, and you shouldn't be referencing anything in that namespace.

To understand how all of this works, read "ASP.NET Life Cycle".