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
Related
My solution structure is like this:
WiX Installer: depends on Project A and B
Project A: depends on Project B
Project B: no dependencies
It is configured like that in the build dependencies. The displayed build order (right click on the solution -> project build order) is the correct one (Project B -> Project A -> Installer). But for some reason when i try to rebuild the whole solution thats not the order in which Visual Studio actually tries to build the projects. It always starts with Project A which of course then fails cause of the missing dependency of Project B.
If i manually build the projects in the right order everything works.
In my .sln file projects are listed like this:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ProjectA", ProjectA\ProjectA.csproj", "{B80B7A8F-0576-41FA-BD3D-B3C6F5F8D6E7}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ProjectB", "ProjectB\ProjectB.csproj", "{D127D2C1-0F13-41F1-B4A1-218BC53ABC40}"
EndProject
Project("{930C7802-8A8C-48F9-8165-68863BCCD9DD}") = "Installer", "Installer\Installer.wixproj", "{1D504782-E92A-4C60-9ADC-6067E7E301AA}"
ProjectSection(ProjectDependencies) = postProject
{B80B7A8F-0576-41FA-BD3D-B3C6F5F8D6E7} = {B80B7A8F-0576-41FA-BD3D-B3C6F5F8D6E7}
{D127D2C1-0F13-41F1-B4A1-218BC53ABC40} = {D127D2C1-0F13-41F1-B4A1-218BC53ABC40}
EndProjectSection
EndProject
Any idea what might cause this issue?
Usually, the build order is saved in the solution file(.sln file) like this:
So when you use this, you should build the whole solution with that file. But
However, in vs IDE, when you build A single project, it can follow the specified build order, but in msbuild command line, msbuild projectA.xxproj does not build B first and then build A according to the specified dependencies. This is also unique to vs ides, although the build dependencies are stored in xxx.sln rather than individual xxx.proj files.
Unless the entire solution(msbuild xxx.sln) is built in MSBuild Command Line, it will be built sequentially.
This is the situation that generally causes this difference.
But for some reason when i try to rebuild the whole solution thats not
the order in which Visual Studio actually tries to build the projects.
I wonder what you did caused this and if you build the whole solution(xxx.sln file), this issue will not happen. So I want to know which build format or what you did to your solution.
Since MSBuild cannot build wixproj file, so you should use VS IDE or devenv xxx.sln /build to build the whole solution.
Suggestion
As a suggestion, you could use Project Reference instead to specify build order which will set the order in every xxx.proj rather than xxx.sln file. This will be more reliable and safe.
1) Remove the build orders under Project Dependencies(Right-click on Solution)
2) Right-click on WIX project-->References-->Add Reference-->Projects-->Select Project A and Project B.
3) Right-click on Project A-->References-->Add Reference-->Project-->Project B.
In addition, if it does not help you, please share with us what you did to cause this issue and any steps which caused it so that it will help us troubleshoot your issue more quickly.
Update 1
Just hint from Eric, and thanks to him for sharing the solution and test result.
Solution
First, remove all the project dependencies and then re-add them, after that, it fixes the issue. It could be an issue to this project since it was migrated from old VS2010.
I had the same problem. I was able to build my solution in Visual Studio. But when building it on Azure DevOps Pipelines with MSBuild, it built them in the wrong order; with my WiX .wixproj project being built before one of its dependencies.
My .sln file looked like this:
What I did to solve the problem, was to manually add more dependencies to this file:
So my advice is to look in your .sln file and add additional dependencies that you think would make sense.
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 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.
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.