Command Line Compilation - Inherits

  • Thread starter Thread starter Todd A
  • Start date Start date
T

Todd A

If I use the following in my code behind page:

Public Class _Default
Inherits System.Web.UI.Page

The page will compile with no errors from the command line compiler
(vbc.exe)

But, If I insert my own base page to inherit from, say,

Public Class _Default
Inherits BaseWebPage

I am unable to get the code to compile, even if I compile BaseWebPage first
and make a reference to it.
Do I have to include the code for BaseWebPage with every page that wants to
inherit it?
I've tried a number of things here, but have been unsuccessful.

Thank you,

Todd
 
Todd said:
If I use the following in my code behind page:

Public Class _Default
Inherits System.Web.UI.Page

The page will compile with no errors from the command line compiler
(vbc.exe)

But, If I insert my own base page to inherit from, say,

Public Class _Default
Inherits BaseWebPage

I am unable to get the code to compile, even if I compile BaseWebPage first
and make a reference to it.
Do I have to include the code for BaseWebPage with every page that wants to
inherit it?
I've tried a number of things here, but have been unsuccessful.

Are you sure that the name of your class is simply "BaseWebPage"?
usually classes - even your custom coded ones - are somewhere in a
namespace hierarchy.

If you're not sure, run ildasm on the assembly that contains the
BaseWebPage class - it'll show you the namespace (if there is one).

Remember that if you're creating your class using VB.NET the namespace
that it will reside in does not have to come from the source file - the
compiler has a command line option "/rootnamespace" which can specify
one. VS.NET VB projects default the rootnamespace to the name of the
project.
 
MIke,
Good point.
I am using a response file, and in the file, I specify my namespace with
/rootnamespace:
Here is a real sample:

/target:Library
/out:"C:\Inetpub\wwwroot\stpaulmoms\bin\_Default.dll"
/rootnamespace:StPaulMoms
/optimize+
/reference:"System.dll","System.Data.dll","System.Drawing.dll","System.Web.d
ll","System.Xml.dll","System.Design.dll","C:\Inetpub\wwwroot\stpaulmoms\bin\
DAL.dll","C:\Inetpub\wwwroot\stpaulmoms\bin\StPaulMomsMB.dll"
/Imports:Microsoft.VisualBasic,System,System.Collections,System.Configuratio
n,System.Data,System.Drawing,System.Web,System.Web.UI,System.Web.UI.HtmlCont
rols,System.Web.UI.WebControls
/res:"C:\Inetpub\wwwroot\stpaulmoms\StPaulMoms.Default.resources"
"C:\Inetpub\wwwroot\stpaulmoms\Default.aspx.vb"

My goal is to give each web page their own DLL. That's why I'm deviating
from the VS.NET Model of building my assemblies.
If my BaseWebPage class (It is named BaseWebPage), which all my web pages
inherit from, is just a stand alone compiled DLL, how can I compile one
class that inherits from a class inside an already compiled dll?

Thanks,
Todd
 
Todd said:
MIke,
Good point.
I am using a response file, and in the file, I specify my namespace with
/rootnamespace:
Here is a real sample:

/target:Library
/out:"C:\Inetpub\wwwroot\stpaulmoms\bin\_Default.dll"
/rootnamespace:StPaulMoms
/optimize+
/reference:"System.dll","System.Data.dll","System.Drawing.dll","System.Web.d
ll","System.Xml.dll","System.Design.dll","C:\Inetpub\wwwroot\stpaulmoms\bin\
DAL.dll","C:\Inetpub\wwwroot\stpaulmoms\bin\StPaulMomsMB.dll"
/Imports:Microsoft.VisualBasic,System,System.Collections,System.Configuratio
n,System.Data,System.Drawing,System.Web,System.Web.UI,System.Web.UI.HtmlCont
rols,System.Web.UI.WebControls
/res:"C:\Inetpub\wwwroot\stpaulmoms\StPaulMoms.Default.resources"
"C:\Inetpub\wwwroot\stpaulmoms\Default.aspx.vb"

I assume that this is the response file used to compile the codebehind page.

I think what we need to look at is the response file and command line
used to build whatever assembly the BaseWebPage class resides in. I
assume it's either DAL.dll or StPaulMomsMB.dll since those are the only
non-framework assemblies referenced above.
 
Thanks Mike,
That did the trick.

I've been away from technology for awhile, so this response is late.

Here's one more question if you have time:

What about vb files that are just MODULES and not classes?
Example: abc.dll is an assembly that has nothing but a public module in it.
xyz.dll fails on compilation when code in xyz is referencing code in abc.
Even though I include the reference to abc.dll when I try to compile
xyz.dll, it fails. Is there something special I should know about
compileing modules and referencing them?

Thanks

Todd
 
Todd said:
Thanks Mike,
That did the trick.

I've been away from technology for awhile, so this response is late.

Here's one more question if you have time:

What about vb files that are just MODULES and not classes?
Example: abc.dll is an assembly that has nothing but a public module in it.
xyz.dll fails on compilation when code in xyz is referencing code in abc.
Even though I include the reference to abc.dll when I try to compile
xyz.dll, it fails. Is there something special I should know about
compileing modules and referencing them?

I'm not a VB.NET expert, but as far as I know, VB.NET Modules are simply
a way to provide something like global variables and non-class-based
functions.

Members of a module are accessible within a namespace without specifying
the name of the module - you would still have to import the namespace
containing the module (or specify the namespace explicitly).

So if you have a something like:

namespace NS1
public module ModuleX
sub test( s as string)
Console.WriteLine( "Inside NS1.ModuleX.test")
end sub
end module
end namespace

The test() subroutine can be called using any of the following:

NS1.test( "x")
NS1.ModuleX.test( "x")
test("x") ' only if there's an "imports NS1" statement

Remember that even when compiling assemblies that contain VB.NET
Modules, the Module might be a member of a namespace by virtue of a
compiler option - just like when compiling a class.

Personally, I think that the namespace a type resides in should be
specified in the source code and that it is a mistake for the VB.NET
compiler to have that option. But it does, and your build environment
needs to take it into account.
 
Thanks again Mike,
After tinkering a bit with what you suggested, I found that my module wasn't
declared Public. If you don't stipulate either Public or Private, the
module will default to Private. This was causing the problem.

That was the last piece to my puzzle. Thanks again.

-Todd
 
Back
Top