Base Class in separate assembly?

Hi,

I have orginally create a project which contained a base class, a client class and a server class. After finish the project I thought rather than having a single assembly containing these 3 classes together that I would break them down.

So I now have

one assembly for my base class
one assembly for my client class which also has a reference to my base class
one assembly for my server class which also has a reference to my base class

So far so good. No problem.

When I create a dummy winform project and I reference my client class to it, all is still ok, but when I try to access a specific class with the client class which is inherited from my base class, it will not work unless I reference the base class into the dummy project.

Why is this? Am I doing something wrong. I though all I would have had to do was to reference the client class and the base class, since reference in the client class would have been called appropriately?

Any ideas as to why this is happening. While I'm not an expert in OO, it seems to me that this would have been an ok design and rather than putting base, client and server class into the one assembly it would have been better to split them for a) size, b) security as server classes should not be accessible at any stage on the client.

The way it is now I'm left with these choices which are no good:

a) reference client assembly and base assembly into dummy project which seems completely useless as I feel there is "double" referencing since the base class is (as previously said) already referenced into the client (and server) class.

b) put back base, client and server together which again to me does not make sense.

Anyone has any ideas?

Thanks.

Thierry
tafAsked:
Who is Participating?
 
mydasxCommented:
Ok short answer no you cant.
However, Typically inheritance is meant for the same namespace besides in the final code.

Mydasx
0
 
mydasxCommented:
I'm not sure i understand... give me some code please...  simple will be fine.
0
 
mydasxCommented:
when I try to access a specific class with the client class which is inherited from my base class, it will not work unless I reference the base class into the dummy project

this is confusing...
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

 
tafAuthor Commented:
Hi,

Sorry about the confusion.

Take the example below:

project1: base.vb

Public MustInherit Class CategoryBase
   
     Protected Sub New
     End Sub

     Public Function Name as string
     End Function

End Class

project 2: client.vb (reference includes project1)

Public Class Category
   Inherits Project1.CategoryBase

   Sub New

   End Sub

   Public Function MoreInfo as string

   End Function

End Class

project3: myproject.vb (references to project2)

In a winform:

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

    Dim cat as new Project2.Category

    cat.Name = "test"

End Sub

The following error occurs on the following line: cat.Name = "test"

'Public Property Name() As String' is declared in project 'Base.dll', which is not referenced by project 'Project3'. Add a reference to 'Base.dll' to your project 'Project3'.

Please note the above may not be 100% correct but the idea is explained. I have a base class in a base.dll which is referenced in a client class in client.dll which in turns is called by a winform project (used to test) and when trying to create an object from client.dll which is inherited from the base, it generates the error above.

Any ideas?

Thanks.

T.
0
 
mydasxCommented:
the example is fine.  When organizing your assmeblies you need to think about what the end usage will be.  You will not inherit the imports statements of baseclass as seen in your example.  This creates a need to look at how to bundle things.  .net is set up for namespaces which are exactly what you are thinking is double references.  e.g. System.IO in system.IO there are lots of functionalities available to us as developers, and when you import that assembly you are importing all of system.IO.  How ever, you gain effeciency in your code by not flooding your assembly w/ that assembly by calling explicit names instead of using imports statements.  I have diverged from your answer...

Use namespaces.  Your namespace will solve your scoping problems.  Put everybody in the same namespace, and they will see each other more readily.  This should not be done w/ your windows form, it should simply import the namespace.
0
 
tafAuthor Commented:
Hi,

This is how I had it originally. I had all code for base, client and server in their respective namespace but decided it would be better to separate the client and server in separate assemblies as I thought I would be distributing uncessary information to client's workstation as they do not require any information stored in the server namespace (assembly now) and other obvious reason such as security, etc...

As for my example as I cannot go into the entire details as they are rather large namespaces containing many classes. I understand what you're saying about the system.io and while the client and the server class have a very close relation in terms of what they store and the fact that they access the same base class, but there is still issue about having all these classes together.

My biggest concern is security. For example, based on previous example i.e. category, the base class contains the categoryID property which would be required by both the client & server class, thus in my base class, but the category name in my case is a tablename in a sql server database should only be available in the server class as client should never be at any stage be able to see this information (which by the way get serialized and persisted).

While I appreciated that I could fill my client class from a client's workstation only with the relevant information to it and never fill the server class, I'd still have a concern about a client having a developer discovering the server class and attempting to fill it with the relevant information.

Also why return a larger class (as this is used with .net remoting & webservices) even if the server part would stay empty it still would contain non-needed "schema" information when serialized as the entire class would be serialized (though I'll test that tomorrow).

Without getting into to many details, my base, client and server namespace contains various classes made of classes and collections which in turns stores very specific information from 27 various tables in our database required used mostly to customise our application but some are only needed in the client with specific values based on the user credentials (espcially no field info and table info) while the server class contains absolutely every thing irrelevant.

Sorry it's my turn :), kind of got away from the point.

Is there no way for me to reference the client.dll (which is reference to the base.dll) without having to reference the based.dll within a project. I don't have a problem doing so (just a question of getting use to it I guess!) but I still feel it really defeats the purpose of inheritance (to some extend anyway!).

Thanks.

T.
0
 
tafAuthor Commented:
Hi TheLearnedOne,

Apogologies for not updating. I'll accept mydasx answer, though not what I was expecting but I guess I'll just have to accept it.

Thanks.

T.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.