Develop Reference

c# hide class members when exporting DLL

Can I only make some methods visible to the end user when I'm publishing a DLL to third party applications?
My code is built upon 7-8 different projects which call each other, they have different namespaces like "Company.ProjectName" which I think relate under the "Company" namespace, and I only want one of the projects (which has an interface defined BTW) to be visible to outer world.
Every project in the solution compiles into DLL's and then I'm combining them using ILASM.
BTW, there are other projects using these in the solution that are not related to this dll.
Edit: will the internal keyword work even if the namespaces are constructed like "CompanyName.Project1", "CompanyName.Project2" ? Will they see each other?

You don't need to combine them, you just need a friend assembly:
When you are developing a class library and additions to the library are contained in separate assemblies but require access to members in existing assemblies that are marked as Friend (Visual Basic) or internal (C#).
...
Only assemblies that you explicitly specify as friends can access Friend (Visual Basic) or internal (C#) types and members.
The InternalsVisibleTo attribute:
[assembly: InternalsVisibleTo("AssemblyB")]
helps to lock it down so only the specified assembly can access the internal items.
(In answer to your edit: this is specified at the assembly level, it doesn't matter what the namespace is).

Use internal
See the example below
public class MyPublicClass
{
public void DoSomething()
{
var myInternalClass = new MyInternalClass();
myInternalClass.DoSomething();
}
}
internal class MyInternalClass
{
public void DoSomething()
{
}
}
In your DLL, MyPublicClass will be visible to external users - those who reference your DLL.
MyInternalClass will not be visible.

How to keep dynamically loaded assemblies form breaking code at compile time?

I am linking one of the external resource at runetime in my code using something like below:
System.Reflection.Assembly assembly = System.Reflection.Assembly.LoadFrom("MyNice.dll");
Type type = assembly.GetType("MyType");
Tool = Activator.CreateInstance(type) as Tool;
Now as you can see that at the end of the object creation, it has to cast the resulting object into the tool class because there are a lot of references to the methods and properties of Tool class in my code that if it is no there then the code will error out on compile time.
Now, this is a bad situation because I wanted to remove the Dll from my references and have it loaded dynamically at runtime but at the same to there are pieces of my code that referes to and are dependent to the Tool assembly. How can I make it independent? Do I have to use reflection all over my code or there is any easy alternative out there?
for example:
if (Tool.ApplicationIsOpen)
return StatusResult.Success;
is there in the same class which assumes that Tool class already exists and will break if I remove it from my references folder.
Any suggesitons?

I would suggest making shared DLL to reference from both projects that contains an interface in which Tool inherits.
In this shared project, make an interface such as ITool, that exposes the functionality you need for the consumer project.
Shared Project
public interface ITool
{
void Something();
}
Separate Project
public class Tool : ITool
{
public void Something()
{
// do something
}
}
Consumer Project
System.Reflection.Assembly assembly = System.Reflection.Assembly.LoadFrom("MyNice.dll");
Type type = assembly.GetTypes().FirstOrDefault(t => t.IsAssignableFrom(typeof(ITool)));
ITool tool = Activator.CreateInstance(type) as ITool;
Now you can delete the reference to the project containing Tool, but you still need the reference to the shared project that contains ITool. If you truly don't want any references, then explore the reflection route, but be warned it'll probably be messy.
This strategy is the basis for many plugin systems. I'd recommend you check out some Dependency Injection (DI for short) libraries that can do a lot of this heavy lifting for you.
Here is a list of DI libraries: http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
Personally I've been using Ninject lately.
Some relevant links:
Using Ninject in a plugin like architecture
Google something like "plugin framework DI C#"

Can't access public classes in an other project but the same namespace

I have two projects in my solution and in each of them I have a CS file containing a public class. Since both classes are in the same namespace, I was expecting them to be able to see each other. That is not the case. See the setup below.
Project Woof1, file File.CS
namespace MyNameSpace
{
public class Foo
{
// Doesn't compile
Faa f;
}
}
Project Woof2, file File.CS
namespace MyNameSpace
{
public class Faa
{
// Doesn't compile
Foo f;
}
}
NB, both classes are stored in files with the same name but in different directories (i.e. not the same file).
Why can't I compile it?
What can I do about it (except moving the classes to the same project).
(I only found this discussion on the subject but in the end it wasn't really my issue.)

Make sure the references are set up as supposed to. Each project needs to refer to the other.
Make sure to set public qualifier on all the classes in the projects.
Make sure to set public qualifier on all the enumerations in the projects.
Also, preferably, you might want to move your enums and other auxiliary definitions to a common project and store them there.

You need to add a reference to project Woof1 from project Woof2.
Also, trying to reference both from each other is not a great idea as you introduce a circular dependancy, making builds a nightmare. If ever you fell you need to do this, you should consider factoring common code out into a separate (third) project.

In Woof1 you need to include a reference to Woof2.
Another thing to note is that the namespace is case-sensitive, so both namespaces should be MyNameSpace.

you need to add a project reference to Woof1 from project Woof2. Please reference to this link for further information.

I did happen with me.It might comes if dlls are not proper builds.In my case i was using release option in toolbar.So make sure that debug option is selected

Include code file into C#? Create library for others?

I would like to know how can I embedd a code source file (if possible), something like that:
class X
{
include "ClassXsource"
}
My second question - Can I build DLL or something like that for my colleagues to use? I need them to be able to call methods from my "part" but do not modify or view their content. Basically just use namespace "MyNamespace" and call its methods, but I have never done anything like that.
Thanks

The C# compiler does not support include files. You can of course use a pre-compiler, that would read your source code files, and insert the included files into them, before passing the new files to the compiler.
As for producing a class library, sure. You can do it in two ways:
You can make the project source code available, so that they would add the project with all its files into their own project, and thus compile your class library as part of their solution.
You can compile it yourself, which produces an assembly file on disk (YourClassLibrary.dll), and then give that file to your co-workers. They would then add a reference to the file and can start using it.

You can't, except by using some external preprocessor. You could use T4, which is already used by Microsoft as a text templating tool, e.g. for code generation with the Entity Framework; see this MSDN documentation page.
With T4, you would include another source file like this:
<## include file="c:\test.txt" #>
Now to the more fundamental point: Including source files is not how you usually create libraries, especially not in .NET. What you would do is define one or more types containing the functionality—there are no global functions in C#, the closest you can get are static methods. You would then compile this and give the resulting assembly (.dll file) to your colleagues. (Or you create a NuGet package and publish it to a source that your colleagues can access.) They will be able to load it as a reference into their .NET project and use your class.
public static class MyFunctions
{
public static void MyMethod1(...) { ... }
public static int MyMethod2(...) { ... }
...
}
(Of course such code is more procedural than good object-oriented design, but this may or may not be an issue for you.)

No, not in that way. But you can create a class library and put all classes they need to use there. They simply add a reference to that dll from their project and import the namespace, voila, they can use the classes.

How can a .net class libraries be protected so it cant be referenced by other applications?

How can a .net class library project and resulting dll be protected so it cant be referenced by other applications (.net projects) except those projects in my own solution?

I think you can't forbid other applications to reference you library.
You can make library's classes internal and provide access to them via InternalVisibleTo attribute but it won't save you from reflection.

Yep, aku is right. In reality if you want certain types & methods to only be accessible to one application, you're better off compiling it all into one exe & marking those types all internal. You can then obfuscate the code to avoid the issue with reflection (see here)

Forgive my ignorance, but if they're all class libraries, what does the code do? Isn't the purpose of having a dll so that the code can be referenced.
In any case if you mark everything internal it won't be able to be accessed outside its own library

I think what deanbates is saying is that he is trying to find a way to keep a DLL public within his own application and private for everything else