I need to use cmake to generate visual studio sln file, BUT I want to ensure, that this generated *.sln file will not be connected with original CMakeFiles.txt (I want to generate sln file once).
I know that this is not typical usage and the connection with source CMakeFiles.txt is in standard usage perfect, but in my case it is not wanted -- I want to distribute these sln files (solution with projects) to some colleagues, who do not have CMake.
Maybe there is another approach (except cmake), to create few visual studio project without annoying clicking in Visual Studio.
Thanks,
Radek
I need to use cmake to generate visual studio sln file, BUT I want to
ensure, that this generated *.sln file will not be connected with
original CMakeFiles.txt
By design CMake will generate solution files that depend on CMake so this part is not really possible with CMake alone.
Maybe there is another approach (except cmake), to create few visual
studio project without annoying clicking in Visual Studio.
There is a way to stop regeneration in the IDE. I use this in many of my projects most likely for the same reason you do. At least with older versions of Visual Studio the regeneration caused dozens of prompts. Although I believe Visual Studio 2013 only prompts 1 time now I still enable this. The following code (inserted near the top of my root CMakelists.txt) is what I use to enable the option to suppress IDE regeneration.
option (CMAKE_SUPPRESS_REGENERATION "Suppress the cmake macro that causes regeneration of build scripts during build" ON)
Related
I was a CLION user for long, and until recently I switched to visual studio 2017 since CLION uses too much memory.
In CLION, basically I can cmake the whole project with the top-level cmake file and generates multiple targets to select from a drop-down button.
I did the same in visual studio except in visual studio I need to run the cmake first to generate a .sln file and open it in visual studio.
After open this, I can see different class instances(my targets) in the solution explorer, but I do not know where to specify which target to run. Each of my target has its own main function. Also, I have integrates all my targets into a top level object called BUILD_ALL. I can build this build_all which builds all of my individual target. But still i dont know how to run each one.
I tried by using the right-click and start a new instance, but it rebuilds the target everytime which is not wanted. In Clion, this is not a problem.
Could someone help on this?
Thanks in advance.
I would suggest using the Set as Startup Project option. This will make it so the build and debug shortcuts target the selected project.
Right click on the project in the solution explorer and choose Set as Startup Project
Another option is to just build and or debug the project directly from the right click context menu.
Depending on how much you work with CMake and Visual Studio you may want to look into VS_STARTUP_PROJECT
Lately we (the team I work with and myself) have been seeing something strange between the build results of MS-build and Visual Studio (2015).
The situation
The team I work with has been tasked with refactoring an older and rather large c# project that contains many (150+) projects all bundled into a single sln file. As to be expected merge conflicts occur in the sln file during our work and one of the team members resolved this conflict incorrectly. Leaving the sln file with a missing project reference.
From here on out the behavior of the project is different on 3 location. They are described below
Visual studio of the developer that origionally made the mistake
(note that I assume that this developer has not cleaned his solution)
This programmer has already build and run the project (using visual studio 2015 professional). So all compiled dll files are in the prorammers output folder. This means that Visual studio does not notice that a reference is missing. The programmer can build, run and test the application without any problems.
The build server
The build server (Jenkins) does not run Visual studio, but it uses MS-build 14 to compile the source code. The Jenkins server is configured to run with pipelines, described in groovy. We call ms build by invoking a bat script that runs MS-build over the command line. An example:
"C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\msbuild.exe" "TheSolutionFile.sln" /property:Configuration="Debug" /property:Platform="Any CPU"
Somehow the build will succeed even with the incorrect sln file. I suspect that ms build resolves its own dependencies as the workspace on the buildserver is clean (completely empty) so no leftover dll's can fool the system. (am I correct in assuming this?)
The other team members
The other team members will eventually pull the changes of the broken sln file and they will be in for some 'fun'. When you do not have the dll files in your output folder Visual studio will attempt to rebuild the missing dependencies. But since the references cannot be resolved it will fail and start stacking errors about missing meta data. In the team we all use Visual studio 2015. But we also tried it with 2017 and ran into the same result. The person who originally made the mistake can also end up in this group of he cleans the solution.
The Question
Obviously we are not happy with the fact that the build server accepts the build with a broken sln file (a developer pulling the latest version cannot compile or run the program). Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile)
Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile
That is because MSBuild.exe from command line does not have the same build environment as Visual Studio. You can call MSBuild.exe from VS command promt which has the same biuld environment as Visual Studio.
If you want call ms build by invoking a bat script that runs MS-build over the command line, you can use devenv.exe to build the solution/project from command line:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE>devenv "D:\TestSample\TestProject\TestProject\TestProject.sln" /build Debug /project "TestProject\TestProject.csproj" /projectconfig Debug
For the detail information about devenv.exe you can refer to Devenv Command Line.
Hope this can help you.
My advice:
The .sln file is just a collection of project files. Create a brand new one, and add in your proj files one by one. Forget the code-merge-conflict-resolution drama.
The voodoo in the .sln file is too much voodoo. Let VS do it for you...as you add each project in, one by one.
File / New / Project ::: Installed / Templates / Other Project Types / Visual Studio Solution ::: Blank
Solution.
One other hint. If you still have issues, then open up each proj, and any "by project" references, delete them and re-add them. Sometimes the GUID's get mixed up, especially over a long code-merge history.
Suddenly, after doing a TFS 2010 get, Visual Studio 2010 is attempting to compile my .tt file as if it was c#.
Moreover, anytime I set it to "Build Action=None", Build Action gets mysteriously reset to Compile. This is breaking our builds on the desktop. I can get builds to work on the desktop by closing then reopening VS.
Our builds on TFS are totally broken because of this. What to do?
The template generates a (totally ok) c# file, so I need the project to build.
I tried changing the file extension from .tt to .donotbuilddammit but that had no effect.
Are you by chance using the Clairus T4 plugin (or another T4 intellisense provider)?
If so, try making sure the files are not open when you change the BuildAction setting.
Visual Studio builds intellisense
based on the compile action of your
files. It will only provide
intellisense for files that are marked
as "compile". Because of that, we
change the build action when the file
is open, and we change it back to
whatever it was before when checking
in, closing the file, closing Visual
Studio and also when opening Visual
Studio (in case it crashed)
See: http://forums.clariusconsulting.net/viewtopic.php?f=12&t=445
I've got about two dozen projects here in one solution that need changes to the include paths. I can go through and change each one, but what's really annoying me right now is that it looks like I have to change each one four times (debug vs. release, win32 vs. x64). Is there an easier way to do this than changing the include paths about 96 times?
As it happens, there's nothing special about the x64 configuration in these projects. Would there be some way to copy the changes from the win32 configurations, preferably copying in multiple projects at once?
Open *.vcproj project files as text files in Visual Studio editor and execute "Find and replace in files" function. Visual Studio project is actually plain XML file.
Google reveals many tools for taking Visual Studio format sln/vcproj files, and producing a make file from them. But I can't find one that solves the opposite problem - I have a make file that references hundreds of .c and .h files and (for convenience, for debugging, for writing code in the VS IDE) would like to open it as a Visual Studio project.
Where can I find a tool to take an arbitrary make file as input, and produce Visual Studio project/solution files as output?
Makefile Project Wizard
You might be able to find a converter for a well-constrained set of makefiles, but a converter for any arbitrary makefile would be tricky. They are mini-programs, after all, that would have to be evaluated. And not all makefile concepts map directly to Visual Studio projects.
If you only have one project to worry about, I'd just manually put together a project in Visual Studio (tip: you can select more than one file in the "Add existing file..." dialog). If you do this regularly, perhaps look into a tool like Premake or CMake to help automate the generation of the projects (and if necessary, a new Makefile) for you.