Friend Assembly Overuse?

[enfekted]

At my company we ship a product that includes around 30 .NET assemblies that we have developed. We have a couple of developers that are under the impression that any public class/method in these private assemblies must be documented and supported in the event a user of our application directly links to these assemblies in their own application.

Question #1: Does the theory make sense? (should we assume that any public class/method in a private assembly can & will be used in a 3rd party application?)


To combat the overwhelming demand for documentation and support that this theory creates, there has been a push for converting all public classes/methods into internal classes/methods and having all of our assemblies friend assemblies to each other. This causes pain for our own developers in VS not showing intellisense for internal classes/methods when in a friend assembly.

Question #2: Is there another way to resolve this issue without causing our own developers additional pain?


Thanks in advance for your insights...

[darwen]

private assemblies must be documented and supported in the event a user of our application directly links to these assemblies in their own application.


Does this make sense ? No it doesn't. There are various reasons for this, the most immediate being backwards compatibility and support.

If a client of your software starts using your internal assemblies then you will be honour bound to maintain backwards compatibility - otherwise they'll install version 2 of your app and theirs won't work any more.

Private assemblies are private for this very reason - if you have 30 assemblies each of which you can't change the public interface for (or rather can only add) this will rapidly strangle any development. No refactoring will be possible and you'll effectively be stuck with the design of the codebase you have now.

To discourage such use you should NOT publish any documentation about the internal assemblies.

If clients want to use functionality provided by your codebase you should provide an interface for them which they should use. This should be well documented and backwards compatibility guaranteed (as much as is sensible).

This you can then support effectively.


To combat the overwhelming demand for documentation and support that this theory creates, there has been a push for converting all public classes/methods into internal classes/methods and having all of our assemblies friend assemblies to each other. This causes pain for our own developers in VS not showing intellisense for internal classes/methods when in a friend assembly


If you publish a documented interface to your codebase, this problem goes away.

And if any of your clients do connect to your internal dlls that is their decision. You can make it clear to them that they will receive no support for doing so, nor do you guarantee any sort of compatibility with later versions.

Darwen.

[enfekted]

Thanks Darwen, you make a good point. I remember now that backward compatibility was another argument given for making all the methods internal, but I agree it doesn't make much sense to ever have backward compatibility for private assemblies. We need to be able to change these assemblies whenever we have a need in order to support our own product and not worry about breaking customer's applications.

One of the issues that triggered this theory is that certain developers began to refer some customers to using our private assemblies for file support & basic functionality. I'm thinking now that we need to put a stop to this and if we want to have customers using our APIs we need to create a separate API-only release with only assemblies and methods we want them to use (fully documented & supported).

Thanks again for your help

[Arjay]

... that certain developers began to refer some customers to using our private assemblies for file support & basic functionality. That's why it's usually a good idea to keep most developers away from the customers. :)

[TheCPUWizard]

Just a few general notes:

1) From a practical standpoint you should only and always supply full user level documentation for the items which you are committed to supporting.

2) ALL items should have proper internal documentation.

3) Shoot the developer(s) who are recommending utilization of non-supported access points.

4) Do NOT use "friend" unless that is really what you mean. This REDUCES security

5) DO use CAS [Code Access Security] if you want to prevent (actually make extremely difficult) external programs from accessing routines.

6) And most important of all, Hide the bodies of the developers you shot.

[enfekted]

Thanks for the replies.

4) Do NOT use "friend" unless that is really what you mean. This REDUCES security


I'm referring to using the InternalsVisibleToAttribute in .NET. How does this reduces security?

[TheCPUWizard]

Thanks for the replies.

I'm referring to using the InternalsVisibleToAttribute in .NET. How does this reduces security?

In increases the "surface area" of an attack. Not only can a user tamper with the assembly that contains the code, they can now also tamper with the "friend" assemblies.

The recommended way is to use Code Access Security, and demand a custom set of permisions. Now you have full control over making a security implemnentation that is approrpriate for your application.

[enfekted]

In increases the "surface area" of an attack. Not only can a user tamper with the assembly that contains the code, they can now also tamper with the "friend" assemblies.

The recommended way is to use Code Access Security, and demand a custom set of permisions. Now you have full control over making a security implemnentation that is approrpriate for your application.

The surface area should be the same in either case (internal methods, although somewhat hidden, aren't any more secure than public methods).

I agree that CAS shouldn't be overlooked in either scenario, but simply (1) having an assembly contain public methods vs (2) having an assembly contain internal methods and linking via internalvisible shouldn't introduce (or resolve) any security issues, I wouldn't think...

Unless, of course, there is a way to bypass CAS from the calling assembly in scenario (2) that wasn't possible in scenario (1), but I don't know of any way...

Maybe I'm missing something?

[TheCPUWizard]

The surface area should be the same in either case (internal methods, although somewhat hidden, aren't any more secure than public methods).

I agree that CAS shouldn't be overlooked in either scenario, but simply (1) having an assembly contain public methods vs (2) having an assembly contain internal methods and linking via internalvisible shouldn't introduce (or resolve) any security issues, I wouldn't think...

Unless, of course, there is a way to bypass CAS from the calling assembly in scenario (2) that wasn't possible in scenario (1), but I don't know of any way...

Maybe I'm missing something?


Consider a case where you have two assemblies [A,B] and are NOT concerned about anything outside your environment.

"A" has a number of classes which have internal classesw/methods. They are not intended to be used by ANYTHING else. It also hase public methods that are going to be used by assembly "B".

Now you decide to "Secure" he situation by making all of the "A" items internal, and make "InternalsVisibleTo" "B". You have now just opened all of the methods which were previously inacccessible to "B".

Therefore it is possible:

a) your developers on "B" will use methods they are not supposed to
b) if security is compromised on "B",then more of "A" is vunerable.

Definately an INCREASE is surface area!!!!