Inheritance and assembly references in multilayerd solution

[Brad]

I have one of those seemingly simple questions that evades/confuses me.
I've created an assembly with bass classes (classes meant to be inherited in
other assemblys). In a secondary assembly (my business layer) I created a
class which inherits from a base class in the first assembly....so far so
good.

If I create a third assembly (my UI layer) and add reference in it to the
business layer and I access a public variable in the business layer...and
that variable is from the bass class I get an error in the UI like

'<name>' is declared in project '<projectname1>', which is not referenced by
project '<projectname2>'

To resolve this I have to add a reference in the UI to the base class so the
UI assembly now has a reference to the base class *and* the inherited class.
My question is: Why? I wouldn't have expected to need a reference to the
base class.....I would think the UI wouldn't have to know anything about the
base class.
Oddly enough even though there is an error message and the UI assembly won't
compile (without a ref to the base class) intellitype still shows me all the
base class public members and interfaces that are in the inherited class.


Example:
=========================
Assembly A

Public Class MyAClass
Public var1 as string
End Class
==========================
Assembly B (which references A)
Public Class MyBClass: Inherits MyAClass
End Class
==========================
Assembly C (which references B)

B.MyBClass.var1

Error Message is:
"var1 is declared in project A.dll which is not referenced by project C.dll"

But even with error intellitype shows .var1



Thanks

Brad

 

[Jay B. Harlow [MVP - Outlook]]

Brad,

To resolve this I have to add a reference in the UI to the base class so the
UI assembly now has a reference to the base class *and* the inherited class.
My question is: Why? I wouldn't have expected to need a reference to the
base class.....I would think the UI wouldn't have to know anything about the
base class.

Unfortunately its the way the references work, as best as I can tell the
inherited class does not include all the meta data of the base class
assembly (as it can change). Hence the need to reference both assemblies.

I think we could have more problems if the inherited class's assembly did
include all the meta data of the base class assembly, as we would definately
have code bloat & what happens when the base class assembly changes?

Hope this helps
Jay

 

[Peter Huang [MSFT]]

Hi Brad,

Every managed module contains metadata tables. There are two main types of
tables: tables that describe the types and members defined in your source
code and tables that describe the types and members referenced by your
source code.

IntelliSense is one of the functions of metadata tables.
Visual Studio .NET uses metadata to help you write code. Its IntelliSense
feature
parses metadata to tell you what methods a type offers and what parameters
that
method expects.

AssemblyRef metadata table is one of metadata tables.

AssemblyRef
Contains one entry for each assembly referenced by the module. Each entry
includes the information necessary to bind to the assembly: the assembly¡¯s
name (without
path and extension), version number, culture, and public key token
(normally a small hash value, generated from the publisher¡¯s public key,
identifying the referenced
assembly¡¯s publisher). Each entry also contains some flags and a hash
value. This hash value was intended to be a checksum of the referenced
assembly¡¯s bits. The CLR completely ignores this hash value and will
probably continue to do so in the future.

You may try to observe the metadata tables of the three assemblies(A,B and
C, you mention in your post) using the tool ildasm.
It can be found in the path below.
<Microsoft Visual Studio .NET 2003>\SDK\v1.1\Bin\ildasm.exe
Viewing Assembly Contents
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconusingildasmexetoviewassemblycontents.asp

For detailed information, you may refer to the book witten by Jeffrey
Richter.
Applied Microsoft .NET Framework Programming
Microsoft is providing this information of recommendation of the book as a
convenience to you with no warranties.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
--------------------