Visual Studio 2010 bug? Wrong namespace in designer files.

Question

My Visual Studio 2010 Professional has started to produce incorrect designer files when editing aspx or ascx files. Visual Studio decides to use the System.Web.UI.DataVisualization.Charting namespace for all controls in the aspx/ascx files.

Example:

<asp:DropDownList ID="test" runat="server" />

ends up being this in the designer file:

protected global::System.Web.UI.DataVisualization.Charting.DropDownList test;

Has anyone else experienced this?

Answer 1

It appears that Visual Studio is unable to pick the correct namespace based on the registered controls.

I have resolved this issue by moving the charting registration to the top of the list. This result in the designer files being generated correctly again. The namespace for asp:Chart controls is correct too.

So my controls section in the web.config has gone from this:

<pages>
    <controls>
        <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add tagPrefix="asp" namespace="System.Web.UI.DataVisualization.Charting" assembly="System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    </controls>
</pages>

to this:

<pages>
    <controls>
        <add tagPrefix="asp" namespace="System.Web.UI.DataVisualization.Charting" assembly="System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
        <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    </controls>
</pages>

I still think there's a bug in VS that caused this behaviour.