I have a VS2012 solution. One of the Project A generates a .h file at runtime. This header file is used by another Project B. Project A and Project B are in the same directory.
However when Project B starts rebuild, C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppClean.targets deletes the files generated by Project A. Due to this Project B cannot find the file anymore and build fails.
How can I avoid the files being deleted during a clean build? Should the two projects be moved to a different directory?
Note that this problem does not occur in Visual Studio 2008.
Have you set the build order in the solution? It has to be explicitly set that project B depends on A, unless you use the project referencing functionality built into VS to directly set the dependency between the two projects.
Is this header generated in the temp ("Intermediate") directory by a "Build Event"? If so, then Project B assumes it's a temp file and deletes it. This is because project B's cleanup finds the header in the temp directory but doesn't know that it's an output of Project A. Possible solutions:
Separate the output folder from the temp folder and generate the header in the output folder.
Keep the output and temp folders together but separate the output/temp folder of Project A from that of Project B.
Generate the header in a Custom Build Step instead of a Build Event, and specify the header as the Output of the step.
I faced same issue while migrating to VS 2015. The solution is to set the "Configuration Property->General->Intermediate Directory" to ..\\$(ProjectName)\ so that Build.CppClean doesn't clean up previous build dlls from other unrelated projects. This worked for me.
Related
Being new to making/using libraries, I followed a simple tutorial to build a static library in Visual Studio (2022). I made a solution with 2 projects in it. One that builds a library and one that uses the library. It worked. Then I made an independent project / solution to see if I can use this library independently from the original solution/projects. I put the lib file and hpp/cpp file into new separate folders and set these folders in project properties (Additional Include and Library Directories + the .lib file).
Problem: I could use the functions from the library in this new project but when I tried to step into it with the debugger, the cpp file it stepped into was from the original project. (that's what the path showed anyway.) When I renamed the old project and tried again, VS complained that the file directory has changed and asked me to set the path to it. I did set it to the newly made directory with only the hpp/cpp in it and it was fine. I made another new project for using the library and tried the whole thing again and then the debugger simply could not step into the function, it stepped over it.
My questions: what was going on here? how did the debugger find the original cpp file when Im positive I did not set that path anywhere in the new project? and how do I debug a static library then? Is putting the cpp file next to the header in the include directory not enough?
Basically, I have two projects, one which compiles to a dll and the other which consumes that dll. What I want is for the .dll file to be copied to the dependent project's binary folder so that project can use it. I can't just do a simple "copy" script because then my dll won't get recopied upon recompilation. It was suggested that instead I should run a couple commands, one which deletes the old dll if there is one, and then copy the newly compiled dll to the location. It was also recommended to do this with a batch file. I've never written a batch file for visual studio (or anything else for that matter) so my question is how would I:
1.) write a batch file that would say something like:
if dll exists then delete and copy over the new dll
2.) Get that batch file to run with my project in visual studio?
Thanks for any help!
You need to get the results (.dll) of one project into the other project's folder. There are multiple ways to do this, but one way is the following.
Go to the project properties of your DLL project.
Go to Build Events -> Post-Build Event
Enter copy <filename>.dll ..\otherproject\bin /y
This will copy the DLL to the destination folder, overwriting it if it's already there (and if it's not in use). You may need to adjust the directories depending on your project structure.
I am working on a project that involves making a dynamic link library, so I want to test it in a console app in Visual Studio.
The DLL is also made in Visual Studio, it doesn't have much, just a few functions in it. I'm not sure if I'm just supposed to include the librarys header in the include directories panel in Properties, or do something else
A lot of people say I'm supposed to add its corresponding .lib file in the Library or Reference directory, but I'm not sure that VS generates a .lib file alongside the DLL. I'm using VS 2015.
I don't have VS in front of me this very moment, but these should be the general steps to set it up:
Properties->Linker->Input: your.lib
Properties->Linker->Additional Library Directories: ../your/bin
Properties->General->Compiler->Additional Include Directories: ../your/include
To build your app, the DLL's API headers must be in the include for the compile-time, it's LIB files in the bin for the link-time. Once you have your app EXE, all you need is the DLL to be in the same folder as your EXE when it executes.
You might also want to add the dll project and the app project into a common solution in VS and add (right click) Project Dependency from the app to the dll. This ensures correct order of building, assuming you are going to build the dll at all.
You can also do what I did.
You can create a Libs directory inside of your Solution directory.
You can then place your .DLL files inside of the Libs directory or some sub-directory inside of Libs
In my case, I added the entire SFML-2.3.2 directory in there, which included the source-code, .lib files, and .dll files.
I did link up what I could in the project properties, but I used Visual Studio's macros to fill in the path name to the Solution directory. Just in case I wanted to put this in version control and work on it from multiple machines.
Then I opened up the Project's Property Page.
Within the property page, I went to Build Events -> Post-Build Event -> Command Line
Within the Command Line, you can add a copy command that will copy any needed files into the same directory as the executable that will need them.
In my case I used: copy "$(SolutionDir)Libs\SFML-2.3.2\bin\*" "$(TargetDir)"
I could have written multiple commands to copy just the individual files that I needed, but I had spent a good three hours trying to get SFML to work without actually installing it.
I have started my first bigger project with Visual Studio 2012 in C++. I will structure my Source-files in folders, but I can not find where I can create real folders, like in the windows explorer. So here is my question.
How can I create real folders in my project?
The IDE has a command for that, "New Folder". It is even present in the Project + Add context menu, something you can see when you look at the context menu with Tools + Customize. It is however hidden in the C++ IDE. Intentionally.
Its important to understand why it is hidden. It keeps you out of trouble, the kind of trouble you'll get into when you create folders with Explorer.
At issue is the way C++ files get built. They produce an .obj file when the compiler is done with them. That obj file is stored in a directory whose name is a project setting. You see it with Project + Properties, General, Intermediate Directory setting. For an individual .cpp file, it is C/C++, Output Files, Object File Name. The default for that one is $(IntDir) a macro that tells the compiler to use the Intermediate Directory setting. With the default settings, all .obj files for the Debug build end up in the Debug subdirectory. Release subdirectory for the Release build. Regardless where the .cpp was stored.
Maybe you see the bear trap by now. If you create a subdirectory with .cpp files then you'll get in trouble when that subdirectory has a .cpp file whose name is identical to another .cpp file in another subdirectory. They produce an .obj file with the same name. One overwrites the other, which ever one was compiled last. That produces very mystifying linker errors. You'll get duplicate symbol errors because the last built .obj file is linked twice and missing symbol errors for the overwritten .obj file.
So go ahead and create a subdirectory but beware this problem. You have to change the Object File Name setting for the .cpp file if such a collision happens.
This is mildly annoying, however, here is what can be done:
Create the new folder in Visual Studio. This does not create a new folder in the file system. Add a new item to the folder. Choose the proper directory for the item.
For example, if your project is at %Documents%\Project, and your new folder name is Folder, then you add a new item to that folder at %Documents%\Project\Folder.
Visual Studio 2012 will put the item in the folder where you want it. If you add a new item, it will default to the same folder. That is where the annoying part comes in. If you create 3 folders for all your project items and try to add a new item to each folder, Visual Studio will try to put all 3 items in the same place in the file system (the last folder you added a new item to), while putting items into the correct Visual Studio folder.
It is possible there is a setting for this in Visual Studio. I haven't found it. I also haven't looked that hard.
I have a project in a c++ solution. For that project, I have some config files that I would like to manage from within the project and when I build the project, have those config files added to the executable build path in the proper directory structure.
Example:
test.exe references config/myconfig.txt
Is there a way to setup myconfig.txt and my project so when I build test.exe, I get
/
as well as
//config/config.txt
so when I run test, all paths stay in the proper order without me having to go in and manually create those directories.
I'm not sure I'm making sense here, but maybe one of you will understand where I'm going.
You could use pre-build events to create the directories and copy the files.
In Visual Studio's Solution Explorer, you can right-click on the non-code files, select "Properties" and set the "Copy To Output Directory" property.
This creates a rule in the build file to (1) include the file, and (2) to copy that file as part of the build process. In other words, it's possible to get this behavior without Visual Studio, but a little more work.