I have a Visual Studio solution and I want to setup project dependencies in following way:
Project A needs project B during runtime. E.g. when someone Builds project A, project B should also be built (unless it is up-to-date).
Project A does NOT depend on project B in compile-time (e.g. it doesn't statically link to project B etc.). Therefore they can be built in parallel.
If I set in Project Dependencies dialog for Project A that it depends on Project B, Project A will be built only after project B is finished building. Because I have about 100 projects in a solution, this significantly slows down build.
So my question is: can I setup dependencies in the way that Project A requires project B, but they could compile in parallel?
Update
The most common case when we run into problem is when someone just forgets to build the solution before launch. When dependencies are set, VS brings up a prompt to build all projects depending on startup project. When there is no project dependency and project B was modified, VS doesn't issue any message to user, and this usually results in nasty runtime errors.
At the moment we are using following workaround: project A does not have dependency set on project B, and we set Projects and Solutions -> Build and Run -> Only build startup projects and dependencies on run to false (not checked). However, this is a global setting, not a solution option. So I wonder if there is more correct way to solve this problem.
Related
I know you can set Build Dependencies for projects in Visual Studio and that will make the dependency build before the other projects. However, I have a project that all others will depend on (including new ones that may be added in the future), and so I'd rather just say "this project must build first, before all others" without bothering to set a dependency for every other project. Is there a way to do this in VS?
Is there a way to do this in VS?
Visual Studio calculates the build order according to your dependence. Like project A depends on project B, Visual Studio will build B prior to A. So if you want to make one project build before all others, you could not avoid this bothering setting or Visual Studio could not get the build order, will build in the error order.
In order to avoid set a dependency for every other project, you can right-click on your solution and find the Project Dependencies menu item:
The dialog that opens will allow you to set build dependencies and show you the calculated build order (you can affect the order by changing the dependencies).
In this case, you can set a dependency for every other project at once, no need to set for each one, but for new ones that may be added in the future, you still need to do the settings after added.
I have a large number of projects in my solution, but the main two that are of interest are projects A and B. Project A has no reference to project B. Here's what happens in a few scenarios:
Build project A. Project A builds as expected.
Run project A without debugging. Project A builds as expected.
Debug project A. Project A builds as expected, but build output gets wiped when complete and VS starts building project B.
Unload project B and debug project A. Project A builds as expected.
Based on these, I think I can safely say that there are no dependencies on project B from project A. I've also searched all the .csproj files, as well as the .sln file itself. There are no references to project B anywhere that I don't expect any (obvious by the namespace prefixes). What could be causing scenario 3 to rebuild project B?
I know that I can define a specific build order using dependencies in Visual Studio, but my question is do those dependencies and build order stay the same whenever I check-in my work to TFS and run a build on the TFS server? I ask because I am having some issues when it comes to having multiple projects in the same solution where project B references project A, and project C references project B, etc.
The solution builds locally just fine because I have set the dependencies such that project B always builds first, but it doesn't seem like this configuration carries over to TFS.
Is this possible to do on the TFS build side?
TF Build will build your projects in the same order, dependency order, that they are built in Visual Studio.
If you reference a project (no reference a projects output but the project) then it will all cascade correctly. Direct Binary references do not cascade correctly as both VS and MSBuild assume it is already built.
Make sure your updated solution file, with the build order, Is committed to TFS.
Ensure that your build is targeting this solution file rather than a list of projects.
As others have said Project References are the key, check all references point to the project and not the binary output.
If the references are correct then the build order will be correct automatically and manual intervention is only really required for projects such as wix projects where the installer project should always be built last after all of the other outputs have been completed.
I recently upgraded to VS.NET 2012 and I started encountering a very frustrating issue when debugging.
Project A has a project reference to Project B. When I edit Project B, I would expect that action of building/debugging Project A to detect the change in Project B and automatically include it during the build of Project A. (That's kinda the point of project dependencies.) And that's exactly what used to happen in VS 2010.
But this doesn't happen in 2012. Indeed, even if I build Project B explicitly, Project A will not pick up that change unless I rebuild project A.
So now I'm forced to explicitly build Project B then go back to Project A and explicitly rebuild it for the modifications in Project B to be included.
Thoughts?
Did you set the dependency projects in your solution?
We can set them from:
Right click solution->Properties->Project Dependencies
By the way, did you build your solution in the Visual Studio IDE or by msbuild command?
If you use msbuild to build the projects, you should add DependsOnTargets attribute in your project files.
More information you can refer to:
http://msdn.microsoft.com/en-us/library/ms366724.aspx
Your 3rd paragraph seems to indicate a misunderstanding with the way dependencies work. Forgive me if I am mistaken.
If project A has a dependency on project B, building project B would not force a rebuild of project A. Building project A however should check for changes in project B and rebuild B automatically if needed.
Project A in this case is the parent or root project. Building the parent would check all the projects on which it depends and rebuild them if they are out of date. Always building the parent would automatically build outdated dependencies first, and then the parent project would be built picking up any new changes in the dependencies.
A
\
B
|\
C D
In this example, if B had dependencies they would be built as well. If you explicitly built B, its dependencies C and D would be checked and rebuilt but not A.
If you explicitly built A, first C and D would be checked and rebuilt if necessary, then B, then finally A.
I had a similar problem before, and the cause was that the A's reference to B was a regular reference (to the DLL file), rather than a "Project Reference". This situation would certainly explain the behaviour you see.
To check, look at ProjectA.csproj in a text editor, and examine all the <Reference> and <ProjectReference> elements to make sure they are the way you think they should be.
I think you're looking for a continuous integration (CI) server. A CI can be configured to monitor source repositories and triggered to build target assemblies when new changes have been committed to the code base.
Otherwise, as others have mentioned, project dependencies can be used to rebuild referenced assemblies.
One potential cause of this is locked .suo files. See my answer on this question:
Visual Studio 2012 not building dependent projects
I have the following setup:
Project A
Project B depends on A
Each project has pre and post build events. Most of the time I make changes in project B. So every time I tell VS to only compile project B the other project is compiled too. This happens despite the facts that no changes where done to A and a up to date DLL for A is present.
How do I tell VS to only compile project B in this case?
Thanks in advance
This isn't very healthy, do make sure that Build + Rebuild works to verify that no circular dependency snuck in. Next step is to get more diagnostic info out of msbuild to see why it thinks it needs to build A. Tools + Options, Projects and Solutions, Build and Run. Change the MSBuild project build output verbosity setting to "Diagnostic".
If you right click on the solution and select configuration manager you can tell the projects not to build.
You can use Shift-F6 to build an individual project.