exporting certain classes in assembly

[puzzlecracker]

is there a way to create a library (assembly/dll) where I can only
export few class? I don't want client to use or know about other
internal classes in the assembly.

Thanks

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: exporting certain classes in assembly

puzzlecracker wrote:

is there a way to create a library (assembly/dll) where I can only
export few class? I don't want client to use or know about other
internal classes in the assembly.

public vs internal ?

Arne

[ab2305@gmail.com]

Re: exporting certain classes in assembly

On Oct 13, 10:25 pm, Arne Vajhøj <a...@vajhoej.d kwrote:

puzzlecracker wrote:

is there a way to create a library (assembly/dll) where I can only
export few class? I don't want client to use or know about other
internal classes in the assembly.

>
public vs internal ?
>
Arne

That could cause a problem. Say my client classes reference util
classes, that I don't want to export outside, making those internal
would break my implementation.

[Peter Duniho]

Re: exporting certain classes in assembly

On Mon, 13 Oct 2008 20:14:30 -0700, <ab2305@gmail.c omwrote:

On Oct 13, 10:25 pm, Arne Vajhøj <a...@vajhoej.d kwrote:

>puzzlecracke r wrote:

is there a way to create a library (assembly/dll) where I can only
export few class? I don't want client to use or know about other
internal classes in the assembly.

>>
>public vs internal ?
>>
>Arne

>
That could cause a problem. Say my client classes reference util
classes, that I don't want to export outside, making those internal
would break my implementation.

First of all, are you the original poster? If so, please don't switch
back and forth between identities. It's hard enough to keep track of
people who use pseudonyms, without them using _multiple_ pseudonyms so
that we never know who it is we're talking to or responding to.

Second, surely Arne's talking about classes in your library, not the
client. Assuming your client isn't itself a library, accessibility of
things in the client have nothing to do with what's "exported outside",
and even if it is, it only exports what it itself declares. Just because
it references something, that doesn't cause that referenced thing to be
exposed.

There's nothing about your reply to Arne's post that makes me think that
his own response wasn't relevant or helpful. Your reply seems more like a
non sequitur to me.

As is usually the case, if you would post a concise-but-complete code
sample that illustrates whatever accessibility issue you're dealing with,
it would be a lot more likely that someone could provide some specific
advice that addresses your need.

Pete

[=?Utf-8?B?TW9ydGVuIFdlbm5ldmlrIFtDIyBNVlBd?=]

Re: exporting certain classes in assembly


"ab2305@gmail.c om" wrote:

On Oct 13, 10:25 pm, Arne Vajhøj <a...@vajhoej.d kwrote:

puzzlecracker wrote:

is there a way to create a library (assembly/dll) where I can only
export few class? I don't want client to use or know about other
internal classes in the assembly.

public vs internal ?

Arne

>
That could cause a problem. Say my client classes reference util
classes, that I don't want to export outside, making those internal
would break my implementation.
>

You can use the StrongNameIdent ityPermission to limit calling code to known
assemblies.

http://msdn.microsoft.com/en-us/library/system.security.permissions.strongnameidentitypermission.aspx

--
Happy Coding!
Morten Wennevik [C# MVP]

[puzzlecracker]

Re: exporting certain classes in assembly

On Oct 14, 1:59 am, Morten Wennevik [C# MVP]
<MortenWenne... @hotmail.comwro te:

"ab2...@gmail.c om" wrote:

On Oct 13, 10:25 pm, Arne Vajhøj <a...@vajhoej.d kwrote:

puzzlecracker wrote:
is there a way to create a library  (assembly/dll) where I can only
export few class? I don't want client to use or know about other
internal classes in the assembly.

>

public vs internal ?

>

Arne

>

That could cause a problem. Say my client classes reference util
classes, that I don't want to export outside,  making those internal
would break my implementation.

>
You can use the StrongNameIdent ityPermission to limit calling code to known
assemblies.
>
http://msdn.microsoft.com/en-us/libr....permissions.s...
>
--
Happy Coding!
Morten Wennevik [C# MVP]

Class cannot be internal, hence I would need to make constructors and
member methods to prevent internal classes from leaking to outside?

thanks

[Chris Dunaway]

Re: exporting certain classes in assembly

On Oct 14, 8:43 am, puzzlecracker <ironsel2...@gm ail.comwrote:

>
Class cannot be internal, hence I would need to make constructors and
member methods to prevent internal classes from leaking to outside?

Why not? Inside an assembly, an internal class is only visible to the
other classes in that assembly. Public classes are visible outside
the assembly.

If the client references the assembly, it can only see the public
classes. The internal classes will not be visible to it.

Could you please clarify your comment about "making constructors and
member methods to prevent internal classes from leaking to outside"?

Or could you provide a simple and complete code sample that
illustrates why you can't use internal classes?

Chris

[=?Utf-8?B?TW9ydGVuIFdlbm5ldmlrIFtDIyBNVlBd?=]

Re: exporting certain classes in assembly


"puzzlecrac ker" wrote:

On Oct 14, 1:59 am, Morten Wennevik [C# MVP]
<MortenWenne... @hotmail.comwro te:

"ab2...@gmail.c om" wrote:

On Oct 13, 10:25 pm, Arne Vajhøj <a...@vajhoej.d kwrote:
puzzlecracker wrote:
is there a way to create a library (assembly/dll) where I can only
export few class? I don't want client to use or know about other
internal classes in the assembly.

public vs internal ?

Arne

That could cause a problem. Say my client classes reference util
classes, that I don't want to export outside, making those internal
would break my implementation.

You can use the StrongNameIdent ityPermission to limit calling code to known
assemblies.

http://msdn.microsoft.com/en-us/libr....permissions.s...

--
Happy Coding!
Morten Wennevik [C# MVP]

>
Class cannot be internal, hence I would need to make constructors and
member methods to prevent internal classes from leaking to outside?
>
thanks
>

Using StrongNameIdent ityPermission it doesn't matter what visibility the
classes have. You can even put it on the entire assembly if you want nothing
at all available to unknown assemblies. However, you are not guaranteed that
identity permissions won't get bypassed by priviliged code, in which case you
may have no other option than to compare the current assembly's public key to
the calling assembly's public key in every constructor, using code similar to
the below

void CheckAssemblies ()
{
Assembly currentAssembly = Assembly.GetAss embly(this.GetT ype());
Assembly callingAssembly = Assembly.GetEnt ryAssembly();

byte[] currentKeyData = currentAssembly .GetName().GetP ublicKey();
byte[] callingKeyData = callingAssembly .GetName().GetP ublicKey();

if (currentKeyData .Length != callingKeyData. Length)
throw new SecurityExcepti on("Illegal calling assembly");

for (int i = 0; i < currentKeyData. Length; i++)
{
if (currentKeyData[i] != callingKeyData[i])
throw new SecurityExcepti on("Illegal calling assembly");
}
}

--
Happy Coding!
Morten Wennevik [C# MVP]

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: exporting certain classes in assembly

ab2305@gmail.co m wrote:

On Oct 13, 10:25 pm, Arne Vajhøj <a...@vajhoej.d kwrote:

>puzzlecracke r wrote:

>>is there a way to create a library (assembly/dll) where I can only
>>export few class? I don't want client to use or know about other
>>internal classes in the assembly.

>public vs internal ?

>
That could cause a problem. Say my client classes reference util
classes, that I don't want to export outside, making those internal
would break my implementation.

You will need to explain what you want.

I read the above as "if make class X internal to prevent
it from being used outside the assembly, then I can not
use it outside the assembly which is a problem".

You can not both eat your cake and have your cake.

If you need more granularity in access then maybe
InternalsVisibl eTo can help you.

Arne