We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now

x

VS.NET 2003 keeps adding "Inherits" attribute to ASP.NET 1.1 page directives whenever changes are made, causing parser errors

tcbdata
tcbdata asked
on
Medium Priority
394 Views
Last Modified: 2008-03-10
I'm new to ASP.NET.  We are working on a project for a server running ASP.Net 1.1 and we are using Visual Studio.NET 2003 for development.  Every time I make a new .aspx web form, or make changes to an existing form, VS.NET automatically adds an "Inherits=" attribute that points to the current page.  However, when the form is run, an "Parser Error" occurs.  Take this sample page directive for an imaginary "page_name.aspx" web form of an imaginary application "my_app" in the "/current_folder/" path for example:

<%@ Page language="c#" Codebehind="page_name.aspx.cs" AutoEventWireup="false" Inherits="my_app.current_folder.page_name" %>

Accessing the form results in the following error:

Parser Error Message: Could not load type 'my_app.current_folder.page_name'.

What's interesting is that the directory structure is included in the auto-inherited class.  For example, the page in question might exist in:

d:\inetpub\wwwroot\current_folder\page_name.aspx

and this is reflected in the Solution Explorer accordingly.  ***When this "Inherits" attribute is deleted, the form runs properly.***  But any time I add a control or make a change to the code behind file and save it, VS.NET just puts the Inherits attribute back in the directive, causing an error.  You can imagine how incredibly annoying it is to have to manually delete this automatically generated code each and every time I make a change.  I found the following topic that supports the solution of removing the "Inherits" attribute of the page directive:

http://www.experts-exchange.com/Programming/Programming_Languages/Dot_Net/ASP_DOT_NET/Q_21701232.html

But the topic does nothing to explain the behavior or how to stop it from being automatically generated, and the article linked within it (http://www.codeguru.com/Csharp/.NET/net_general/code-behind/article.php/c4637/) is useless as well.  Is there any way to turn off this ridiculous behavior?  Or is there something I need to do to the project globally to make the "Inherits" attribute actually work?
Comment
Watch Question

Commented:
Hi there,

Have you been remembering to BUILD the application after each change?  If you have C# code attached to the page, the Inherits attribute is required.  But it looks like the "My_App.dll" assembly is not in the bin\ folder of the application.  If it is not, in VS you should choose the "Build Solution" option from the Build menu and copy the bin\ folder to the server you're attempting to test with.
CERTIFIED EXPERT
Most Valuable Expert 2012
Top Expert 2008

Commented:
If you have a mix of namespaces, then you will get this type of problem.

Bob

Author

Commented:
Well, the solution won't even build at this point...but mostly due to client-side errors that VS.NET is catching (unknown CSS properties and such).  But even so, having to build the solution any time a make a minor change is made seems like overkill.  Even when I create a whole new blank solution and test project, I encounter the same problem!

Could you be more specific about a "mix" of namespaces?  I have not made any new namespaces, but VS.NET seems to be declaring them automatically in all code-behind pages.  For example, if my application name is "appname", the first line of every auto-generated code-behind after the standard "using" lines is:

namespace appname {

and then the auto-generated classes are contained inside.  While I'm new to C# and .NET, it seems to me that it's explicitly declaring the namespace "appname", and thus the aspx should see this namespace and be happy.  No?

My guess is that the problem is with our environment.  Like I said, even a new blank project exhibits this issue.
CERTIFIED EXPERT
Most Valuable Expert 2012
Top Expert 2008

Commented:
If you right-click on the project in the Solution Explorer, you will see a property--Default namespace.  If you haven't changed this, then all new pages, classes, etc., that are created for the project will be assigned to the same namespace.

How many projects do you have within your solution?

Bob

Author

Commented:
Well, I technically have two projects in the solution.  One is a simple data utility to access our database.  The other one is the web project itself.  The "Default Namespace" was automatically populated with the application name already...the same name that it keeps trying to "Inherit".  I cleared this property and tried again, and it still adds the "Inherits" attribute to the page directive with the same namespace!
CERTIFIED EXPERT
Most Valuable Expert 2012
Top Expert 2008
Commented:
Ah, yes, the headaches of 1.1--2.0 doesn't do this, and I am not sure how to work around it.  I thought it might be a simple namespace conflict.

Bob

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Author

Commented:
We decided to upgrade to .NET Framework 2.0, and sure enough it seems to work!  Not only is VS.NET not adding the inherits attribute when changes are mode to the code-behind C# file, but the pages that DO have it in there don't generate an error anymore.  Thanks, Bob.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.