Compiler warnings from generated code


This post was originally published here.

Although I believe strongly in treating warnings as errors, on rare occasions I get compiler warnings from generated code.  Examples of generated code include the designer code files for Windows and Web forms, XAML, etc.  Warnings in those files are easily removed, as it’s almost always related to files coded by the programmer.

I recently hit a really strange compiler warning while using the aspnet_compiler tool, which compiles the ASPX, ASCX, and other content.  Part of this process is to parse the ASPX and ASCX files and create C# files from those.  However, I started getting very strange warnings from the precompilation:

c:WINDOWSMicrosoft.NETFrameworkv2.0.50727
  Temporary ASP.NET Filesecommstore5c1cb822
  6aeabbaeApp_Web_d0wxlov2.10.cs(87):
  warning CS0108: Ecomm.Login.Profile' hides inherited member 'Foundation.Core.Web.PageBase.Profile'. 
  Use the new keyword if hiding was intended.

Shadowing warnings aren’t new to me, but this one is especially strange since it came from ASP.NET.  Specifically, a property created in an auto-generated class conflicts with a property in a global base Page class we use for all of our ASP.NET pages.  The base Page class is created by another team here, which provides all sorts of logging, etc.  I can’t touch that one, nor would I want to, as it is used company-wide.  That base Profile property isn’t virtual either.

But how can I get rid of the other one?  I tried all sorts of magic:

  • Shadowing and exposing as virtual (the subclass and override method)
    • Shadowing and preventing overriding by using the new and sealed modifiers on that property</ul> Nothing worked.  No matter what, the Profile property would get created.  What does that code file actually look like?  Here’s the more interesting part:
    public partial class Login : System.Web.SessionState.IRequiresSessionState {        
        
    #line 12 "E:devecommstorebuildDebugecommstoreLogin.aspx"
    protected global::System.Web.UI.WebControls.PlaceHolder mainPlaceholder;
        
    #line default
    #line hidden
        
    protected System.Web.Profile.DefaultProfile Profile {
        get {
            return ((System.Web.Profile.DefaultProfile)(this.Context.Profile));
        }
    }
        
    protected ASP.global_asax ApplicationInstance {
        get {
            return ((ASP.global_asax)(this.Context.ApplicationInstance));
        }
    }
    }
    

</pre> </div>

There&#8217;s the offender, the auto-generated Profile property.&nbsp; Looking back at some older build logs, I notice that this warning didn&#8217;t show up until we migrated to ASP.NET 2.0.&nbsp; One of the new features of ASP.NET 2.0 is the [Profile properties](http://msdn2.microsoft.com/en-us/library/at64shx3.aspx).&nbsp; ASP.NET 2.0 profiles allow me to create strongly-typed custom profiles for customers and let them be integrated into our ASP.NET pages, be automatically stored and retrieved, etc.&nbsp; If I defined custom properties for my profile, then a dynamically created Profile class would be used (instead of the DefaultProfile type).

However, we don&#8217;t use Profiles, so I can just turn them off in our web.config file:

<div style="font-size: 10pt;background: white;color: black;font-family: consolas">
  <p style="margin: 0px">
    <span style="color: blue"><</span><span style="color: #a31515">profile</span><span style="color: blue"> </span><span style="color: red">enabled</span><span style="color: blue">=</span>&#8220;<span style="color: blue">false</span>&#8220;<span style="color: blue"> /></span>
  </p>
</div>

By turning Profiles off, the Profile property is never created in the auto-generated code.&nbsp; The warnings go away, and our problem is solved.

There are several other instances of these new ASP.NET 2.0 features in auto-generated code causing naming collisions with existing properties when migrating from ASP.NET 1.1.&nbsp; The solution was always to rename your properties, but since I couldn&#8217;t do that, turning Profiles off did the trick.
Treat warnings as errors