Exposing internal members of an assembly

[mmkhajah]

Hi,

I am trying to have a set of base classes and interfaces of an
application framework in their own assembly. That way, concrete
implementations of the API will reference that assembly and implement
the abstract classes and interfaces.

The problem is that some parts of the API are "internal" in the sense
that they are internal to the implementation. If I declare these parts
as internal in the API, the implementations will not be able to access
them.

The reason behind using "internal" members is to eliminate the need for
the proxy design pattern so I can pass objects between the implemation
and the GUI directly whilst ensuring that the appropriate access levels
are maintained.

Any thoughts?

Thank you,

 

[n4ixt]

In "Programming .Net Components, 2nd Edition" (O'Reilly, July 2005, ISBN
0-596-10207-0) Juval Lowy shows how to do just want you want, assuming you
are in C# 2.0 (2005).

Section 2.2.8 of his book talks about a new attribute called
InteralsVisibleTo. In the AssemblyInfo.cs file, add this attribute:

[assembly: InternalsVisibleTo("YourDllOrExe")]

Any clients in the assemblies YourDllOrExe.EXE or YourDllOrExe.DLL will be
able to use any classes in your original dll and call both public and
internal members.

Haven't tried this yet myself, just happened to read about it last night so
it was good timing. It's more meant for situations where for whatever reason
a team decides to break a single DLL into multiple DLLs but parts in
different DLLs rely on internal members from the original.

Personally I think you ought to think about your design a bit, as you are
essentially exposing internal members and circumventing the whole of idea of
it being internal, but if you insist, well above is a way to do it.

Robert

 

[mmkhajah]

Thanks a lot for your reply. Although your solution works, the base
assembly (Framework API) must be aware of its clients which is not
really practical.

Regarding the design, the problem is that the implementation must
specify methods that are internal to itself, so its kinda weird.

I found a possible but cumbersome solution and that is to use "modules"
which are assemblies without manifests. Basically, I can make a module
and include in an assembly and the assembly would have access to the
module's internal members. The problem with this is that it can only be
done with the command line compiler. VS 2005 doesn't support it.

 

[Jon Skeet [C# MVP]]

I am trying to have a set of base classes and interfaces of an
application framework in their own assembly. That way, concrete
implementations of the API will reference that assembly and implement
the abstract classes and interfaces.

The problem is that some parts of the API are "internal" in the sense
that they are internal to the implementation. If I declare these parts
as internal in the API, the implementations will not be able to access
them.

The reason behind using "internal" members is to eliminate the need for
the proxy design pattern so I can pass objects between the implemation
and the GUI directly whilst ensuring that the appropriate access levels
are maintained.

Any thoughts?

So you want the derived classes to have access to the members in the
base classes, but you don't want other classes to have access to those
members? If so, you just need protected access.

 

[mmkhajah]

That will deny derived classes from using each other which is what the
framework is all about. The primary problem is that the framework API
will reside in a different assembly.
For example, I can use the "protected internal" access level but that
would mean that classes in the implementation will not have access to
"protected internal" members.

 

[Jon Skeet [C# MVP]]

That will deny derived classes from using each other which is what the
framework is all about.

Ah - that wasn't clear.

The primary problem is that the framework API will reside in a different
assembly.

It sounds like the members should basically be public then. Yes,
there's a risk that components which shouldn't use those members will
use them - but I suspect the risk is small in reality.