The solution I'm working on contains 400+ projects. The issue is not reproducible but very annoying. (Windows 8.1, Visual Studio 2015 Update 2 and 3)
Basically, some project dependencies are not taken into account when calculating build order. The process stops with an error: the referred dll cannot be found. It occurs every now and then, usually with a different project 'missing'. Many of the times nothing is wrong and it just works. Could not find any pattern.
If I build the 'missing' project by hand and then build the solution, everything is fine, or an other project goes 'missing'.
It seems, as if VS had lost track of project dependencies, although every reference is there, as seen is VS and in the csproj files.
See the screenshot: Solution build has stopped, because a dll is missing. The project that produces the dll is referenced correctly (see solution explorer), but is not visible in the Project Dependencies dialog. My guess is that because of that missing dependency, the build order gets confused and - based on some randomness due to parallel compilation - in some cases the dependent project gets built too late.
Note: yes, I could just check that check box but as I said, this issue occurs randomly and with random projects. And yes, I can work around the problem by manually building the affected projects beforehand. I am looking for a solution to the root problem.
Any hints and comments are welcome.
One way would be to just check what you reference and make sure you deploy those dependencies also. Another way to troubleshoot this is by checking the Fusion log with Fusion Log Viewer and see what dlls are searched for and are not found.
In order to identify project dependencies, you must first create a map of project tasks. Next, look for tasks that the team cannot perform until they receive information or deliverables from a previous task. Those tasks are dependent. Think of your whole project as a series of workflows or a flowchart.
Sometimes I have noticed that using an import helper (such as ReSharper) can cause a dependent project to link to the output of another dependent project instead of the dependency source.
This is to say that if you were to create a project - let's call it 'ProjectA' - and link it to library 'MyLib' then create 'ProjectB' and allow ReSharper to auto-resolve dependencies to link to 'MyLib' you might find that ReSharper will actually link to the .\ProjectA\Bin\MyLib.dll file rather than the .\Libraries\MyLib\MyLib.dll file.
When you rebuild your solution the following may occur: * ProjectB happens to build first/faster (because, perhaps, ProjectA has many changes but ProjectB only has few code changes). * ProjectB then attempts to link to the MyLib.dll located in ProjectA's \bin folder and can't find it. * ProjectA completes building and copies it's dependency - MyLib.dll to it's \bin folder. * ProjectB is not rebuilt manually by you and now has no problems locating \ProjectA\bin\MyLib.dll.
So, in summary, check the exact source location of dependencies in your project. I'd hazard a guess that with 400+ projects some includes have become crosswired.
Good luck!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With