I'm using Visual Studio 2008.
I have a solution with two projects. One builds a DLL, which is my "production code". The other builds a console app exe, which is my unit test suite.
For my unit test project, I have listed as linker inputs the names of the source modules from the DLL. I.e., I have a DLLMain.cpp in the DLL project, and a linker input "DLLMain" in the exe project. This allows the exe to link with the obj files produced by the DLL project, preventing recompilation of those modules just for the unit tests. (Saves a lot of build time.)
THE PROBLEM IS that because the exe is produced later than the obj's, and by a different project, its timestamp is always newer than the obj's. So when you try to run or debug, it ALWAYS says the exe project is out of date and needs to be rebuilt.
Is there some way I can configure the exe project to ignore the timestamps? Or is there some other, perhaps more general, solution I'm not seeing here?
Seems like you are creating foo.obj in the DLL's project, linking foo.obj in the DLL project to produce the DLL, and then linking foo.obj to your EXE project without first recompiling it.
I have never done this before, but first thing I would check is to make sure the Intermediate Directory settings are the same for both the EXE project and the DLL project.
Go to the project that is not needed for unit testing
Right click on it and press Properties
Click on Configuration manager
Add a new configuration using the first drop down list
Click ok
Select that configuration in the window that is now focused
then in configuration properties set "Excluded From Build" to yes
Related
I'm currently working on a project that has a DLL and a .exe that loads it. Whenever I press F5, it compiles the .exe project(which is set as default) but it does not compile the DLL one(which is the one with the most changes to).
I've tried the "Multiple Startup Projects" feature in the solution's properties, does force the DLL project to compile, but it always pops a message box saying it can't launch a DLL file.
Is there anyway I can tell Visual Studio to build the .exe and the .DLL whenever I press F5(or click the button) but only start the .exe one?
VS should build any projects that it recognizes as out of date. If the DLL project is not referenced by the EXE project, then you can add an explicit build dependency by right-clicking on the solution and picking Project Dependencies from the context menu. This lets you specify build dependencies before a given project build (in addition to relationships implied though project references).
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 project that relies on some other projects on my solution. For example assume that my main project is m and it produce m.exe
This project depends on some other projects say a.dll, b.dll,c.dll.
My problem is:
when I build m.exe, a.dll,b.dll and c.dll are created and the output is placed in some directory on my pc, but these dlls are not copied to output directory of m.exe and hence when I want to debug m.exe, they are not found.
If I copied them to output directory (debug directory) the application runs, but I am not able to debug into a.dll,b.dll and c.dll.
How can setup my MSVC so I can compile and debug into these dlls?
I am using Visual studio 2012.
In your project settings (Configuration Settings -> General) for each project, you can set the output directory. Change it for every configuration/platform of every project to e.g. $(SolutionDir)$(Platform)\$(Configuration)\ (or anything else that resolves to the same location for each project).
The alternatives are to either add a post-build step to copy files around via command, or to change your DLL resolution mechanism and use delay loading code that resolves referenced DLLs "manually".
I'm developing a C++ project in Visual Studio 2012 that uses driver code to interface with an open DMX box(ENTTEC DMX USB PRO). Thus far, I've been writing code and compiling as an EXE so I could use main() to run unit tests.
I want to port this over so that I have the device interface code that compiles down to a .DLL, then a separate source file that contains C++ code to compile an EXE that links to the DLL and makes calls to the functions to run the tests.
Essentially, when I go to debug, is there a way to setup Visual Studio 2012 to generate a .DLL and an .exe making calls to the .DLL and run the .exe automatically all in one step? I'm new to Visual Studio and find it quite confusing.
Yes. Setup two projects in your solution: One for your main code (generating a DLL) and one for your executable, where your unit tests reside. Then look under project dependencies (under the Project menu on VS2010, not sure about 2012) to make the EXE dependent on the DLL (that will make sure the EXE rebuilds/relinks when necessary).
Right-click on the EXE project in the Solution Explorer and select Properties. There you can setup the includes/linker to get to your header/lib file, if necessary (it might not be necessary if you use LoadLibrary explicitly or something, but I'm guessing you're not doing that).
Now in the project settings for the EXE under build events, add a post-build event that runs your tests. Note that if your EXE returns something other than 0 from main(), VS can report that as an error in the build.
I have a solution where I've added and setup boost unit tests. The problem is that I have another project I'd like to test that has some classes in it. In fact, that project is the main reason I added boost.
My project that needs testing is set to output as a .dll. And the problem is that, whenever my tests project needs to access code from the other projects, it can access the header just fine. However, if the header has unresolved code in it that's otherwise resolved in a .cpp file of the project with the objects, I receive a linking error. Is there a way around this? I'd ideally like to keep my objects in my other dll and then test them in my tests project.
You're probably not telling your test project where to find the symbols. Either link against your production code's .lib manually, or you can add the project as a reference and VS will link your projects automatically.
Go to your project's properties, under Common Properties choose Framework and References. Click the Add New References... button, and select your other project. Since it's a .dll, you then want to set Link Library Dependencies to False (save and reopen the dialog, that setting seems to be buggy).
The problem was that the visual studio compiler couldn't link to the CPP in the other files. I had to add the CPP files to the boost project as well using the existing files option.