views:

313

answers:

2

I have an VS2008 solution with 2 projects, WebUI and Domain; WebUI references domain

The Root Namespace in the WebUI project is:MyCompany.MyProjectName.WebUI
The Root Namespace in the Domain project is blank. (Namespaces are manually declared for all classes)

So everything has been working fine, until I tried to reference a class in Domain via a fully qualified path: MyCompany.MyProjectName.Domain.EntityClasses.SomeClassName

VS was not able to find the class. However, if I do at the top of the code file: Imports MyCompany.MyProjectName.Domain.EntityClasses

....then it can see it. (Just as SomeClassname, not the fully qualified name)

Does this make any sense?

So, then I cleared my WebUI Root Namespace, and voila, the fully qualified declaration then does work. However, doing this then seemed to invalidate the registration of all my user controls on my pages. The only thing that seemed to solve this was in the codebehind of each user control, manually add a namespace of MyCompany.MyProjectName.WebUI ...which might make sense as perhaps the namespaces of the pages somehow had still retained the root namespace value. But, if I was to create a brand new aspx page and drop a user control on (this is before manually adding the namespace), even that page couldn't properly register it. Yet, the uwer control properly rendered in design view....so the VS UI seemed to be able to properly resolve it, but the compiler seemingly can't.

So from what I can tell, I can at least get things to work by manually wrapping user controls in the proper namespace. Why this is necessary for aspx pages, that have no namespace specified, to see the user controls, seems to make no sense.

Is there some fundamental principle I am misunderstanding??

A: 

Ok, I think this is the problem:

When you have a root namespace specified for your project and create a new aspx page, the aspx page will hardcode the root namespace in its definition at creation time, ie:

<%@ Page Title="" Language="vb" AutoEventWireup="false" MasterPageFile="~/MasterPages/DefaultMasterPage.Master" CodeBehind="Home.aspx.vb" Inherits="yourCompany.yourApp.WebUI.Home" %>

...and that will never change even if you change the project root namespace. If you didn't have a root name space when the page was created, you'd get:

<%@ Page Title="" Language="vb" AutoEventWireup="false" MasterPageFile="~/MasterPages/DefaultMasterPage.Master" CodeBehind="Home.aspx.vb" Inherits=".Home" 

So if you change the root namespace half way through, all the prior aspx pages will have their namespace hardcoded to the old value. However, I think the code behind for the aspx does react to the removal of the root namespace, so you start to get weird behaviour with user controls, etc. and you have to go into all the code behinds and explicitly set a matching namespace in there for the pages to work properly. In this case, I think the best thing to do is search all your aspx files for this explicit definition of the namespace (in the Inherits tag) and remove it. You should, I think, still be able to explicitly set the namespace in the codebehind if you so choose, which the aspx will inherit. Not 100% sure though.

Long story short, decide which namespace naming method you want at the start and stick with it.

tbone
A: 

I would suggest you use the Web Application project format to avoid this kind of thing. Web Site projects are a retrograde move for anything other than simple sites.

5arx