I have read this post thoroughly: How does Visual Studio's source control integration work with Perforce? and found it very informative. However, I have a specific issue that is blocking my use of Perforce in VS.
For the most part, I have no complaints about the plug-in (I'm still using the P4VSCC plug-in because the new plug-in requires conversion by the entire team which can't happen at this time). Once I understood the idiosyncracies, I've had only one problem working with the plug-in.
Our solutions contains many projects that are built into a single deployment package. As such, each assembly is versioned the same. To accomodate this, and other common aspects, we have defined a common "SharedVersionInfo.cs" file which contains the AssemblyVersion and AssemblyFileVersion attributes typically found in the AssemblyInfo.cs file. This file is stored in an Assets folder beneath the solution folder and added to each project's Properties folder as a linked file. This works great from a version management perspective as we only have to change the version in one place and all assemblies are updated. However, Perforce has a problem with this when a new developer first opens the solution or when a new project is added. The only remedy we have currently is to remove all of the linked files (there are 3 per project in this solution), bind the project to source control, then re-add the linked files.
This isn't such a big deal when we add a new project but the solution contains 80 projects (and counting), so this isn't a viable remedy for a new developer!
My understanding is that the problem has to do with where VS thinks the binding root for each project is. After some research, I was led to find where the MSSCCPRJ.SCC files are for the projects. I found there are numerous SCC files scattered throughout the solution structure. So...
First question: Why are there multiple MSSCCPRJ.SCC files in my solution structure?
We also have several shared/common projects that we use in our solutions. This leads to the following folder structure:
/Source
/CommonTools
/ProjectA
ProjectA.csproj
/ProjectB
ProjectB.csproj
/MySolution
/Assets
SharedVersionInfo.cs
/Project1
Project1.csproj
/Project2
Project2.csproj
:
/ProjectZ
ProjectZ.csproj
MySolution.sln
Where both ProjectA and ProjectB are part of MySolution.sln
Second Question: How can I setup the bindings so the /Source folder is considered the root? This would ensure that all projects included in the solution are under the same binding root. Perforce considers this folder to be the root, how do I get VS and the plug-in to do the same?
Since no one else has offered up a solution, I thought I'd follow-up with my own findings for anyone else that comes across the thread.
First, I still have no idea why Visual Studio creates multiple MSSCCPRJ.SCC files but these are the key to establishing the "binding root" for a solution. It is critical that this file exist at the highest level necessary so that ALL of the projects in the solution are in sub-folders relative to the location of this file. In my example above, the MSSCCPRJ.SCC needed to be located in the /Source folder. Having it in the /MySolution folder caused the original problem when adding projects from /CommonTools into the solution.
That said, resolving the issue was no easy task. I had to manually edit the .sln and all of the .csproj files in Notepad. What I found was that some of the .csproj files had the following elements identifying the source control settings:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
I don't know what SAK stands for, but my understanding is this tells Visual Studio to use the binding information contained in the .sln file.
I had to change these to:
<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>
where the SccLocalPath value is the relative path from the .csproj file to the MSSCCPRJ.SCC file.
I also had to change the SccLocalPathX and SccProjectFilePathRelativizedFromConnectionX statements for each project in the .sln file. The SccLocalPathX value should be the relative path from the .sln file to the MSSCCPRJ.SCC file - a dot (.) if in the same folder. SccProjectFilePathRelativizedFromConnectionX should be the relative path from the binding root to the .csproj file.
I wish I could say that having that in place, I never had to repeat these steps. Unfortunately, I still have to go in and make corrections every time I added a new project to the solution. Visual Studio still wants to use SAK for the elements in the .csproj file and sometimes the values in the .sln file aren't quite right.
But, at least I know what to look for and what needs to be done to achieve my goals. If anyone else has a better solution or a way to configure VS and/or Perforce so these settings are created correctly up-front, I'll gladly give credit.
Hope that helps...
Codeblocks cannot find definitions or declarations of some functions in my project.
Question: Is there a way to force a re-scan of the source tree?
I believe that all of the relevant files are included into the project.
(Just checked: it cannot find by name a struct declared in an opened file.)
First, let me give a couple of ways to help C::B find your declarations/definitions.
Although somewhat obvious, you should make sure the function is in a file that is either:
1) part of the project itself (i.e. it should be shown in the projects->workspace window). If you intended it to be part of the project but it isn't there, then go to project->add files and add the file.
2) If you don't want/need the file to be part of the project but you still want to access the declarations/definitions, you need to let the project manager know where to find the file. You can do this in project->build options and set the search directories. Be careful when setting the search directories...you can set it for the whole project or build target (debug or executable).
Note: one common problem occurs when you have multiple projects open in C::B. Even though all your projects are "open", there is only one that is "activated". So, just because you have a file open, it doesn't mean the file is part of the activated project. You can do search-->open files" which will find code in a file if it's open but not in the current active project.
The only way to "re-scan", is to rebuild your project after making changes in the source code or project settings. You may have to restart C::B. If you still can't find the declaration/definition after doing the above, I would suggest you make a sample program and see if it will find the declaration/definition. If it does, then you can check the settings between your project and the sample project. In the worst case, you can copy your code from your project to the sample project. If that doesn't work, you can reinstall C::B and try again. Not fun but sometimes it works.
You can try, rebuilding the project, but make sure at least one other file includes the header for the structure or make sure the header and source file are included in the project.
Sorry for what seems like a silly question: But I've never, ever worked with boost, until tonight, and I'm finding that getting it configured seems to be harder to use than it should be.
I wanted experiment with it tonight. So I downloaded the zip file, and unzipped it to a directory here:
F:/boost_1_44_0
Then I created an empty c++ project in visual studio 2010 (not using pch either). So all I wanted to do was to include a header file. But not even a silly thing like that seems to work. Now I've been using visual studio for years, though at work we are still stuck on vs 2008 (That is another story). So usually what you do is set an include directory, and then you can include files in at will right?
So I set the global include directory to include the boost root. i.e. Property Manager -> My configuration (debug|win32) -> Microsoft.Cpp.Win32.user -> Common Properties -> C++ Directories -> Include Directories. There I added my path to f:/boost_1_44_0.
I also went to the project properties and set the C++ include directory for the project to point to the boost root like in vs 2008.
I then added a silly include declaration like so:
#include <boost/lambda/lambda.hpp>
But, amazingly it fails to compile!!! with the following error:
Error 1 error C1083: Cannot open include file: 'boost/type_traits/transform_traits.hpp': No such file or directory f:\boost_1_44_0\boost\lambda\core.hpp 25 1 test_boost
Which when I double click it, it opens up in f:\boost_1_44_0\boost\lambda\core.hpp, and takes me to this line:
#include "boost/type_traits/transform_traits.hpp"
So I have no idea what's happening. Is visual studio just not delivering up my global include paths that I set? It seems also that the include directive in core.hpp should be using angle brackets and not quotes.
If I'm doing something wrong what?
EDIT:
!! SOLVED !!
Before I didn't have all the files unzipped. I don't know what happened. So I re-downloaded the zip file, and unzipped it again. This time the zip file took much longer to unzip, and it extracted much more files: Including the missing files.
Problem solved, my hello world app compiles just fine now.
The behaviour of compilers in locating header files is implementation defined for both the <> and "" variants.
However, based on this page for VC2010, it appears the quoted form searches a superset of the angle bracket form so I'm not sure that's the problem.
I suppose it would be a silly question to ask if the following file actually existed?
f:\boost_1_44_0\boost\type_traits\transform_traits.hpp
So, a couple of investigative jobs:
Make sure that f:\boost_1_44_0\boost\type_traits\transform_traits.hpp exists.
Try changing your top-level include to use quotes.
Try changing the include in f:\boost_1_44_0\boost\lambda\core.hpp to use angle brackets.
Make sure you try all four possibilities for those last two.
Is f: a network-mounted drive? What happens if you put it all on c:?
That last one is just in case Windows is doing some shenanigans under the covers :-)
While it's a bit overkill for this, learning to use SysInternals' Process Monitor will pay off over time. It will show you what files are actually opened, and which attempts failed. Look where Visual Studio tries to read transform_traits.hpp from, and you'll probably have the answer.
I am building a cross platform product and one of the requirements is across windows(win32,AMD64 and IA61). The product as is relatively simple CLI but we have a separate build team who checks out the code from CVS and build in separate build environments. I am able to build succesfully(using Visual C++ 2005) in one platform(AMD machine). But once I check in the code, check out the build fails.
The cause of the build failure is because the include library paths are wrongly specified in the property sheets. Specifically the output file folder under the Linker in property pages are specified wrongly. So these libraries get built in a different folder from where the other projects are expecting them.
However along with the source I check in the .sln files (and later .vcproj files) also everytime. Morover if I open the .sln file in the folder where the build is not succeeding, there is no difference between the one where I could succesfully build(pre check in). In fact using windiff I could not see any difference between the two build folders (except some .ncb and cvs log files).
So any idea what is going on? Where does VC++ 2005 take the include directories take the output folder path from if not from .sln? Is CVS somehow interfering with the process? Anything else I could try out.
Thanks in advance.
Just to update the problem was resolved. The root cause is the .vcproj files were not getting checked in CVS!! This is where the individual project settings were stored(I was under the impression that this is done in .sln files).
I think the problem can be that after you have changed the settings in one build configuration (for example x86-Release) but forgotten to change them for another configuration (for example ia64-Debug), and when configuration changes, you have this problem.
Another thing that I would check on your place is project dependencies. If those are set in the right way VS will look for project output exactly where it is outputted, even when you change the output folder.
Do you have any binary files checked in as ASCII?
The round trip to and from CVS can corrupt binary files that are incorrectly marked as ASCII because CVS performs character processing on ASCII files (e.g. to give you the correct end of line codes for your OS). Corruption can occur even in an all Windows environment.
See the Binary section in the CVS FAQ for more information.
I have a Visual Studio project with about 60 C++ source files. I can do a build, and it completes without errors. But if I immediately hit F7 again, it always re-compiles about 50 of the source files. It doesn't re-compile all of the files, which is strange.
I have 'Enable minimal rebuild' (/Gm) set. Any ideas why it might be doing this?
None of the files have a Modified Date in the future.
Are any of your file dates in the future? This can occur if you changed time zones or changed the system clock time. Dates in the future will confuse the IDE and force a rebuild every time F7 or F5 is hit.
I've solved the same problem.
In my case compiler displayed warning, that /Zi option is required if /Gm is specified.
/Gm enables "minimum rebuild", which requires debug information in .pdb file. So, if you don't want to use .pdb, also disable minumum rebuild - it solved a problem in my case.
Most probably is a matter of dependencies.
Consider the following possibilities:
If you have custom build tools defined for some of the files in your solution, make sure that the output property contains the right file name(s). If the output of the build tool doesn't correspond to the one(s) specified in the output file names, the builder will rebuild that file.
If you have custom build events, check whether the output from those build events don't affect the dependencies of the files to be built.
I had problems when trying, at post-build, to copy or move some of the output files to a build folder. The post build operations that affect the timestamp of the ouput files of the build process will determine rebuild each time.
In my case of such effect (C++ via VS2005) it was on Release configuration only, and the Studio tells in the build output, that compiler option /Gm is ignored if /Zi - option is not set. After setting /Zi via
Configuration Properties -> C/C++ -> General -> Debug Information Format : Program Database (/Zi) ,
it was ok. But isn`t there something wrong, when the Release Configuration needs something about Debugging? Not yet clear to me!
Project Properties -> "C/C++" -> "Output Files" -> "Program Database File Name" option should not be empty. Set this option by selecting from drop-down box . The option will be set like this: $(IntDir)\vc90.pdb. And line ProgramDataBaseFileName="" will be removed from vcproj file.
Then only changed *.cpp files will be recompiled when you build the project or solution.
It seems that this problem can be caused by many things, but what fixed it for me was:
Closing Visual Studio
Manually deleting all bin and obj folders (Clean doesn't seem to do the trick)
Opening the solution and running Clean (I'm not sure if this is necessary, but I did it just in case...)
Building like normal
Note: This was for a C# program in Visual Studio 2010.
After a couple days of googling, I ended up with a solution to my problem.
I encountered this problem when I moved my projects to a new PC. I had checked several times the creation date of the files. These dates were up-to-date, however the modification dates were in the bast (kinda bizarre) even when I changed the files.
A simple update of the files resolved the problem.
I'm having the same problem, and it seems to be because I've turned browse information off. Properties->C/C++->Browse Info->Enable Browse Info->None. The only fix I've found is turning it back on. This is for an xbox 360 project, fwiw, my other projects don't have the problem.
A reason is if the 'date last modified' for one of the source file is set for some date in the future: it rebuilds, and then the source file is still later than the executable.
This problem with the dates can happen if the source file is located in a directory a remote machine (a network share), and/or may even happen if your machine's time isn't synchronised with the date of the machine which is running the server of your source version control system.
Check your project includes any .h header file that doesn't exist on disk. Always happens to me when I delete a header file I'm not actually including anywhere, but forget to delete it from my solution navigator in VS. Note: missing headers produce no errors during the build (when not #included anywhere).
Check your project's Program Database Filename setting. For some reason, if this is set to the name of a directory (such as "$(IntDir)\"), it can sometimes cause VS to rebuild your project every time, even if you're not generating PDB files (i.e. Debug Information Format is set to "Disabled").
This is a bug in VS2008; I have not yet reproduced it yet in VS2010, but my tests haven't been thorough, so I'm not confident saying that the behavior isn't present in VS2010.
What caused similar symptoms at me was:
I have several projects in a solution. There were .cpp files which were referenced (and therefore compiled) by >1 projects. Unfortunately Visual Studio creates .obj files with a very simple naming - it just replaces ".cpp" by ".obj". Creating wrapper .cpp-s with different named solved the problem.
I had something similar. Even though I did have pre and post build events, they weren't causing the issue. It turned out that I had a number of projects down the reference chain that had content files that were marked as "copy always" instead of "copy if newer" meaning that these projects were always considered "out of date". By changing all of these to "copy if newer", changes to my unit test project no longer forced a recompile of all of the other projects.
Disabling "minimal rebuild" (Configuration Properties > C/C++ > Code Generation) fixed it for me. The compiler even left a clue:
1>cl : Command line warning D9007 : '/Gm' requires '/Zi or /ZI'; option ignored
Although I must point out, the compiler did not ignore the option as it said.
In my case I changed system data time to previous date so it is rebuilding every time because of different time stamp of the files once changed to the current time its not rebuilding every time.
We have that here regularly:
delete all intermediate and output files by hand. The clean option in vstudio is sometimes not enough. From a fresh start do the complete build. If after a complete build vstudio still wants to recompile certain files it might be related to next bullet.
if in your vcxproj a header file is referenced which is not on disk, the project is also recompiled. You might check this by some hidden feature described on MSDN blogs or just touch (i.e. click on it to open) all header files in the project exploder and see if one does not exist on disk
Had the same problem. Solved by:
-delete output folder (obj,exe,all files)
-run cygwin
-cd project folder
-run "touch *", which reset file modify date/time
-build and enjoy problem fixed
There is similar issue with project rebuild.
Visual Studio does not recompile but re-links a project every time on F7 hit.
Fix is simple. Try to open in Editor all files included into project (from Solution Explorer double click on each file) and remove from solution those files which do not exist.