Visual Studio: Build order random?

Question

I've a solution containing 239 projects. I've currently the following issue:

When I do a "rebuild all" on the solution, after having done a full clean(delete of the output directory):

17>------ Rebuild All started: Project: AAA, Configuration: Debug x86 ------
18>------ Rebuild All started: Project: BBB, Configuration: Debug x86 ------
18>CSC : error CS0006: Metadata file 'E:\Dev\Trunk\Debug\x86\AAA.dll' could not be found
17>  XmsCommon -> E:\Dev\Trunk\Debug\x86\AAA.dll

I understand the following:

• Visual studio is multithreading the compilation(in my case, 4 assembly at a time)
• I've no explicit "Project Dependency" specify(Right click on solution -> Project Dependencies)

What I don't understand

• In this example AAA is a referenced project of BBB, for me, it's an implicit dependency, how would it be possible to correctly build BBB without being sure that AAA has been built correctly?
• How should we manage this for a solution that makes 239 projects? It's hard enough to ensure that we don't make any reference to a wrong project, so if we always have to ensure the build orders, it becomes complicated.

A single note: I don't know if this is due to a recent change(of a project/visual studio/...), because it makes 2 years I work on this solution, and it's the first time that I came accorss this issue again and again.

So the question:

1. Is there a way to handle this without having to indicate each Project Dependency on the solution?
2. If not, how should we do this?

EDIT After the comment, here is some additionals infos:

• There is no compilation errors in AAA or BBB except it can't find the reference
• We references projects and not dll(checked in one specific case where I was having the error.

In BBB.csproj, I've the following reference:

<ProjectReference Include="..\..\..\..\SomeOtherFolder\AAA\AAA.csproj">
  <Project>{6241076B-05B3-4D5D-AFA9-46D41E1CEC3A}</Project>
  <Name>AAA</Name>
  <Private>False</Private>
</ProjectReference>

EDIT 2 I don't know if this is directly related, but when checking the Project Dependencies, I found that BBB is depending on CCC(but nothing is indicated for AAA. I'm wondering if there is a dependency specify, it basically ignore all the informations coming from the references? If I try to remove the CCC dependency, I got a message: This dependency was added by the project system and cannot be removed

EDIT 3

I made an interessting discovery: In fact the error I've in the EDIT 2 is because this dependency has been added when creating the reference between the two projects.

For an unknown reason, it seems this dependency has not been created for one reference here. If I remove the project reference, then add the reference again to the same project, I now have this dependency(which I cannot delete). I can't find where this "dependency is stored. Any idea on how to "fix" this solution wide?

Answer 1

I know this is not a solution, but you could turn your compile dependencies into runtime dependencies is you use Dependency Injection technologies, like MEF or Unity.

In this case, your projects have limited dependencies (Interfaces, Containers).

But I have to say, these technologies carry some side effects - like 'pseudo random' initialization and so on...

Answer 2

After some investigation, I found the issue:

In fact Visual Studio should automatically add those dependency between the projects when referring one into a project. I can see that very easily by just adding a project reference. In addition, it seems that those "dependencies" cannot be removed(see my edit 2).

So the question I asked is how can I have some projects referenced and no dependency for some projects?

I checked that my references(at least some case I saw it wasn't working) and they were project reference and not dll.

Some of my colleague, with the exact same code(Get latest version of code without changes) were not having this issue, and were having the dependency displayed in Visual studio.

So I ended by removing the *.sdf file near my solution file(after having closed visual studio). I reopened and tadaa, all the dependencies have been recomputed by visual studio. Now we I rebuild, everything is a success directly.

I'm not sure of why it happens, I had some time to kill visual studio, maybe something was corrupted then.

Answer 3

From your post you said that "I've no explicit "Project Dependency" specify(Right click on solution -> Project Dependencies)" This implies that all of your references are to the compiled DLLs, and not to the projects.

I have seen this approach many times done by teams with large solutions (you have 239 projects) due to the slowness of VS to load that many project references.

The workarounds that I have seen used are:

• Multiple Solutions for each sub-area of the primary solution, such as Entities, DAL, Logic, Service, etc.
• Checking in DLLs (not recommended, but I have seen it) into Source to be used for faster builds. Once you change a code area you are responsible for replacing the DLL.
• Configuring the Project Dependencies settings so that builds are done in proper order.
• Dealing with the performance of the Project References (slow, but ensures build order

A single solution with 239 projects seems to go against the tenet of compartmentalizing your development into smaller modules, but that isn't always your decision...

Answer 4

I have seen this issue in a smaller, but highly inter-dependent solution. We solved this issue by reducing the Maximum number of parallel project builds lower until it predictably succeeds. Tools --> Options --> Projects and Solutions --> Build and Run.