Develop Reference

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.

access referenced projects at runtime

I have a rather strange project where I need to check the assemblies of the projects included as references in my project to see if they contain a certain Type. As far as I can tell the only way to see which projects are in my solution is to parse the solution file - which I can't do at runtime since I don't have it.
Does anyone know a way to see, at runtime, which assemblies are in the project file?

To check the referenced assemblies in your project assembly at runtime, you need to use Reflection.this.GetType().Assembly.GetReferencedAssemblies()

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

How to set "Specific Version" property for project references in Visual Studio

I have got a Visual Studio Solution containing several projects and have set up the references between the projects as project references.
When a reference to an assembly is added, the references' properties contain a setting for
Specific Version = True|False
This property is missing for project references. How can it be set? I'd like my solution to load any available assembly (no matter what version) in the bin folder.
I've had a problem when a workflow instance (Workflow Foundation) was deserialized and the dependencies were updated meanwhile.

I think the problem is that what you are asking is not possible directly with a project reference, I think that always implicitly turns into an 'explicit version', because of the nature of the link.
The way you could do this (calling the currently referenced project A, and the referencing project B):
Have the project you want to reference in your solution, just like you do now with the project reference
Explicitly set the dependency chain so the 'referenced' project is built first
Build the referenced project A once first manually
Create an assembly reference in project B to the results from the build in project A
Set the assembly reference to 'Specific Version = false'
The build order (dependency) will guarantee that A is always built before B, and B will reference it from the binary output directory of A.
(altho, it's a little brittle and I would not recommend it since it's easy to get wrong results if the settings are not all right, or the sun aligns with the stars wrong, or some such)

I might be misunderstanding your question, but when you add a project reference, the project's assembly is always loaded into any project that references it when the project is built. Therefore, you'll always have the latest available assembly in the bin folder for that project. VS treats projects differently than other assemblies in that regard.

You can add references to project output dlls instead of projects. Then you will be able to set Specific Version setting.

I have found the solution to my problem. It's described pretty detailed here.
The problem is not a matter of wrong project references, but more a de/serializing of workflow instances question.
Thanks to everybody who tried to help.

conditional assembly references based on solution

I have a rather large solution consisting of about 10 different projects. Until now we have shipped the entire solution as a whole to customers, but we are looking into shipping a stripped version of our software.
To this end I would like to exclude several projects from the solution. I know that you can prevent projects from being built in the solution configuration manager. Using macros all code references can be disabled when the stripped configuration is chosen. Unfortunately this does not take care of the project references. Can I make these references conditional depending on the chosen configuration?

It should be a pretty simple matter to remove the project references from the project file using a small script - it would just be a case of removing lines adding those references. The project file format is quite simple.
I suspect that's likely to be the easiest solution.

I think that this should be done when you build your projects for production. Simply enclose all code that needs to disappear between a compiler-level IF, that checks for a defined compiler directive. If on, then the code between the IF and ENDIF will not compile. This works for code files only.
For anything other that you need to take out, just make up your own way, depending on the file format, as Jon Skeet mentioned. But once you put that into build scripts, you need not care about it any more - no switching configurations, etc.

Your best bet is to create separate projects for your "stripped down" solution that references only those other projects you want. Reference the same code. Create a separate solution to hold those projects together.
They can all live together in the same folder structure, too.
For example:
MySolution/MySolution.sln
MySolution/MyStrippedDownSolution.sln
MySolution/MyProject1/MyProject1.csproj
MySolution/MyProject1/MyStrippedDownProject1.csproj
MySolution/MyProject1/MyClass1.cs
MySolution/MyProject2/MyProject2.csproj
MySolution/MyProject2/MyStrippedDownProject2.csproj
MySolution/MyProject2/MyClass2.cs
MySolution/MyProject2/MyProject3.csproj
MySolution/MyProject2/MyClass3.cs
MyProject1 and MyStrippedDownProject1 reference MyClass1
MyProject2 and MyStrippedDownProject2 reference MyClass2
MyProject3 and MyStrippedDownProject3 reference MyClass3
MySolution references MyProject1 and MyProject2 and MyProject3
MyStrippedDownSolution references MyStrippedDownProject1 and MyStrippedDownProject2
MyProject1 references MyProject2 and MyProject3
MyStrippedDownProject1 only references MyStrippedDownProject2 -- it does not reference - MyProject3

There's lots of info in http://bytes.com/topic/net/answers/444853-conditional-assembly-reference that I found very useful for resolving a similar question (it pertains more to assembly references than project references though). MSBuild get assembly reference from ProjectReference might help with bridging between.