Referencing a type w/o included source?

[Brett Romero]

Say I have a library (A.dll) with a method that accepts a collection of
a specific type. The type is defined in B.dll. In A.dll, I need to
loop through this collection and reference fields of the type.

For example, a Person type. It may have arm, leg, feet, and hands.
Hands is a collection containing types of fingers. The only way to get
at fingers is by accepting the parameter as its true type. This means
I'll need a file reference to B.dll so I can declare a variable of type
Person to hold the Person parameter coming in.

Is there a way to do this without including B.dll? I want A.dll to be
stand alone. Referencing B.dll means any application that uses A.dll
will need to drag around B.dll as well. Also, if the application is
already referencing B.dll, that means I'm redundant once the reference
to A.dll is made (since it is too referencing B.dll).

Some one may say to use an interface here. Just have all of the B.dlls
implement the interface. Any other library such as the application or
A.dll will reference the interface, which is a conduit to all of the
B+.dll libraries. That doesn't work either because if the application
is referencing the interface already and then includes A.dll, which
also references the interface, I'm still including the interface twice.

Is this good logic or am I mistaken in my thinking on it? Is there a
way to get at the type or specifically, something in the type without
declaring the type in A.dll? Does .NET 2.0 offer anything for this?

Thanks,
Brett

 

[Steven Nagy]

Could you declare a class in A that inherits from the class in B and
make the A class be the instances in the collections?
That way the target app only needs to reference A, getting A.Class
instead of B.class.

There's also the whole partial class concept that I am not all over
yet. Perhaps it would work.. its a 2.0 thing I think, where you can
declare a partial class in your B.dll and then in your A.dll add some
minor functionality, or even none at all, but this might still make the
class be part of the new A.dll.
Sorry I can't test it right now. Perhaps one of these MCPs, MCSDs,
MCADs, UFOs, etc who frequent this forum can expand on the partial
class concept.

Steve

 

[C.C. \(aka Me\)]

I think you are out of luck in terms of not having to include both files..

An easy way to look at it is:

If you want to create an instance of _any_ object type you need to reference
the assembly that includes that code and that assembly needs to be available
on the clients machine in order to run.

I wouldnt worry about "multiple" references either because it wont make your
application any bigger - it just informs .NET what assemblies you need in
order to work.

Hope this helps!

 

[Brett Romero]

A.dll is a utility file and really shouldn't include any of custom
types. That's probably how I should think of it and avoid trying to
figure out how to use a custom type in A.dll when it shouldn't be doing
anything with a custom type.

A.dll has an extended data grid control. I want to take in a
collection of a specific type and update a particular item in the
collection when some one updates a row on the grid. I can do all of
this in the calling form. I just wanted to completely abstract it into
the data grid, since this is a grid thing.

It starts getting very complicated. I'd also need a way to get at
fields in the collection. Also, other types will use the custom data
grid. A.dll would have to know all of those types. In the end, I'm
trying to make the custom data grid to specific when it should be very
generic. I start getting into IFs or Switches or multiple methods will
very similar code.

I'll leave the code in the application calling the grid. It can do all
of the specific work in the particular form. This way, the custom data
grid does not need to know anything about custom types. It can still
extend its row update event to the form, which will subscribe to that
event.

Hmmm, good for now I suppose.

Brett

 

[Jon Skeet [C# MVP]]

Say I have a library (A.dll) with a method that accepts a collection of
a specific type. The type is defined in B.dll. In A.dll, I need to
loop through this collection and reference fields of the type.

For example, a Person type. It may have arm, leg, feet, and hands.
Hands is a collection containing types of fingers. The only way to get
at fingers is by accepting the parameter as its true type. This means
I'll need a file reference to B.dll so I can declare a variable of type
Person to hold the Person parameter coming in.

Is there a way to do this without including B.dll? I want A.dll to be
stand alone.

In that case you logically *can't* have it referencing a type defined
in B.dll. It just wouldn't make sense.

Referencing B.dll means any application that uses A.dll
will need to drag around B.dll as well. Also, if the application is
already referencing B.dll, that means I'm redundant once the reference
to A.dll is made (since it is too referencing B.dll).

Some one may say to use an interface here. Just have all of the B.dlls
implement the interface. Any other library such as the application or
A.dll will reference the interface, which is a conduit to all of the
B+.dll libraries. That doesn't work either because if the application
is referencing the interface already and then includes A.dll, which
also references the interface, I'm still including the interface twice.

If you only have the interface declared in one place, it shouldn't
matter how many times you add references to it.

Jon

 

[Jon Skeet [C# MVP]]

A.dll is a utility file and really shouldn't include any of custom
types. That's probably how I should think of it and avoid trying to
figure out how to use a custom type in A.dll when it shouldn't be doing
anything with a custom type.

A.dll has an extended data grid control. I want to take in a
collection of a specific type and update a particular item in the
collection when some one updates a row on the grid. I can do all of
this in the calling form. I just wanted to completely abstract it into
the data grid, since this is a grid thing.

Are you using .NET 2.0? If so, the obvious solution would be to use
generics. If you need to do anything "to" the objects you're provided
with, include an interface and make that a constraint on the type.
Otherwise, just make it a CustomDataGrid<T> and you should be away.

Jon

 

[Brett Romero]

How does CustomDataGrid<T> help me in A.dll? Wouldn't I still have to
this back to Person to reach all of its inner workings?

Thanks,
Brett

 

[Jon Skeet [C# MVP]]

How does CustomDataGrid<T> help me in A.dll? Wouldn't I still have to
this back to Person to reach all of its inner workings?

You haven't really said what the type in A.dll needs to do. If it just
needs to hold references to instances of Person and expose them in a
strongly typed way, generics is perfect. If it needs to do other
things, you could include an interface (in A) which Person implemented,
and then constrain the parameterised type to implement that interface.

Jon

 

[Brett Romero]

The Person type that is passed into A.dll as a generic (hopefully)
contains an address collection. I may actually pass in the Person
collection, which contains person objects. Each address object in the
address collection of a Person object contains fields (address, city,
state, zip). Would I be able to access
PersonCollection[1].address[1].city in A.dll for example if the
PersonCollection type came in as a generic? How would that look in
code (caller and recipient)?

Thanks,
Brett

 

[Jon Skeet [C# MVP]]

The Person type that is passed into A.dll as a generic (hopefully)
contains an address collection. I may actually pass in the Person
collection, which contains person objects. Each address object in the
address collection of a Person object contains fields (address, city,
state, zip). Would I be able to access
PersonCollection[1].address[1].city in A.dll for example if the
PersonCollection type came in as a generic? How would that look in
code (caller and recipient)?

If the collection were actually MyCollection<Person> (as created by B,
using MyCollection<T> from A, then as far as B were concerned it would
be returning Person in a strongly-typed way. If the collection class in
A.dll needs to do that indexing and look at the address, then I'd
suggest it's not a good candidate for being in a general purpose
library in the first place.

Have a look at List<T> for examples, and try creating (say) a
List<Stream> - the indexer will return a Stream, strongly-typed, so you
could do list[0].Read(...) with no problems. Apply the same to your own
collection and your own element type and I believe that solves your
concerns.

Jon