How the ProfileCommon class gets compiled

Thursday, June 1, 2006

.NET ASP.NET

Lance and I were puzzling over the magic that happens when you configure the profile provider in asp.net 2.0. As you may or may not know it codegens a strongly typed class called "ProfileCommon" when you set up the properties in the web.config. Our question was how is this codegen happening and how is it that I'm getting intellisense at design time.

We both immediatly thought of the build providers. Those are plugins to asp.net that are used to generate code and compile specific file types. (e.g. web references, resxs etc.). You can write your own as well which is very cool. Anyhow this made the most sense but upon inspecting the main web.config there was no such build provider configured:

   1:  <buildProviders>

   2:      <add extension=".aspx" type="System.Web.Compilation.PageBuildProvider" />

   3:      <add extension=".ascx" type="System.Web.Compilation.UserControlBuildProvider" />

   4:      <add extension=".master" type="System.Web.Compilation.MasterPageBuildProvider" />

   5:      <add extension=".asmx" type="System.Web.Compilation.WebServiceBuildProvider" />

   6:      <add extension=".ashx" type="System.Web.Compilation.WebHandlerBuildProvider" />

   7:      <add extension=".soap" type="System.Web.Compilation.WebServiceBuildProvider" />

   8:      <add extension=".resx" type="System.Web.Compilation.ResXBuildProvider" />

   9:      <add extension=".resources" type="System.Web.Compilation.ResourcesBuildProvider" />

  10:      <add extension=".wsdl" type="System.Web.Compilation.WsdlBuildProvider" />

  11:      <add extension=".xsd" type="System.Web.Compilation.XsdBuildProvider" />

  12:      <add extension=".js" type="System.Web.Compilation.ForceCopyBuildProvider" />

  13:      <add extension=".lic" type="System.Web.Compilation.IgnoreFileBuildProvider" />

  14:      <add extension=".licx" type="System.Web.Compilation.IgnoreFileBuildProvider" />

  15:      <add extension=".exclude" type="System.Web.Compilation.IgnoreFileBuildProvider" />

  16:      <add extension=".refresh" type="System.Web.Compilation.IgnoreFileBuildProvider" />

  17:  </buildProviders>

So what gives? Well Luts Roeder's Reflector to the rescue (again). It turns out that a build provider is being used but its added dynamically in code by the CodeDirectoryCompiler:

   1:  internal class CodeDirectoryCompiler

   2:  {

   3:      private void FindBuildProviders()

   4:      {

   5:            if ((this._dirType == CodeDirectoryType.MainCode) && ProfileBuildProvider.HasCompilableProfile)

   6:            {

   7:                  this._buildProviders.Add(ProfileBuildProvider.Create());

   8:            }

   9:            VirtualDirectory directory1 = HostingEnvironment.VirtualPathProvider.GetDirectory(this._virtualDir);

  10:            this.ProcessDirectoryRecursive(directory1, true);

  11:      }

  12:  }

Now, why this is done this way and not with the standard buildProvider config section is still a mystery. My guess is that it has to do with the config that it is compiling exisitng in the web.config file. Which is a minor detail that I wish was differnet in the ProfileProvider stuff. I would have rather had a .profile file in the App_Code folder. Oh well not that big of a deal.

1 Comment