I have an ASP.NET web site that I am trying to build, but I am getting some compiler errors on one page.
This page was originally not in any namespace. I then moved it to a namespace and rebuilt successfully. Now I removed the namespace, but the generated part of the partial class is still generating with the previous namespace.
I've deleted the generated files in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files, and they have regenerated with the out of date namespace.
Why are the generated parts not in sync with the manually created parts?
EDIT
Found solution. Had to change the Inherits attribute at the top of the .aspx file to match the new namespace/class name.
Related
I have a project I'm working on in a Visual Studio 2003 and SQL Server 2005 environment. Lately I've been having some trouble with the codebehind files for my ASPX web pages. Some pages are referring to codebehind from other pages.
Recently, for example, I copied a page from one of my projects to use it as a starting point (it is for a form with multiple pages), After renaming it, the codebehind and other files followed suit. However after modifying the page to what I needed, I found out that it was still referencing the old codebehind (making references to controls that are no longer there).
I checked the aspx code, and the reference is correctly pointing to the new codebehind. I've tried building and re-building the project several times, resetting the IIS, deleting temp files and modifying the web config. No dice.
If you copy a page in Visual Studio and rename it, it will automatically change the Codebehind attribute in the <%# Page declaration on the .aspx markup.
But what it won't do is change the name of the class in the codebehind file, or the class that the Inherits attribute on the declaration points to.
Firstly, change the Inherits to your new class name - this should automatically change the designer file to use the same class name.
Then change the class definition in the code-behind file.
I've worked on VS projects before where there is no .designer.cs files.
Now I started a new project on a different computer and I can't get rid of designer.cs files. It's really annoying me. Do I really need it, how can I remove it? There must be a setting somewhere.
YES! You can remove them......here is how.....
HOW TO DELETE DESIGNER.CS PAGES FROM YOUR WEB APPLICATION
After great torture and much testing seeking a way to avoid designer.cs pages in Visual Studio (v. 2015 and earlier), I finally found a work around for this. If anyone is stuck with designer.cs pages in a Web Application Project in Visual Studio this solution will allow you to erase all application compile errors quickly then delete the designer.cs pages completely from your project.
First understand the following:
Web Application Projects use designer.cs pages (partial classes) auto-generated by Visual Studio, and which are tied to the design tools built into Web Applications which the web app model sustains. I call it web sites for dummies. I could find no setting or way to turn the creation of partial classes and designer.cs pages off, as they are often unnecessary code tied more to the IDE than the functioning of the application. All partial classes get compiled into one class anyway. Web Apps also get pre-compiled or built ahead of time in general by design, and those dll's gets pushed into bin folders.
Web Site Projects do not use designer.cs files and are less tied to the IDE. They allow for a cleaner coding of class structures. They also use partial classes. But Web Sites Projects generally get compiled at runtime.
SOLUTION - How to Remove "...designer.cs" errors and files from a Web Application Project in Visual Studio.
Unless you want to convert your web project from an Application to a Web Site model in Visual Studio, this solution below allows you to run your project as is, yet like a Web Site, where you can move most or all the designer.cs partial class control references from that file into your main web page partial class file. It also removes all errors AND does not interfere with the Visual Studio recreating those designer files should other developers be sharing them and adding controls to pages and forget to use this solution on specific pages.
In the front-end .aspx pages, in the #PAGE directive at the top, change the "CodeBehind" to "CodeFile". Make sure it still references the same .cs code or class file.
Add the "CodeFileBaseClass" attribute to the same #Page directive in your web page and have it access the fully qualified path to the same .cs above with any namespaces in the path.
Make sure you use the "Inherit" attribute with the same path as the "CodeFileBaseClass".
You should have the following for every web page in your Web Application with these attributes formatted as such:
<%# Page Language="c#" CodeFile="index.aspx.cs" CodeFileBaseClass="YourNameSpace.index"
Inherits="YourNameSpace.index" %>
Now go into your designer.cs file for the page and copy any control references from the partial class in your designer file into the partial class of your main .cs file for the web page. If you have lost your designer.cs files, just add in any web controls as field references as fields that the compiler says are missing. After you do that DELETE the designer.cs file. You don't need them and have complete control over your web page controls using the main .cs file and its partial class.
Below is what I had in the designer.cs file before deleting it. Below it is the main index.aspx.cs file for my project after I added the designers.cs control reference as a field in its partial class. I then deleted the designer.cs file and its code completely from my project:
namespace YourNameSpace
{
public partial class WebForm1
{
/// <summary>
/// form1 control.
/// </summary>
/// <remarks>
/// Auto-generated field.
/// To modify move field declaration from designer file to code-behind file.
/// </remarks>
protected global::System.Web.UI.HtmlControls.Literal Message1;
}
}
In my index.aspx.cs file below you can see where I pasted the last "Message1" reference line from the designer above into its partial class at the top. You can see how I was then able to access the web page Literal control, Message1, in my Page_Load event and modify the text. That shows it was referenced correctly now, compiled, and worked, where before such references failed if the designer.cs file was missing or its partial class failed:
namespace YourNameSpace
{
public partial class index : System.Web.UI.Page
{
protected global::System.Web.UI.WebControls.Literal Message1;
protected void Page_Load(object sender, EventArgs e)
{
this.Message1.Text = "hello world";
}
}
}
The key to fixing this is the CodeFileBaseClass and CodeFile attributes in the #Page directive in the main web page. This prevents new member references and controls in the web page from being automatically generated by the Visual Studio IE and stuck as stubs in designer page partial classes (which to me is not helpful when you want full control over those fields in a single convenient area).
Note: If you later regenerate the designer.cs files again for your project by selecting your project in VS, then in the top menu choosing Project > "Convert to web Application" those designer.cs files will get recreated, BUT Visual Studio will ONLY place references to missing web controls in them that are NOT now added to your main .cs partial class page. In other words, any references I copied and added above to my index.aspx.cs partial class file would not be recreated in the new designer.cs file. So there is no conflict with the Web Application model you are using. When you see those designer files, you can now have developers safely copy them into your main code behind .cs files and safely delete the designers if you like.
You're dealing with a web application rather than a website (clarification)
Yes, in the context of a web application, you do need them.
The real "answer" is for MS to simply allow you to not use them.
I've seen lots of posts about the Inherits Attribute, and the Parser Error "Could not load type"
I can get this working by putting "RootNamespace.PageName" for a specific page, where RootNamespace matches the Root namespace in my project properites.
But I would rather not put the namespace in there. i.e. I would rather put "PageName" than "Namespace.PageName".
I have a library project with a few DLLs and 10 or so .aspx and .ascx files.
To get an update of my library project, other projects in my company copy the DLLs in and then copy the .aspx and .ascx files into a specific folder in their project.
Only problem is every time they copy they have to change the Namespace of the inherits attribute to match the root namesapce in their project.
If they don't do this, they get no compiler errors but just get a Parser error when they hit the libary .aspx and .ascx files.
This is very annoying, it seems very ridiculous that so many pages will not work if the project root namespace changes.
Does anybody have any ideas on how I can make library pages and user controls for nuse withing other peoples projects?
Thanks,
Mike G
Ah ha! A colleague stumbled upon a way around this by accident...
OK I have a single shared "Library" project and many "normal" projects that make use of shared stuff from the Library...
1- Create a "Library" WebApplication that outputs a DLL, and put your web library code and also .ascxs and .aspx pages into the WebApplication project. 2- Reference the "Library" DLL in your "Normal" projects 3- Copy just the shared .aspx and .ascx files from "library" into the "normal" projects, but ... (important bit!) ... without the code behind
In our example we don't actually include the copied .ascx and .aspx files in the project (e.g. They're not referenced in the .vbproj file) and they don't get put in source control, they just get copied in from the library every time you build. We haven't experimented with what happens if you tell the project about the .aspx and .ascx files but they definitely load OK at run time.
So it does actually make sense no I think ab out it.
Basically the root namespace of the .aspx files is unachanged it's just refers to classes in the referenced library DLL so it all works.
I have a website that has 2 files as follows:
page.aspx
page.aspx.cs
It used to be that I could just drop new files onto the web server and IIS would automatically compile the files and I could access the page e.g.
http://www.website.com/page.aspx
... and the associated functionality in the page class contained in the .cs file would work nicely.
Now I get the error: "Could not load type namespace.classname" which refers to my page class.
Now for some strange reason I have to put all my .cs files, even page classes into the app_code folder.
All that has changed on my website is that I reorganised the structure so that instead of my pages being on the web root they are now inside http://.../newfolder/page.aspx.
For some reason all my page.aspx.cs files now have to be in app_code.
Any ideas?
Sounds like you are mixing up a Web Application Project and a Web Site.
Are you sure the files are exactly the same? Perhaps one #Page directive says CodeBehind=Page.aspx.cs and the other says CodeFile=Page.aspx.cs?
CodeBehind requires project compilation, so you cannot just drop in a new .cs file, you need to upload a new compiled DLL. CodeFile will allow dynamic compilation.
The App_Code directory is dynamically compiled (in both cases) when your app is accessed, so the Inherit directive has a valid type when you put the file there. In general, don't do this. You want the .cs file to go with the .aspx file. Use App_Code for business logic or utility classes that aren't associated with a particular page.
Finally, is this new subdirectory set up as a new app in IIS? What does the web.config file in your new directory change? Are you running the same version of ASP.NET? Check the "compilation" tag. I'm not sure what you could do there to cause this, but I'm sure you could cause some chaos.
Let me try to ask this question from a different angle.
I noticed that everytime an aspx page gets rendered in the browser using the "web site" model, a random assembly gets created 'on-the-fly' in the Temporary ASP.NET files. Analyzing the assembly in Reflector shows that the class created for any given .aspx file is under the "ASP" namespace.
So, starting with a empty "Temporary ASP.NET Files" directory, I opened my ASP.NET "website" in VS2008, and launched the default page. Immediately I observed that a random directory was generated inside that folder. Working my way down the path, I found 2 DLLs created: App_Code.1lywsqqz.dll, and App_Web_iohekame.dll. I assume that all the .aspx pages in the website get compiled into App_Web dll and everything in App_Code folder gets compiled into App_Code.dll.
So if my App_Code C#/VB.net files are under the "ASP" namespace, and my App_Web files are created under the "ASP" namespace, how come I still get an error "Could not load type 'ASP.NothwindDataContext'?
Somebody said "you don't need namespaces in the App_Code folder", but I tried it without and still get "Could not load type 'NorthwindDataContext'".
So what's going on between the App_Code folder, the rest of the site, and namespaces?
EDIT:
Here's my LinqDataSource in my .aspx file:
<asp:LinqDataSource ID="LinqDataSource1" runat="server"
ContextTypeName="NothwindDataContext" EnableUpdate="True"
TableName="Categories">
</asp:LinqDataSource>
Neither "NorthwindDataContext", nor "ASP.NorthwindDataContext" works.
Types in App_Code C# source files, just like any C# file, will not be put in a specific namespace unless specifically declared by namespace Name {...} around it. So a class MyClass declared in App_Code will have the fully qualified type name MyClass. Just that.
You can reference it in Web.config as: "MyClass, App_Code".
Side note: When you are using a DBML in App_Code, the namespace of generated classes are defined in that file (look at the properties window when DBML file is open). If you specify a namespace in that file, naturally, your classes will be defined in that namespace. Note that this does not contradict with what I said above. The thing is, the LINQ data context generator processes the file and defines the classes in the specific namespace.