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.
Related
My confusion is not new here or arround the web, yet, i have some questions for which i did not find answers anywhere:
The first question is:
Why is Inherits necessary on CodeFile and not on CodeBehind?
I read: http://msdn.microsoft.com/en-us/library/vstudio/ms178138(v=vs.100).aspx and some more pages, and i understand that CodeFile is for source code and for compilation on the fly while the other is for an assembly. This raised me another question:
Why do everyone say that CodeBehind must be an assembly if i find
File.aspx.cs everywhere including in a test project i have and it
works like a charm? Is this a compiled assembly?
But, as of the first question, and based on the url i supplied, i might understand, why the Inherits is necessary. I assume the compiler must know what is the name of the partial class to compile later. Makes sense. Yet, shouldn't it be necessary on CodeBehind as well? If we are going to merge the partial classes, i suppose i should give the name of the one i want to merge. I even tried adding another partial class to the .cs file and it compiled/ran well.
Am I missing something here?
I also read that CodeBehind is not used anymore and it's CodeFile, the new one.
Any .NET guru to help me?
Thank you all in advance.
UPDATED:
I tried to implement events using no Inherits on CodeBehind. It didn't work. This makes more sense. But, it doesn't complain on compilation, while CodeFile does. Is there any reason for this?
Inherits property carry the class name which written inside the code behind file. you can have multiple classes in same code behind file and inherit in two different .aspx file
CodeBehind file provides the code behind for the aspx page. When you add a new "ASP.NET webpage with CodeBehind", let's call it NewPage.aspx, 2 files are also created, called NewPage.aspx.cs and NewPage.aspx.designer.cs. NewPage.aspx.cs is your CodeBehind file. As Vijay stated, since a (C#) file can have multiple classes (which is different from Java, where a class file can only contain 1 class, and the class name have to be matching the file name), Inherits=[namespace].[class] indicates which class you want to actually use for the web page.
The CodeBehind attribute is for Web application projects. The CodeFile attribute, on the other hand, is for Web site projects.
I'm developing a stand-alone ASP .NET component for dropping in to various sites we create.
Part of the application is a CompositeControl, which needs to load a UserControl.
However, CompositeControl has no LoadControl() method - in stead, I must (as far as I can see?) rely on Page.LoadControl() and this is a problem!
How do I know the path to my control, when the page is not part of the assembly?
The page the CompositeControl is situated on resides outside the assembly I am writing the Page.LoadControl() code in, and thus cannot find my .ascx file.
I've tried LoadControl(type, object[]) but this doesn't load the "code infront" file, which I need.
So - how do I find the Path to some .ascx file inside some included assembly (name known, ofc) for my Page.LoadControl? Or, alternatively, is there some other way to load the control from inside the CompositeControl?
Cheers!
EDIT:
The following provided the solution, although it is slightly hacky. It does work, however:
http://www.cmswire.com/cms/tips-tricks/aspnet-reusing-web-user-controls-and-forms-000915.php
This may be of some help to you : http://blogs.msdn.com/b/davidebb/archive/2005/10/30/487160.aspx
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.
I have controls in ascx file but i can't see them in intellisense in .cs file.It was working nice before.
I can see the control names in designer.cs file.
I have deleted the Asp.net temp files in AppData folder but still not working.The other user control files in the app can reference coerrectly to it's page controls. What is the problem here ?
I use VS2008.
Look at the top line of the .ascx page and check out the value of Inherits= and make sure that is has the right namespace.class appropriate for your codebehind. For example if your namespace is ProjectNamespace and your control class is MyControl then it should be ProjectNamespace.MyControl. This can get out of synch if you renamed the ascx file, etc and cause this type of problem.
This happens to me every time I copy a user control from one project to another. The connection between the ascx and the code-behind breaks.
This solution is tedious but it gets around the problem:
Create a new User Control. Visual Studio will correctly connect the ascx file to ascx.vb file.
Copy the ascx and vb code from your original control into the new one.
Delete your original control.
You now have a working control, but it has a different name.
If it is important to retain the name of the original control, repeat the whole process again and copy the second control to a third one with the correct name.
Write to Microsoft and ask them to stop adding bells and whistles we don't need and fix the basic stuff!
I just figured this out for my situation: in the Page parameters of the .aspx file, the 'Codefile' parameter was pointing to the file name: 'LabEdit.aspx.cs'. It should have been pointing to the path: "~/WOPages/LabEdit.aspx.cs". I know I didn't move the codefile or the page file, so this is maybe a problem with VS2008
I have solved the problem, I have uninstalled and reinstalled VS2008 and it is solved.
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?