What is the common methjod of doing this in C# 
Author Message
 What is the common methjod of doing this in C#

Hi y'all,

Ok, a simple one.  I have an abstract base class which is going to be used
to derive classes in different slightly related projects.  In C++, this
abstract definition would be distributed across the projects via a .h file.
In C#, the equivalent method would be to add an existing file containing the
abstract base to each project via a link.  Is this the technique generally
employed or is there a beter way?

Thanx,
Bill



Sat, 21 May 2005 08:08:38 GMT  
 What is the common methjod of doing this in C#
I'd add the abstract base class to a separate library project and reference
it from the others.  When you copy files like that, it's too easy for one of
them to get out of whack during development.

Joe

--
Joe Mayo, Author - C# Unleashed
http://www.amazon.com/exec/obidos/ASIN/067232122X/cstati

http://www.csharp-station.com


Quote:
> Hi y'all,

> Ok, a simple one.  I have an abstract base class which is going to be used
> to derive classes in different slightly related projects.  In C++, this
> abstract definition would be distributed across the projects via a .h
file.
> In C#, the equivalent method would be to add an existing file containing
the
> abstract base to each project via a link.  Is this the technique generally
> employed or is there a beter way?

> Thanx,
> Bill



Sat, 21 May 2005 08:27:22 GMT  
 What is the common methjod of doing this in C#
Joe,

Regarding the link to which I referred, when you add an existing item to a
project and click on the down arrow on the Open button, there is a link
option which links to a file rather than copying it.

I'd rather not have a dll generated for every abstract class - that's what a
library produces.  Or is a class library not really a dll but rather a
library?  After all, it seems strange to have an abstract class dll.  Or, as
I asked, is this the preferred method of sharing an abstract class.

Thanx,
Bill



Sat, 21 May 2005 09:48:48 GMT  
 What is the common methjod of doing this in C#
My bad for misreading your post.  Since I haven't done it that way, I can't
comment much.  However, I do have a few thoughts on the subject.  To play
devil's advocate a bit, here's a scenario to think about.  Say you have
derived classes D1 and D2 in separate projects, P1 and P2 respectively.
They both derive from abstract class A, whose class file is linked to their
projects.

1.  Where does A physically reside?
2.  Later, add derived class D3 in a new project P3.  Then link file
containing A to project P3.  Can you remember the physical location of A?
3.  Add more abstract classes and interfaces to the solution.  Where do they
physically reside and what plan do you have to put in place to find them?

I'm sure you could make it work if you have a plan and are consistent.

The easiest solution, if practical, is having all related classes, derived
and abstract, in the same library.  However, sometimes size and logic
dictate a physical separation, which it sounds like you have.

I have a similar situation the the solution I'm working on now.  There are
different libraries that share the same base classes and interfaces.  It
doesn't make sense to put these common types into one library or the other,
so I created a utilities class for all the cats and dogs that are used in
numerous places and don't specifically belong anywhere else.  The grouping
helps reduce the number of projects, but keeps logically related types in
the same place.  The additional DLLs and copies are a necessary evil with
the current VS.NET project management system.  My current solution contains
about 32 projects and this seems to be working for me without any problems.

This is simply one way to do it - I would be interested in hearing how other
people have handled this problem also.

Joe

--
Joe Mayo, Author - C# Unleashed
http://www.amazon.com/exec/obidos/ASIN/067232122X/cstati

http://www.csharp-station.com


Quote:
> Joe,

> Regarding the link to which I referred, when you add an existing item to a
> project and click on the down arrow on the Open button, there is a link
> option which links to a file rather than copying it.

> I'd rather not have a dll generated for every abstract class - that's what
a
> library produces.  Or is a class library not really a dll but rather a
> library?  After all, it seems strange to have an abstract class dll.  Or,
as
> I asked, is this the preferred method of sharing an abstract class.

> Thanx,
> Bill



Sat, 21 May 2005 11:37:07 GMT  
 What is the common methjod of doing this in C#
Hi again Joe,

Seems to me that the C++ way was neater.  I'll probably go with the class
library but ecstatically, having a dll comprised of abstract base classes
seems wierd.  I suppose that the dll, in this case, consists of those
methods that are not virtual.  But...

I just had a thought - how would I go about defining an interface instead of
a class?  If I converted my base class into an interface, there would not be
any associated code...   A class library would not make any sense since it
would not have any associated code.

There are ways to do this, someone out there must know what the common
technique is!

Thanx,
Bill



Sat, 21 May 2005 12:26:03 GMT  
 What is the common methjod of doing this in C#

Quote:
> I just had a thought - how would I go about defining an interface instead
of
> a class?  If I converted my base class into an interface, there would not
be
> any associated code...   A class library would not make any sense since it
> would not have any associated code.

I was about to reply the same thing.  I would create an interface, and put
that in its own assembly.  That works well.  The downside is that you need
to deploy the DLL with your application.

Abstract base classes with pure virtual functions in C++ are really just
interface definitions.  Now you can really declare it as such in C#.

-- Alan



Sat, 21 May 2005 23:57:36 GMT  
 What is the common methjod of doing this in C#


Wed, 18 Jun 1902 08:00:00 GMT  
 What is the common methjod of doing this in C#
Hi y'all,

I still haven't gotten a definitive answer to what I throught was a trivial
question.  Here is my problem:

I have multiple provisioning systems, P1, P2 and P3, each one very distinct
from the other.  However, each Pn saves a subset of its data in separate
database tables that are processed by an analysis system, A1.  To make this
data accessible, P1, P2 and P3 each derive from interface I1 as does A1.
The result is that P1, P2 and P3 store data with an I1 interface which is
then read an analyzed by A1 using the I1 interface.

P1, P2 and P3 are not related except via the analyzed database data.  If I
was using C++, the I1 interface would be declared in a .h include file and
incorporated into each processing module.

It now seems to me that the best way to do this in VS C# is to mimic the C++
include capability by adding an existing .cs file to a project via the
open/link option.  This way I don't have assemblies floating around that
consist of interface definitions only, nor do I have dlls coming out the
kazoo for every piece of code that is shared.

My impression of C# was that it had some method of doing this which was
efficient and orderly.  dlls and assemblies shared across multiple projects
seems a lot more confusing to me that my proposed solution.  Is there a
prefered way of achieving this end without the confusion I envision?

Thanx,
Bill



Sun, 22 May 2005 02:27:49 GMT  
 What is the common methjod of doing this in C#
I'm afraid I don't think there is an option beyond the linking in Visual
Studio (at least not one that wouldn't take more than a bit of effort).  I
gather from your posts you don't like that option.

As I see it, you can:
- Link, as you currently are.
- Build modules for each piece of code and add them into a single assembly
(dll), adding new ones as necessary. I don't think VS.NET supports building
modules, only the command-line compiler through the /target:module switch -
though I could be wrong about that.
- Build cusom VS.NET macros/add-in that somehow added include-like behavior,
though this would take some significant effort.

Richard


Quote:
> Hi y'all,

> I still haven't gotten a definitive answer to what I throught was a
trivial
> question.  Here is my problem:

> I have multiple provisioning systems, P1, P2 and P3, each one very
distinct
> from the other.  However, each Pn saves a subset of its data in separate
> database tables that are processed by an analysis system, A1.  To make
this
> data accessible, P1, P2 and P3 each derive from interface I1 as does A1.
> The result is that P1, P2 and P3 store data with an I1 interface which is
> then read an analyzed by A1 using the I1 interface.

> P1, P2 and P3 are not related except via the analyzed database data.  If I
> was using C++, the I1 interface would be declared in a .h include file and
> incorporated into each processing module.

> It now seems to me that the best way to do this in VS C# is to mimic the
C++
> include capability by adding an existing .cs file to a project via the
> open/link option.  This way I don't have assemblies floating around that
> consist of interface definitions only, nor do I have dlls coming out the
> kazoo for every piece of code that is shared.

> My impression of C# was that it had some method of doing this which was
> efficient and orderly.  dlls and assemblies shared across multiple
projects
> seems a lot more confusing to me that my proposed solution.  Is there a
> prefered way of achieving this end without the confusion I envision?

> Thanx,
> Bill



Sun, 22 May 2005 03:45:20 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. C# , i am trying to create a file on the server using C#

2. System.Threading.Timer , am I doing this correctly ?

3. Wot am I doing rong??

4. Am I doing this right?

5. what am i doing wrong?

6. what am I doing wrong here?

7. What am I doing wrong?

8. What am I doing wrong?

9. WHAT AM I DOING WRONG?

10. what am i doing wrong!

11. What am I doing wrong (part 2)

12. Q: What am I doing wrong??

 

 
Powered by phpBB® Forum Software