first, I'd like to apologize for my english, it's not my 1st language !
During a build configuration (TFS 2010), in the Workspace tab, I can specify the needed directories in order to avoid getting the whole source code every time I run a build.
Instead of doing this, is it possible to specify to the build to automatically get the projects in the solution to build and nothing else ?
Thanks a lot for your help ! :)
In short, no. You have to specify a folder to get the source code from because, when you build on a server, the build step is completely separate from the get step.
This behaviour in Visual Studio is provided when you open a solution, and it's a feature of the IDE intended to aid developers, but if you were building direct from the commandline you'd not get this help.
Related
I'm currently working on a large project with a lot of potential bugs and glitches. I enlisted a few of my friends to help me test the program to find potential bugs but a lot of them aren't very tech savvy and have no idea how visual studio works.
Is there a way I can compile my project so it could run as a stand alone executable? I tried building it and getting the vcxproj file but I still have no idea how to make that a click to run type of program. Any help?
As far as I'm concerned, there is no way to "publish" C++ code.
I suggest you could refer to the link: https://social.msdn.microsoft.com/Forums/en-US/6998eadb-36fb-4a97-bba5-0de49d533732/how-can-i-publish-a-visual-c-project-?forum=vsclassdesigner
If you want to make a stand alone .exe file. I suggest you could try to use "Release" to build a stand alone .exe file. Check the .exe program Configuration Manager, ensure your set Release for your .exe program. (open your .exe program under Solution Explorer, right-click solution and select Configuration Manager).
Is there a way to understand if a C++ Project has been Build previously in Eclipse?
I have to rebuild some projects sometime because I can not tell if it has been build before. And this process takes a lot of time.
Yes, you will get to know. when you click build and it was successful, and later you make some changes, and get error, you can go back to your last build configuration. You also can build it automatically, when you save.
I'm having a problem with Visual Studio not invoking msbuild to actually build my solution. Invoking msbuild from the commandline results in a proper build, but in Visual Studio starting build results in an "everything is up to date" message. Manually compiling a .cpp file seems to partially or fully fix the problem.
Restarting VS2010 does not correct the problem, so I feel like VS2010 must be writing its own dependency information somewhere. By dependency information I mean what files actually require building, AKA which files have been altered since the last successful build.
Does VS2010 perform it's own dependency checking before invoking msbuild? Where does it store this information?
To force a build to occur from the Visual Studio GUI you can select "Rebuild All". That will trigger compilation of all your source files.
The problem with regular builds not working could be related to incorrect clock settings in your PC. Make sure your system clock is correct, including the time zone. Then do a project 'clean' and try to build again.
My Dad says to check your "obj folder" and clean it out. VS2010 is seeing that there are things on there so it assumes there's nothing new to build.
I've seen this kind of behavior occasionally, though I can't explain how it gets corrupted.
Try deleting all the intermediate files: everything in the Debug and Release directories, plus the project name files of types .suo, .ncb, and .aps. Then rebuild all.
If you are experiencing the same behavior as I do, this tends to make VS work properly for awhile—a few weeks or 50-100 builds (whichever comes first).
So I have main.cpp and main2.cpp with int main in each. I want to get 2 exes out of it. Is it possible and what would be instruction to create such project?
Nope, Visual Studio's project model is rigidly built around the assumption that "one project generates one output".
If you need two executables, you have to create two projects. You can keep them in the same solution to make things easier for yourself, but they have to be separate projects.
Edit
Ok, as other answers have pointed out, it can of course be done, if you're desperate. You can add a custom build step, which does anything you like, including building another executable. (However, the build system won't understand that this file should be considered project output, and so some scenarios may fail: for example the file won't be automatically copied to the output folder, and when checking dependencies before a rebuild, it might not be able to understand which files to check, and what (or how) to rebuild.)
Visual Studio (at least up to 2008, not sure about 2010) also allows the use of nmake files, but then I think you're stretching the definition of "a Visual Studio project".
But under "normal" circumstances, one project implies one output. And in order to get two executables, you'd normally create two projects.
You need a solution which includes two projects. Have a read of the Visual Studio documentation on solutions and projects.
Here's my solution, since nobody in a Google search seems to suggest this method. It's quite simple and I've used/seen it used in other IDEs (like Code::Blocks).
Within your project, create a configuration for each output that you want. Then, only include one main source file in each configuration.
In VS, this means for each source file with main: right-click -> Properties -> Excluded From Build = Yes. So, once you're done, only one main source is built for each configuration. You can then specify a different output for each configuration in the Project Properties. I did this on VS 2010, but it should probably work with other versions.
I'm using this approach so that I can have several tests for one project, without cluttering the solution with more test projects than actual code projects.
I don't know if it can be done ,but the only change you have ,to do this ,is with custom build step.
EDIT: Since someone downvoted this ,i did a test making a dummy configuration.
In the custom build step I two Link-cmds (copied form original link-cmdline and modified it a bit) taking as input main1.obj resp. main2.obj and outputting App1.exe resp. App2.exe.
It's executed after Compiling and before linking.
It worked !
The downside is I cannot prevent (yet) the linking ot the orinal exe (which errors on duplicate main function).
Solution to this could be to have a lib project excluding the sources with main()from build and build them in the custum-step too.
So the answer to the question should : Yes ,it can be done!
You can't have more than one main() function in a single visual studio project. So you can't compile 2 executables, the only way is to make two different project in the same solution
You can create a solution with two project one for each output you want. Then head to Build menu and select Batch Build.. and select both projects.
If you want both exe files to be in one place you can specify a custom Post-build action:
For both project:
view the project properties page and in Build events select Post-Build events, then in the Command line field enter the command that will copy the output to the location you want, something like:
copy $(TargetPath) c:\yourlocation /Y
Then after you build the solution the output files will be copied to that location.
Another option you have is to use conditional compilation with sth like
main()
{
#ifdef VERSION1
call_main_logic();
#else
call_main2_logic();
#endif
}
and then define different configurations within the project. For each configuration you will then need to define preprocessor symbols appropriately (in: project settings -> configuration properties -> C/C++ -> preprocessor).
Please note, that it will be only one executable created at a time, but with switching configurations you'll get the one that does what you want at the moment.
... which may suit your needs or not, depending on more specific situation that you are in.
Edit: In addition, since different configurations create their separate output folders, you will have your both execs as outputs.
I have a project that builds fine If I build it manually but it fails with CC.NET.
The error that shows up on CC.NET is basically related to an import that's failing because file was not found; one of the projects (C++ dll) tries to import a dll built by another project. Dll should be in the right place since there's a dependency between the projects - indeeed when I build manually everything works fine (Note that when I say manually I am getting everything fresh from source code repository then invoking a Rebuild from VS2005 to simulate CC.NET automation).
looks like dependencies are ignored when the build is automated through CC.NET.
I am building in Release MinDependency mode.
Any help would be highly appreciated!
Can you change CC to use msbuild instead of devenv? That seems like the optimal solution to me, as it means the build is the same in both situations.
After a long investigation - my understanding on this at current stage is that the problem is related to the fact that I am using devenv to build through CruiseControl.NET but when I build manually VisualStudio is using msbuild.
Basically this causes dependencies to be ignored (because of some msbuild command arg that I am not reproducing using devenv).
I think the fact that dependencies are set between C++ projects is relevant too to some extent, since I've been able in other occasions to build properly with CC.NET setting dependencies between .NET projects and C++ projects.
In order to figure out exactly what is generating this different
behavior I'd have to follow this lead.
I'd like to hear other people's opinions on this.
Try building it from the command line and see what happens.
My guess would be that the user that the service is configured has different permissions and/or environment variables as you do when actually running it. If you are on the same physical box and it compiles fine with visual studio and you are also using visual studio in CruiseControl (not MSBuild) then it is almost assuredly the user. If however you are using MSBuild in CruiseControl there is a huge set of diffrence when MSBuild (2.0) compiles a C++ sln and when Visual Studio compiles it. If you must use MSBuild on C++ solutions try v3.5 it has much more support for C++ solutions.
I wonder if CC.Net is building with different environment variables, such that the necessary library directories aren't properly added to the path.
Is there any specific error message in the CC.Net build log as to why that particular DLL import failed? Could not find file? Permissions? Look in the detailed CC.Net build log for the failure and see where it differs from a normal command-line build.
I've run into instances where my solution builds if I open it in the IDE and compile, but fails if I run from a command line (either msbuild or devenv.) In each case, the problem was due to a bad reference - likely from paths not matching between your local box and the build server. You see it compile in the IDE correctly because VisualStudio, when opening a solution, will attempt to auto-resolve broken paths. When it does this, it won't tell you about it and usually won't change your solution and project files (which is what you'd hope for.)
Try opening your solution file and/or project files in a text editor and make sure all relative paths are valid.
As Alex said, I think that your problem is that the CC.NET service runs as a local user account. Unfortunatly some of the C++ environment variables are per user and will not be carried over to the default build environment. In my case it was the lib and include files defined in Tools -> Options -> Projects and Solutions -> VC++ Directories. This same issue evidently causes other issues and is called out in this article as a yellow block.
My solution was to create a new user (BuildUser) on the build machine specifically for building. The key was to then log in as BuildUser and set up the environment. Finally, I changed the CC.NET service to login as BuildUser and restarted it.
(reposting as my initial post seems to have failed)
VC2003 seems to have an inconsistency between dependencies and input libraries.
An example:
ProjectA --> A.lib
ProjectB --> B.exe
In Properties-->Linker-->Additional Input Libraries, A.lib is specified.
In Project Dependencies, ProjectA is unchecked (why it is not automatic is still a mystery to me)
When cleaning ProjectB, A.lib is not deleted, nor is it rebuilt when ProjectB is compiled. So the build appears to succeed in your local machine.
CC.NET starts from scratch, and the build fails as A.lib is not found in the first place.