I am using Visual Studio 2008 in order to build a soultion with 19 projects.
If I go to the Project Dependencies window and then to Build Order tab I see that project XXX should be the last project to be built. However, when I build the solution, project XXX is built somewhere in the middle, and it is definitely not the last project to be built.
How is this thing possible?
The Build order tab should show you one possible topological sort of the projects based on dependencies. If you want a project to always be the last one built, you should make it depend on all the other projects.
Maybe you selected another one which depends on your project XXX project before building
solution. Also, concurrent projects building at a time may cause your confusion. Let
open "Option\Projects and Solutions\Build and Run" and make sure maximum number of parallel
projects builds is 1.
Related
I have multiple C++/C# Visual Studio Solutions some depend on each other, in the building Process I make the building order manually and build them one by one until the end.
now I will be going to continuous Integration "CI",
My Question Is: is there any tool or method to automatically generate the correct building order?
My Project Structure Looks Like that:
All_Code:
VS Solution A:
Project A.1
Project A.2
VS Solution B:
Project B.1
Project B.2
Let's say Project B.1 Depends on A.1 and A.2 Depends on B.2
so, when I am building I order them as follows:
A.1
B.1
B.2
A.2
Create one solution (.sln) file that contains all the projects in the CI build and plan to use that solution file for the CI build.
Now, you can either discard the use of the existing 'A.sln' and 'B.sln' solutions and add project references in the projects (Project B.1 would have a project reference to A.1 for example) or set the build order in the new .sln file itself.
Prefer to use project references if possible because they have options and capabilities that the other approach doesn't offer. But note that a project reference is a change to the project file. Further the referencing project and the referenced project must both be in the solution. That means that using project references will break the existing 'A.sln' and 'B.sln' solutions.
You can, however, create solution filter files (.slnf) for the new .sln to create 'views' that are equivalent to the 'A.sln' and 'B.sln'. (See Filtered solutions in Visual Studio.)
If you need to keep 'A.sln' and 'B.sln' and keep them useable, you can manually set the build order in the new solution. In the solution properties in the 'Project Dependencies' section, manually set each project's dependencies. This is stored in the .sln file. The project files are not changed. However, the dependencies set in the .sln file will need to be kept in sync with the project's actual dependencies.
The tooling will automatically determine the build order based on both the project references in the projects and the project dependencies in the solution.
I've been redesigning my custom VC++ build to be compatible with the new TFS 2015 Build solution.
The issue is running msbuild. I can post perhaps a simplified version, but my solution contains two items:
1 Makefile Project designed to build all of the libraries required, and
1 .exe project.
I have a reference in the .exe project to the makefile project, so that the build of the .exe forces the build of the library if needed.
The issue we are seeing is that when we do a rebuild with msbuild of the solution, it first rebuilds the library, and then when it gets to the .exe, it cleans the library project, causing some of the rebuilt files to be deleted and then preventing the link of the .exe file because the .lib file was deleted.
Why is it cleaning the makefile project again? It seems like when it gets to the .exe project, it re-resolves the dependency, and does not know that the library project was already rebuilt.
Thanks in advance. Larry
If multiple projects are in the same folder, Visual Studio attempts to erase output folder (typically Debug or Release) when the next project will be compiled. The best solution is to put each project in the separate folder.
I didn't go through all details but the reason this happens is that when building on the command-line, rebuilding the exe project results in Clean + Build of the exe project, and the Clean target for the exe project eventually calls the CleanReferencedProjects Target which results in Clean being called on your Makefile project (and later on, Build as well).
This CleanReferencedProjects is conditional on the properties BuildingInsideVisualStudio and BuildProjectReferences, so building inside VS skips this step anyway because BuildingInsideVisualStudio is true, and it's even documented:
When building the project directly from the command-line, clean those referenced projects
that exist on disk. For IDE builds and command-line .SLN builds, the solution build manager
takes care of this.
The BuildProjectReferences property is documented as follows:
By default we will build (and if applicable, clean) all project references. But this can be used to disable that
So one possible solution is calling msbuild some.sln /t:Rebuild /p:BuildProjectReferences=False. In the case with only 2 projects this will work properly, but I cannot guarantee this will always work in more complicated situations with more inter-project dependencies.
Now one thing got me wondering: how come I've never seen this behaviour myself? The answer lies in that I don't use makefile projects often, and the C++ projects which I do use are slightly different: there, the Rebuid target is defined in terms of Clean+Build (while for a Makefile project it is a standalone, separate target). As such when the exe project calls BuildProjectReferences, it will call Clean in the C++ project, but that results in
Target "Clean" skipped. Previously built successfully.
because when the C++ project's Rebuild was called it called Clean and Build already.
So another possible solution is doing the same for the Makefile project. You say that your Rebuild has additional requirements; I don't know what they are nor why they are needed (and arguably it is wrong that Rebuild does not have the same effect as Clean + Build) but this might work anyway, for example with this in the makefile project (all the way at the end of the file):
<Target Name="Rebuild" DependsOnTargets="Clean;Build">
<!--additional requirements here perhaps?-->
</Target>
everything beaves properly and Clean/Build is called once only.
If none of these solutions apply I don't immediately see another way than removing the makefile project from the solution, and manually building it before the solution both locally and in TFS.
I have a Visual Studio 2013 solution with several projects in it. There's a Core project and Engine project, which compile to static libs, and a final Game project which links those libraries.
If the Engine has a compile error in it, then that project fails to build. However, Game will still attempt to build and link, presumably using the existing / old Engine library file.
So, even though my build has a compile error, it still produces a final EXE. Is there any way I can stop this?
EDIT: Here are the options I am using to reference the first two projects from the final one. Perhaps I am doing something wrong here?
There seem to be StopOnFirstBuildError extension for that purpose. Found reference to it in the feature request
Set proper dependencies in your projects: usually all you need is to add references, this way if one of dependent project fails final exe won't build as it wouldn't have all required references.
In your case it seems like you copy some libraries to some other location and then use these copied libs for linking. This would definitely lead to problems like the one you describe if your final exe doesn't use references but has manually configured input libraries in linker settings.
For example, if you use VS 2013 (or any recent version), and have a few static libraries and some executable that depends on them you should do this:
remove explicit libs from "Additional Dependencies" from linker settings of your executables and dlls.
remove explicit dependencies from project settings if you set anything manually (for simple cases you don't need to set these).
add your lib projects to references of your executable or dlls that use these (this properly sets all dependencies, linker inputs etc if you use default VS project settings):
If your Core and Engine are static libraries, then do not make Engine dependent on Core even if Engine uses Core, this way VS can build them in parallel. If Engine is a dll then add Core to References of your Engine project and add references to Engine to your Game project. If Core and Engine are static libs, then simply add references to Core and Engine to your Game project, nothing else is needed.
Try this sample TestGame VS project.
First build TestGame project, try to run it.
Go to engine.cpp and introduce some error in that file.
Now build TestGame project again. VS first tries to compile TestGameEngine project and this fails and ends entire build process without even attempting to build TestGame project.
At this point TestGame project still has and old binary that was left from previous successful build and if you try to run TestGame it will ask if you want to build it (as it's outdated):
If you click "No", it will run old binary. If you click "Yes" it will try to build TestGame project again (which will fail again). If you check that box "Do not show this dialog again" and click "No" Visual Studio won't try to rebuild an existing binary even if it's out of date, and will run existing binary and won't ask again about that.
If you click "Yes" after it fails to build updated binary of TestGame it will ask if you want to run old build:
If in this dialog you also check that box to not ask again you'll probably get that behavior that you describe where VS tries to use last successful build. All you need to do to "uncheck" check check boxes now. You can do that in options (Tools -> Options -> "Project and Solutions" -> "Build and Run"), see the screenshot:
Is it possible to compile in one fell swoop multiple build targets? For example, I would like to compile an .exe and a static library which includes everything but the .c file that includes main()
If that's not possible, how to manage multiple build targets like this?
You actually can build multiple configurations of the same project. So you need make sure each individual configuration builds okay and in separate path. Then you can use Batch Build dialog to do build all in one time. I hope it should be even possible to build exe and dll using the same project, but different configurations.
Build multiple configurations simulataneously:
On the menu bar, choose Build, Batch Build.
In the Build column, select the check boxes for the configurations in which you want to build a project.
Choose the Build or Rebuild buttons to build the project with the configurations that you specified.
For more reference, see the batch build dialog box.
I am quite used to Linux development and Makefiles, and started using (Windows and) Visual Studio not so long ago.
What I want to do is (I think) quite simple, but I can't seem to find how to do it using Visual Studio.
I have to write an application, which I can divide into several independent sub-parts. I want to work incrementally, and create several projects that together with a main file will end up with my full project.
What I basically want is to be able to write a small project, have a main for it so that I can fully test it, and use it as a dependency for the next project. In this case, the smaller main would be deactivated (or I can comment it), and I would just change the startup project.
If I find a bug in a subset while writing my bigger software, I could just change the startup project and solve it at a smaller scale.
Well, that's what I do all day long in Python and Java.
I tried to create new projects into my project, but I always end up having linking problems, where my main projects knows about the files in the sub projects, but not the smaller ones, etc. . .
So, is there a guide somewhere I can find to work this way ?
Thank you
For individual projects:
Every individual project property sheet has a C++ options page. Here you can specify the 'Addional Include Directories' in a comma separated form.
Similarly, there should be a property sheet for Linker where you can specify the 'Addional Include Dependencies' and the names of the libraries it depends on.
For linker dependencies of the main executable:
Go to that main project, go to its properties, go to common properties and select 'Framework and References'. This should give you a list of all the projecs that are in your solution. Keep adding them and Visual Studio should add the right linker flags automatically for you.
Sorry, have no access to the computer now else would have provided exact steps. Visual Studio can get tricky sometimes but once you use it, you'll be amazed by what it can do for you. Personally, I love it.
Hope this helps.
Thanks to Vaibhav, I was able to find a solution:
I had to :
change subproject type to lib instead of exe
Add the subprojects as project dependencies in the main project (this just sets the build order)
Comment out the main of my subprojects, to keep only one active.
Add each subproject include directory in the include repos of the main project, so that the compiler can find the header files
Add the general directory as a dependency for the linker (in this case, it is not the debug/release folder of the subprojects, but the output directory of the complete project).
Add the names of the lib files of the subprojects in additional dependencies of the linker of the main project.
To make it simple, the project dependencies capability of VS2010 just changes the order in which the projects are built. . . I miss Eclipse.
If I find a bug and want to test on of the subprojects, I have to :
change the startup project to be the subproject I want to change.
uncomment the corresponding main
change the project type to be exe instead of lib to be able to compile it.
Debug, and do everything back again to continue working on my main project.
Quite boring, don't you think ?
Looks like you trying to do manual unit testing. Use something like Google.Test. You need to make test project for every lib.
We have directory with static libs projects. Another directory with tests projects. Every test solution contains one exe project and few existing lib projects. Every project have configured dependencies. You dont need to set additional dependencies of the linker manually (paths are evil, out dir for the lib file will be taken from project settings), open project properties with right mouse button, Common properties, Add new reference and select lib project. You only need to set additional include dirs.
When you find new bug - just open test project for the library with bug, add code which cause the bug, fix it, and be happy (and sometimes run all test). And even better - use TDD.