Develop Reference

How to call a Method from an dll from an other project in the same solution

I have two different projects in a Visual Studio solution. I want to use one of the two as the main part of my program and so have referenced the second project like:
I know that I can use all the public classes from the project x on my main project. My question is: can I have dlls on the second project, x, and use the methods of those dlls in my first project?
A good example will be if, every month, I have a new version of a dll and I do not want to change this dll on 10 different projects in the solution explorer, I want to add those dlls as references on the x project and then all other projects to use the same dll.

it is not possible by referencing both projects, you would create a circuilar reference.
anyway, it is possible by doing this over reflection. for example in project x you can enumerate all types (Assembly.GetTypes or so), also of the referenced project. then you can create an instance of a class Activator.CreateInstance and execute members.

If you have 2 projects:
x.dll
MyProgram.exe
Making MyProgram.exe reference x.dll is fine. However if you want x.dll to also reference MyProgram.exe, this creates a circular reference.
This is a dangerous road to go down because you can only build either project when you have a binary of the other. In other words you can't build both from source at the same time because the references are not yet compiled.
I would highly advise against this. Instead consider further abstracting your code by moving the code x.dll needs to get from MyProgram.exe to a separate y.dll. This way you would have 3 projects:
y.dll
x.dll (references y.dll)
MyProgram.exe (references x.dll and y.dll)
This way you can build all from source as all the dependencies are linear.

Referencing a project in another project creates unwanted dependencies

I have a project ProjectA in which I am keeping utility classes. I want to use this project in multiple solutions so I do not have to copy files, link files and update files every time I make changes in classes of Project.
But there seems to be a problem: if I am referencing ProjectA in ProjectB, the compiled application of ProjectB can not run unless there's a compiled application from ProjectA next to it. So if the output of ProjectB is ProjectB.exe, ProjectB.exe gives an error upon execution if ProjectA.exe is not next to it. Why is that? I just want to use namespaces from ProjectA in ProjectB, I do not need ProjectA to depend on a compiled version of ProjectB.
Can anyone tell me how to reference ProjectA in ProjectB without needing the output of ProjectA to run the output of ProjectB?

You probably need a shared dll.
You have created utility classes in project A out because they are shared all across project A (Application A?), now you have introduced project B (Application B) and as you state it needs to get hold of the code from projectA.dll/exe.
So create a new project in your solution (Ab.Shared.dll maybe:-)) and move your utiilty classes into it. You can now reference that dll from both project A and project B.
Update: Just read about your comment about sucking code out.
The shared dll is the most common way of sharing the code about, but there are other ways. Theoretically you can simply "include" the same *.cs files in both projects and share them that way (use the drop down on the Add existing item dialog and select Add as link) . However in practice it becomes more awkward maintaining this scenario so most people use a shared dll.

Namespaces are not restricted to one assembly - you can use the same namespace across several assemblies if you wish, and one assembly can contain as many namespaces as you like.
If you are referencing a class/type from another assembly, then that assembly must be present (or locatable) when you run the original assembly. If all you are doing is coding then a simple project reference in your solution will do the trick. If you don't have the source code to Project A then you will need it in its compiled form - without it the CLR cannot inspect it and know what it contains.

In that case add the ProjectA compiled dll in your bin folder and add the reference to that dll from your other project. Do not add reference to your ProjectA project.
When you add reference to the project using Visual studio, Add Reference -> Projects, then it requires the project to be compiled and it copies the dll/exe to the other project bin folder.

Open your csproj file in text editor and insert xml:
<Reference Include="AssemblyName.dll">
<HintPath>$(EnvironmentVariable)\bin\AssemblyName.dll</HintPath>
<Private>False</Private>
</Reference>

If I understand correctly, you have code in ProjectA.exe that you want to use in ProjectB.exe, but at run time, you'd like to run ProjectB.exe without requiring the user to have a copy of ProjectA.exe.
This is not possible. When you use a type from another assembly, that assembly is loaded at run time. The type is not copied from ProjectA to ProjectB.
It sounds to me like you should extract the common utility classes into ProjectUtility.dll, and then reference that from both your ProjectA.exe and ProjectB.exe applications.
EDIT: ILMERGE might be the way to go. See Linking statically in C# for more information.

Adding a ProjectReference to a project that is not in the same solution

While doing some refactoring of our projects and solution files, i have separated some .sln files to contain less projects.
Occasionally i need to reference some projects from outside the scope of the current .sln file.
For example, my initial state was this:
SOLUTION A
PROJ A
PROJ B
After refactoring it would look like this:
SOLUTION A_NEW
PROJ A
SOLUTION B_NEW
PROJ B
My question is -- Is it possible to add a ProjectReference node to a project that is not defined in the same VS solution? (in my case, having PROJ A have a project reference to PROJ B).
Also, if it is possible, is that recommended?
I know that this is not possible from the VS IDE, only by editing the .csproj file manually.

You can't do this. A project reference includes an identifying GUID for the referenced project, which is maintained in the solution file in order to track solution build options and dependencies. If you try to reference a project that is not in the solution, Visual Studio will complain.
You can add a file reference to the assembly produced by a project that's not in the solution, of course.
UPDATE: Since this got downvoted, I'll refine my answer.
Though it's technically possible to craft a project file that references another project outside the same solution, Visual Studio won't help you to do it easily. One very good reason why it's a bad idea to do this (that I've observed) is that whatever Solution Configuration and Platform you're building (the referencing project) will be ignored if MSBuild decides to build the referenced project - the default Configuration and Platform specified in that referenced project file will be used instead. Thus you may end up with a mixture of binary types in different folders.

Temporarily add the project to the solution, add a reference to it, unload the project that now has a reference added to it, remove the referenced project, reload the project with the reference.
If you don't unload the project then the reference will be automatically removed by Visual Studio when the referenced project is removed.
As you can probably tell, Visual Studios not designed to do this and you'd be better defining a build order for the solutions and use assembly references instead.

You can definitely add a project to a solution A that is in solution B. There is not any problem with that. From my experience, it's not something that I usually have done or do, but sometimes need to. This can be especially true on large projects where you need different nodes of your architecture to reuse same code base.
Hope this helps.

Class Library - References - Reusability with Copy Local?

I have a class library project, lets call it CoreLib.
CoreLib has two references to 3rd party DLL files 1.dll and 2.dll
Because I love reusability so much, I want to be able to use CoreLib in as many places as possible/needed.
So if I had a project called BigProjectA and another project called BigProjectB and they needed to leverage the functionality provided by CoreLib, all I would have to do is add a reference to CoreLib in those projects (BigProjectA and BigProjectB).
That is fine, except when I go to copy over my output folder (bin directory) to another person's computer, I can't guarantee that they have 1.dll and 2.dll on their machines.
For that, I just set Copy Local to True for 1.dll and 2.dll references in the CoreLib project.
When building the CoreLib project I can see 1.dll, 2.dll, and CoreLib.dll files. That is PERFECT!
But in the projects referencing CoreLib, only CoreLib.dll is copied over, not 1.dll and 2.dll.
Am I missing something? Copy Local set to True, but only copies for the CoreLib project. So even though they are in the same solution, and I'm adding CoreLib as a project reference to the other projects, I still dont see 1.dll and 2.dll copying out to the other bin/Debug, bin/Release folders of the other projects (BigProjectA and BigProjectB).
Is there an easy solution?

The easy solution is to either:
reference 1.DLL and 2.DLL in projects which have a binary reference to CoreData.DLL
Add CoreData as a project reference to BigProjectA and BigProjectB instead of as a binary reference
In the first scenario, CoreData's dependencies are not automatically output by the compiler. If the CoreData project is added to the solution, its dependencies will be output. Hence, to use CoreData as a binary reference, you must also reference its dependencies.

There is nothing wrong. In projects BigProjectA and BigProjectB you have a references to only CoreLib, so they "care" about coping only it, cause they have no any clue about it's dependencies. What you can do to resolve these kind of issue, is to add for example PostBuildVEent in your BigProject.. to copy also CoreLib dependencies.
Or add reference to CoreLib project, if you can.
Another solution, is to consider DI like a technique to avoid strong coupling of references. So, if in BigProjectA or B you don't care about functionality provided by 3rd party libraries in CoreLib, for you should be enough to just copy CoreLib.

Good answers guys....but I actually just ended up using ILMerge. Seemed safer/less annoying.
Thank you though

Assembly dependencies with .Net projects

If I have an assembly (A) which references another assembly (B).
I want to reference A in a project, I add the reference and it copies A into my BIN directory. It does not copy B as well, even though A depends on it, so the code doesn't compile.
How can I set things up so that whenever I reference A, both A and B get copied to my bin directory?

In Visual Studio, add each project to the same solution. Ensure you use Project References instead of direct file references (ie browsing for the assembly).

I dont think there is any way around what you ask other than to explicitly add both. I dont think however adding projects for the sake of getting references copied is a viable solution to the issue. Not all projects that a solution depends on should necassarily be added to the solution. This would completely depdend on your overall project structure, processes, source control, division of labour, etc

Reference both A and B.

Unfortunately you'll have to manually add both. This is what happens to me as well whenever I use pre-3.5 versions of NHibernate: it requires both log4net and Iesi.Collections assemblies. So I have no choice but to manually include a reference to both in all my solutions that implement NHibernate.
This is more of an issue, of course, if you only have the DLLs. If it's a project that you have a codebase to Visual Studio itself will warn you beforehand that the references are missing.

How about adding them to Global Assembly Cache?