[MonoDevelop] variables that don't exist in current context
venable.devin at gmail.com
Mon Aug 30 09:00:37 EDT 2010
Without anything more to add, I just wanted to say thank you Michael
for this good information. This is just what I was trying to get my
head around. I appreciate the explainer.
On Fri, Aug 27, 2010 at 4:23 PM, Michael Hutchinson
<m.j.hutchinson at gmail.com> wrote:
> On Fri, Aug 27, 2010 at 3:01 PM, Devin Venable <venable.devin at gmail.com> wrote:
>> I'm porting an ASP.NET project on Windows to mono/Linux in
>> MonoDevelop. I'm still a newbie when it comes to ASP.NET.
>> On Windows, the project was a "web site" and I'm making it a "web
>> application" by importing everything into an empty project.
>> For each aspx file (web template) there is one ascs.cs file (the
>> associated code).
>> For every field that is in the aspx like this:
>> <asp:RequiredFieldValidator ID="rfvQ1" runat="server"
>> Display="Dynamic" ErrorMessage="Required.<br>" InitialValue="
>> <asp:DropDownList ID="ddlQuestion1" runat="server">
>> There is a reference in the c# like this where it is used:
>> rfvAnswer1.ErrorMessage = msgRequired;
>> The problem: When I compile I get:
>> Error CS0103: The name `rfvAnswer1' does not exist in the current
>> context (CS0103) (GTPCard)
>> It's because the rfvAnswer variable hasn't been explicitly declared.
>> If I add a protected member to the class like this:
>> protected System.Web.UI.WebControls.RequiredFieldValidator rfvAnswer1;
>> ...the error goes away.
>> The question is WHY am I having to do this over and over again for
>> every reference? Is there a reference I can include, or a way to
>> configure the project so that the variables are automatically created?
>> I assume something must be happening like this on the Windows/Visual
>> Studio side, since there the project source doesn't have these
>> variables explicitly created.
> This is down to the difference between the CodeBehind models used by
> Web Sites and Web Applications.
> Web Sites are intended to be compiled fully on the server. In
> contrast, Web Applications have a project that is compiled by the IDE.
> Hence, the CodeBehind classes in Web Sites are compiled into
> individual assemblies on the fly, while CodeBehind classes in Web
> Applications are usually compiled into a single assembly by the IDE.
> Each as[pchm]x file is compile to a class by the ASP.NET server. The
> class that it subclasses is called the "CodeBehind" class, and can be
> specified by the Inherits attribute in the page directive. CodeBehind
> classes can access controls defined in their subclasses because if
> there is protected/public field/property in the base class with the
> same name as the control's IDE, the control instance will be assigned
> to that. You can define these members manually in the CodeBehind
> class, or use the IDE or server's ability to autogenerate partial
> classes with these members which can then be compiled together with
> the CodeBehind class.
> If the Page directive has a CodeFile="Foo.aspx.cs" attribute, then
> when the ASP.NET server compiles the aspx file it will also generate a
> partial class and compile it together with the Foo.aspx.cs. You can
> use this CodeBehind compilation model in a Web Application project,
> but beware that you must set the Foo.aspx file's build action to
> "Content", not "Compile". Also, MonoDevelop will provide only limited
> or inaccurate code completion for this model.
> If there is no CodeFile attribute, the server tries to find the
> CodeBehind class in the assemblies in the app's bin folder. This means
> it will find any classes that have been compiled by the IDE, i.e. with
> Compile build actions. Both VS and MD can assist this model - if there
> is a class called Foo.aspx.designer.cs beside the Foo.aspx file, then
> the IDE will generate the partial class in the "designer file"
> whenever the aspx file is saved.
> Also look out for the App_Code folder - this is also intended for use
> with Web Sites, since the server compiles all code in this folder, so
> if you use it in Web Application project you must also set the build
> action of these files to "Content" not "Compile" or you will get
> duplicate type conflicts.
> Michael Hutchinson
More information about the Monodevelop-list