Designer page is prepending Global to custom controls definition namespace - asp.net

I've got a custom control defined in my App_Code folder. When I add it to a page, I get the error Type 'Global.XXX.xxx.MyControl' is not defined
Class:
Namespace XXX.xxx
Public Class MyControl
Inherits TextBox
...code...
End Class
End Namespace
Page Useage:
<%# Register TagPrefix="xxx" Namespace="XXX.xxx" %>
...
<xxx:MyControl runat="server" id="StartTime" />
Designer:
Protected WithEvents StartTime As Global.XXX.xxx.MyControl
So what's happening is Global is being prepended to the namespace in the designer file. For some reason, the IDE thinks my custom control is living in the global namespace, but as far as I can see from searching the Object Browser, it isn't. Manually going in and deleting the prepended Global from the designer file allows me to build the page successfully, view it and test the functionality of my control, however this is far from an ideal solution, as the designer file is regenerated every time you make a change to the corresponding page.
Any ideas as to why it thinks my custom control, living in the App_Code folder, is in the Global namespace? Any suggestions on a better fix than the manual one?
EDIT: Perhaps a better question would be how to get that namespace into the Global namespace, so that when it creates the designer file, it's correct?

The question Type or namespace could not be found from App_code folder may be what you want.
Either put your class in a different folder or change the build settings as per http://vishaljoshi.blogspot.co.uk/2009/07/appcode-folder-doesnt-work-with-web.html

Related

How can I access the controls on my default aspx page from my class library, within solution

My problem seemed easy but I really can't find the right solution. How can I access mg controls (textboxes, grid view, etc) that are located in my default.aspx page from my class library. An error (The name 'GridView1' does not exist in the current context) is being thrown. I'm wondering why since I already added the project where the default page is located in the reference of my class library. I also include it in the namespace.
Exercise1 --> project where my default.aspx page is located
ClassLibrary1 --. where I wanted to use the controls
using exercise1; --> included in the namespace.
What else do I miss? thanks!
It seems to me you're working on this backwards, your class library shouldn't have access to the presentation elements, you should be (in your code behind) calling methods from your class library to interact with your gridview. You shouldn't be calling the gridview from the class library.

Should ASPX code-behind be within a namespace?

Something like this:
Namespace Test_NS
Partial Class Test_WebSite
Inherits System.Web.UI.Page
End Class
End Namespace
Or should I leave it alone and only keep the classes in my App_Code under a Namespace?
It makes little difference for a project. By default, your code-behind is NOT in a shared name-space. Also, your classes (I assume you're still talking code-behind) are not stored in the app_code folder.
Do you use visual studio? It will do the organizing for you, and if you're not sure, then I'd just leave everything as-is.
Any new .vb files (not code-behind) that you create independently do go in the app_code folder, and you can group these in name-spaces (or not) as you wish.

Confusion with Root Namespace in Asp.net web project

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??
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.
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.

Ambiguous Reference

In my WAP project, every .aspx's code-behind and designer share the same namespace. For example my Main.Master.cs and Main.designer.cs are both in the OurCompany.Web namespace by default.
When I go to another .aspx page and use the following, I get an "Ambiguous reference" error because it can't decide if I'm talking about my code-behind or designer file of that master page
<%# MasterType TypeName="OurCompany.Web.Main" %>
but by default this is the way VS creates .aspx pages so should I really care?
The designer files are all marked as "partial" classes so they don't get compiled into their own types.
My guess is that you really do have 2 classes called "OurCompany.Web.Main". A tool like Reflector would let you browser your DLLs so you could tell for sure.
This just happened to me, your problem is the JIT compilation creating temporary "copies" of your assemblies in a temp directory.
Make sure every namespace/partial class declaration is "tight", check for incorrect class names, wrong namespaces.
The problem "just went away" for me as well. Recreating or cleaning the solution will probably do it. Wish I could be more helpful but going cleaning up the source, both manually and with the right click menu probably helped.
I'm guessing you have a master page and a web form page with the same name on the code behind class. And this will prevent your site from working correctly (if it works at all).
I'd go through my aspx.cs files and looking for the class name main (find should work here). I bet you will find two files with the name. You will have to change one of them to something else. Just make sure you also change the Inherits in the .aspx page and the .designer.cs class name.

User Controls Not seeing the Day of Light - Doesn't recognize code-behind methods

This is driving me absolutely nuts.
I created a new WAP project in VS 2008. Copied over the files in my Web Site Project. Added any required references. Tried to convert the Web Project to a Web Application using the "Convert to web application".
None of my user controls are able to see methods in their code behind. They don't even see them so I get errors everywhere saying it doesn't know what this or that method is.
Example:
<%=CreateMenu(xxx.WebMenuType.Occasion, "menuShopOccasion", "Occasion") %>;
That is in my Header.ascx
And so it errors out because it has no clue what CreateMenu is!
In my Header.ascx.cs it's there and was being referenced with no problem in my old Web Site Project:
protected string CreateMenu(xxx.WebMenuType menuType, string menuID, string title)
{
...
}
It's probably a namespace problem. Make sure that the Inherits attribute in your <%# Page ... %> declaration refers to the correct path to the code behind file, including the namespace. The designer file must also be in the same namespace as the code behind.
I am not entirely sure this is your problem but....
you may be missing the .designer.cs files. For your example above there would also be a Header.ascx.designer.cs which contains a partial class (Header) which has all the declarations of the controls in the Header.ascx file?

Resources