Unable to move User Control registration into nested web.config

Okay, I've been banging my head against this for almost five hours now, so I figure it's time to ask.

I'm working on a Web App (.NET 4.0, C#, ASP.NET, AJAX, jQuery) in Visual Studio 2010 (Professional) that has several parts. Let's call them Mo, Larry, and Curly, with each residing in a subfolder of the project. Currently, each has several User Controls, stored in a subfolder named Controls underneath their specific folder, and all of these controls are declared in the root web.config.

So we have something looking like this:

WebApp - Web.config

--Mo

----Controls

--Larry

----Controls

--Curly

----Controls

I am attempting to better "modularize" the Web App, and would like to be able to (without success so far) move the User Control declaration into nested Web.configs so that they cannot be referenced globally. I have tried to do this by just moving the control declarations into Web.configs that sit in the Stooge-named folders. Intellisense complains that they aren't known elements, but it works as long as I don't try to make any modifications to the page(s) that uses the controls. As soon as I do, (even something as simple as pressing Enter for a new line) the designer freaks out and removes the reference to the control.

I have tried web.configs in the named folders as well as the sub Controls folders. I have tried including the namespaces inside the web.configs at both levels as well.

So, anyone have any ideas?

Sample web.config declaration:

<?xml version="1.0"?>    
<configuration>
   <system.web>
      <pages>
         <controls>
            <add tagPrefix="curlyctrl" 
                 src="~/Curly/Controls/NuykNuyk.ascx" 
                 tagName="joke"/>
 开发者_JAVA技巧        </controls>
      </pages>
   </system.web>
</configuration>

I recommend placing your controls into their own class libraries and according namespaces. A secondary advantage to this is that if the controls need bug fixes or changes made you can compile the class library and update it on the server, without having to recompile your Asp.Net application. I don't really see any other way to modularize Asp.Net controls that would actually benefit the development of your application.

If you choose to modularize by assembly, you can differentiate controls with the same name by simply using a different tag prefix. For example, say you have the following assemblies and controls:

ServerControl1.dll

• ServerControl1

ServerControl2.dll

• ServerControl1

You should register the controls in your page as follows:

<%@ Register assembly="ServerControl1" namespace="ServerControl1" tagprefix="mo" %>
<%@ Register assembly="ServerControl2" namespace="ServerControl2" tagprefix="larry" %>

<mo:ServerControl1 ID="ServerControl1" runat="server" />
<larry:ServerControl1 ID="ServerControl2" runat="server" />

I hope this helps. I had a little bit of troubles understanding exactly what you are trying to accomplish by modularizing other then maybe easier organization or differentiation. But, you really only should run into differentiation issues if you are naming controls identical names that are ambiguous.

The only way I can find of doing it is to manually declare the control in the code-behind of the page you want the control on... in your case, something like...

Protected WithEvents joke1 As NuykNuykCtrl

Or...

protected NuykNuykCtrl joke1;

The auto-generation ignores the control as it's already declared, and your code should compile.

However, I fully accept that this is not as nice and neat as just creating the control on the page and letting Visual Studio create the declaration for you.