32

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.

lysergic-acid
  • 19,570
  • 21
  • 109
  • 218

3 Answers3

32

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.

lesscode
  • 6,221
  • 30
  • 58
  • Whats so hard about solution A, reference a class of a project inside Solution B by typing in a project of solution A :using ClassOfThatProjectB ?? – Peter Jun 22 '17 at 08:50
  • Unfortunately Visual Studio will only warn you on adding a new reference, but not when loading a solution. This leads to the situation where - if you use the same project in multiple solutions with "lightweight variants" to conserve on Intellisense resources - Visual Studio will never complain about already dead references. In fact, Visual Studio itself simply ignores references pointing outside the solution, while MSBuild will follow them. – Ext3h Jul 10 '17 at 07:26
11

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.

GrahamD
  • 184
  • 1
  • 5
2

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.

Travis Vroman
  • 364
  • 2
  • 9
Tigran
  • 61,654
  • 8
  • 86
  • 123
  • My question was, can i add a reference to project A (ProjectReference) to project B, if they're not contained in the same solution? – lysergic-acid Jul 22 '12 at 16:55
  • @lysergic-acid: no you can't. You can add a `DLL`, or the project which is inside the solution already. But why do not simply include the project in the solution ? What is a problem, actually? – Tigran Jul 22 '12 at 17:17
  • the problem is i'm trying to create a more "fine-grained" solution file, instead of including all references in it. – lysergic-acid Jul 22 '12 at 17:18
  • @lysergic-acid: I would suggest avoid some "custom" (or hack, if you wish) solutions in this case, honestly. The solidity of the code model, it's possibility to be build or fail on different versions of different projects (in case those projects are managed by different people), is much more important that some optimizations, imo. – Tigran Jul 22 '12 at 17:30
  • @lysergic-acid, actually it is possible. But then it will work only like a dll reference, i.e. the project which you reference will not be rebuilt, so there is no practical meaning in this. – Do-do-new Jul 11 '17 at 07:48
  • @Empus Practical point is that in big solution (which contains all projects) types will be understood properly. Type from project A will be type from project A, not an one more type from assembly A – Evgeny Gorbovoy Jul 30 '19 at 14:04