Develop Reference

Is there an access modifier that limits to a solution?

In my .NET solution, I have two projects: one main project and a project for running tests against the main project. In my project, I have several methods that I'd like to keep "private", but would also like to run tests for. Is there an access method that could limit these functions to just inside of my solution?

You are looking for the InternalsVisibleTo attribute.
This attributes lets you specify other assemblies that should have access to types and methods that are internal to your assembly. So, in your main project AssemblyInfo.cs file (or any other source file), you can specify that your test project is a 'friend assembly' and should have access to the internals of your main project:
[assembly:InternalsVisibleTo("MainProject.Tests")]
On a side note, as pointed out by Alexei, if your MainProject is signed with a strong name key, any 'friend' assembly must also be signed. This is explained here
Although, as mentioned in another comment. Best practice is to test your assembly by using its public API.

You can use InternalsVisibleTo attribute to make internal types and methods visible to selected assemblies.
However, you should try to design your API so that it can be tested using only the public interface.

You should seriously think back about the architecture of your solution. This is a smell that often shows that your class does too much things at once.
A simple fix is to extract this responsibility (those private methods) to another class where they then become public and are testable out of the box...

No, there is no way to limit access to "just solution".
The reason is solution is simply group of projects. One project can be in any number of solutions. So even if you "limit" access to projects included in one solution you/someone else can create another solution that somehow will need to magically get access to methods.
Additionally built assembly does not include any information on what solution it was part of - so there is no information at run time to check access.
To you particular problem - InternalsVisibleTo (as shown in other answers) will give access to internal methods to projects you allow (requires strongly signed assemblies) or refactor your code to avoid need for testing private methods.

InternalsVisibleTo - How do you prevent someone from creating an assembly with same name and get access to internal classes or methods?

Recently, I came across the InternalsVisibleTo way of making internal classes and methods visible to other assemblies. Though this is very useful in an application where you have a whole bunch of assemblies and you want to avoid circular dependency or code duplication, some of us think this could expose a security flaw. What are your thoughts?
For example, if I have an attribute thus:
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("foo")]
Even if this were hidden away in an assemblyInfo.cs file, one could discover this through disassembly, etc. And not everyone signs or obfuscates their assemblies. Now, armed with the information that there may be more functionality up for grabs, I can create my own assembly called foo.dll and then make use of methods/classes that I previously could not.

There's no security flaw here because the public/private distinction has nothing to do with security. Members are not "hidden" as private for security reasons, but rather for design reasons. Anyone could find all your private methods by reflection and call them directly anyway, even if InternalsVisibleTo is not set.

If you don't want "accidental" replacements (I say accidentally because member visibility is not a security measure) you need to use strong name signing of the target assembly you are wanting to make visible (your source assembly will also need to be strong named, see the remarks section of the MSDN for InternalsVisibleToAttribute).
so the following attribute
[assembly: InternalsVisibleTo("foo")]
will become
[assembly: InternalsVisibleTo("foo, PublicKey=002400000480000094" +
"0000000602000000240000525341310004000" +
"001000100bf8c25fcd44838d87e245ab35bf7" +
"3ba2615707feea295709559b3de903fb95a93" +
"3d2729967c3184a97d7b84c7547cd87e435b5" +
"6bdf8621bcb62b59c00c88bd83aa62c4fcdd4" +
"712da72eec2533dc00f8529c3a0bbb4103282" +
"f0d894d5f34e9f0103c473dce9f4b457a5dee" +
"fd8f920d8681ed6dfcb0a81e96bd9b176525a" +
"26e0b3"")]
Then only assemblies that where signed with the private key that corresponds with the public key listed in the attribute will be able to view your assembly's interals.

You should in the first place avoid using InternalsVisibleTo if you can. I rarely even use the internal accessibility on types, and even more rarely find a need for those types to be accessible to an assembly other than the one in which they are declared.
That said, the attribute does exist for a reason, and in some very rare cases it really is needed. In those cases, as you've found, if the referenced assembly is not signed, then anyone can build such an assembly and then the internals in your own assembly will be visible to it.
And no, there's not anything you can do about that. .NET has no way to recognize the "correct" assembly unless it's signed. That's precisely why signing exists.
So, if you really want to restrict access to the internal members of the assembly, then you need to use strong-naming (i.e. signing the assembly) so that .NET can tell the difference between the correct assembly and an imposter.

My experience is that InternalsVisibleTo is essential for sound unit testing.
I agree with previous answers that string name signing is key to minimizing security holes. If you want to be double-secure - I wrap a (#IF DEBUG) around the InternalsVisibleTo declaration. Then it's not compiled when you go to RELEASE.

In C# (VS-2010), is there a way to fail a frontend build if a certain library class is used? (When normally it would compile just fine?)

I'm writing a library that has a bunch of classes in it which are intended to be used by multiple frontends (some frontends share the same classes). For each frontend, I am keeping a hand edited list of which classes (of a particular namespace) it uses. If the frontend tries to use a class that is not in this list, there will be runtime errors. My goal is to move these errors to compile time.
If any of you are curious, these are 'mapped' nhibernate classes. I'm trying to restrict which frontend can use what so that there is less spin up time, and just for my own sanity. There's going to be hundreds of these things eventually, and it will be really nice if there's a list somewhere that tells me which frontends use what that I'm forced to maintain. I can't seem to get away with making subclasses to be used by each frontend and I can't use any wrapper classes... just take that as a given please!
Ideally, I want visual studio to underline red the offending classes if someone dares to try and use them, with a nice custom error in the errors window. I also want them GONE from the intellisense windows. Is it possible to customize a project to do these things?
I'm also open to using a pre-build program to analyze the code for these sorts of things, although this would not be as nice. Does anyone know of tools that do this?
Thanks
Isaac

Let's say that you have a set of classes F. You want these classes to be visible only to a certain assembly A. Then you segregate these classes in F into a separate assembly and mark them as internal and set the InternalsVisibleTo on that assembly to true for this certain assembly A.
If you try to use these classes from any assembly A' that is not marked as InternalsVisibleTo from the assembly containing F, then you will get a compile-time error if you try to use any class from F in A'.
I also want them GONE from the intellisense windows. Is it possible to customize a project to do these things?
That happens with the solution I presented above as well. They are internal to the assembly containing F and not visible from any assembly A' not marked as InternalsVisibleTo in the assembly containing F.
However, I generally find that InternalsVisibleTo is a code smell (not always, just often).

You should club your classes into separate dlls / projects and only provide access to those dlls to front end projects that are 'appropriate' for it. This should be simple if your front-end and the group of classes it may use are logically related.
If not then I would say some thing smells fishy - probably your class design / approach needs a revisit.

I think you'll want to take a look at the ObsoleteAttribute: http://msdn.microsoft.com/en-us/library/system.obsoleteattribute%28v=VS.100%29.aspx
I believe you can set IsError to true and it will issue an error on build time.
(not positive though)
As for the intellisense you can use EditorBrowseableAttribute: http://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute.aspx Or at least that is what seems to get decorated when I add a service reference and cannot see the members.

Prevent loading an assembly in c#

I want to prevent an assembly to be loaded from another application. So that it can be loaded from my application only.
Rigth now I'm using Assambly.LoadFrom to load the assembly.

Ultimately, no. It sounds like you are deploying a dll, but you want to retain sole control over how it is used. That is just an arms race; ultimately if somebody really, really wants to (ab)use it, they can. Even if that means disassembling, de-obfuscating, and disarming any preventative code you have added.
The only way to block that: don't give it to them. Consider using a web-service for some functions. Then they don't have the assembly.

You can try to validating entry assembly (Assembly.GetEntryAssembly) somewhere in your 'protected' assembly.

You can't stop people from using your DLL using technological approach. You can try to make it more difficult but a sufficiently skilled user will be able to modify the assembly so that they can use it.
You could try a legal approach. You can include a clause in your license agreement which disallows people from using your assembly in another application. But it won't stop everyone.

You could use the InternalsVisibleToAttribute in your assembly and specify your application assembly as a "friend". This will prevent other assemblies of using types provided they are marked as internal but will allow your application to still use those types.
From MSDN:
Ordinarily, types and members with
internal scope (in C#) and friend
scope (in Visual Basic) are visible
only in the assembly in which they are
defined. The
InternalsVisibleToAttribute attribute
makes them also visible to the types
in a specified assembly.
The attribute is applied at the
assembly level. This means that it can
be included at the beginning of a
source code file, or it can be
included in the AssemblyInfo file in a
Visual Studio project. You can use the
attribute to specify a single assembly
that can access the internal types and
members of the current assembly. To
make the assembly's internal types and
members visible to additional
assemblies, you must include a
separate InternalsVisibleToAttribute
attribute for each assembly.
Not that this does not prevent anyone from loading your assembly, it just prevents them from using the internal types within the assembly (at least not without some major effort, in the end anyone can just disassemble your code and use it that way).

Obfuscate it and keep documentation secret. Also include a key as in:
http://www.codeguru.com/columns/experts/article.php/c4643

Sharing dll without adding reference

I have got a dll placed in a shared folder over development server. Is there any way to use that dll without adding reference in my application and without installing the same in GAC.
Thanks in advance.

Assembly asm = Assembly.LoadFrom(path);
See MSDN for late binding, reflection etc.
Small edit: A variable with the keyword "as" is asking for trouble. So "Assembly as" changed to "Assembly asm" should be safer.

You may want to look at the Managed Extensibility Framework or at Assembly.Load... in the base framework.
Why would you want to do this, though? You'd need to call any code within the Assembly via reflection (hence the suggestion that the MEF may be what you're really after).

Yes, it is possible...somehow. Have a look at the Assembly-Class. With it you can load assemblies from a file without knowing what you exactly load.

Using Assembly.LoadFrom would be the only way to have zero references, but you'd still need to share contracts.
What's the problem with adding a reference?
What are you going to do when someone wants to work on a laptop and the WiFi goes down?

Yes,
you can call Assembly.Load() and then make use of Reflection to call into the public interface (lowercase "interface" - what I mean is the methods, fields and properties) exposed by the assembbly.
But in order to do that you need to know what methods to call. It helps if you can be certain that the assembly includes classes that do conform to a known .NET interface.
This idea is the basis for "plug-in" architectures in many tools, where the tool loads any assembly in its "plugin" directory, instantiates classes, casts the result to an ISomething, and then invokes methods via that interface.

I also would read Suzanne Cook's .NET CLR Notes.
http://blogs.msdn.com/suzcook/default.aspx

If this assembly is in a shared folder, you may find that .NET security restrictions stop you working with classes in that assembly in quite the way you'd expect.
Rather than storing on a shared folder, you may want to consider checking in the assembly to your source code repository. (I've seen a "/lib" folder used to good effect for this). Then you can reference the assembly directly.
(There are also repository solutions such as Maven that can more properly control this. However, they don't play well with .NET, unfortunately.)