I'm building a project that includes my own source code, but also includes a number of thirdparties e.g googletest. I'm including third parties as source and adding them to my own CMakeLists.txt (via add_subdirectory) file so they get built alongside my libraries.
Is it possible to exclude the thirdparty projects from the generated Visual Studio solution? I don't want developers of my own code to see the thirdparty projects/source when they open the solution, I just want it there at build time.
I'm aware I can move them so a separate folder in Visual Studio using the FOLDER property, but ideally don't want them showing at all.
Related
I am building a "Solution" consisting of many small "Projects" within VS-2015.
To ensure consistency, I would like to set Project preferences such as additional include directories, additional libraries and platforms from one location or copy from one project to the next.
Could you please point me to a document that describes this?
Thanks in advance.
Since all projects are based on MsBuild, you can create a single targets file which sets the properties you want to sync across your projects. You can then import this targets file in every one of your project files.
To add a targets file you'll need to edit the csproj file directly (Unload project, edit project file in VS or through a 3rd party editor).
There are also some options like Directory.build.props and Directory.build.targets files, in Visual Studio 2017 these are automatically imported during your build and that gives you the advantage of not having to edit the project files. This may require MsBuild 15, which ships with Visual Studio 2017.
Some Visual Studio UI will be able to show the current value of certain properties, but editing them in the UI will pull these values back into to project files. This is an unfortunate behaviour of Visual Studio.
For all options to import targets files see:
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017
Here's my specific scenario: Using VS2010, Pex and TFS2008, generated moles files are getting automatically added to source-control (TFS).
Pex adds a "project_name.moles" file to your test project and then autogenerates 3 files at build time: project_name.Designer.cs, project_name.Moles.dll, and project_name.Moles.xml. I want to keep the *.moles files in TFS (it's source code) but I don't want the 3 generated files to be in TFS (they are still part of the project, but they are generated when first built on a new system).
There are two reasons I need this behavior:
1. It's not a good idea to store generated code in source-control (let's not debate the merits of that here).
2. Specially, the DLL file is BAD because every time someone builds, all moles files are regenerated and thus all files are checked-out and DLL files are checked-out EXCLUSIVELY (non-mergable) and so other people can no longer build on their local box.
The Pex/Moles team are working on this but the solution is still likely several months away.
Is there a csproj property that can be assigned to these project files so that they are in the project but not managed by version control? I don't mind hand-editing the csproj file.
Moles will not be adding any files to the project in the next version (v0.94). It will use MSBuild to generate the assemblies on demand.
I think it depends more on the version control tool than Visual Studio, as usually you can set up some kind of filters in your version control configuration in order to exclude some files/paths.
E.g. if you use Mercurial/Hg, you can (and should) edit your repository .hgignore file and specify e.g. to exclude all *.moles files and the whole sub-tree MolesAssemblies\*. I guess other version control systems have similar options.
My dev environment at work consists of a Visual Studio 2005 Solution with many sub-projects (by "project" I always mean VS project). Some of the projects build libraries which are used by other projects. By convention, a fair amount of test-related code ends up in header files which end up getting modified frequently. I've noticed that when I hit F7 to Build the solution, Visual Studio does not detect changes to header files that are in library projects. It will report that everything is up to date when it's not. To force it to rebuild the libary, I have to change (touch) one of the .c files in that particular project, or do Rebuild All which is quite slow.
Is there something I can change in the Solution or project settings to change this behavior so Build works as expected? I've actually gone so far as to hack together a script that "touches" one of the library .c files in a library when it detects an .h file has been updated, but there has got to be a VS solution to this.
Are the header files actually members of the library project - not just in an include file search path?
I have several Visual Studio web application projects that include SVN externals. When a new file is added to an external module, VisualSVN brings it down to the file system, but doesn't add it to the Visual Studio project; it has to be manually added.
I might write a macro to automate this process, and I'm wondering if I can make it a one-step process by either:
Having the macro initiate the VisualSVN update, then do the work (Q: Is it possible to trigger a VisualSVN update from a macro?)
Hooking into a hypothetical "post-update" event from VisualSVN to fire a macro to do the work (Q: Does such an event exist?)
I assume you are currently working like this: your "external modules" are just a loose collection of source files without a project file. Whenever a source file is added, you update all your application project files by adding the new source file, so that it is compiled into all the application assemblies.
I think you are doing it wrong. Your project solution file should contain a reference to a separate visual studio project file for each external. Each source file should be compiled into exactly one assembly.
For example, you might have a C# library shared between multiple web applications. This library has its own .csproj project file, which lives in the external location. If a source file is added to the library, the .csproj is updated. The updated .csproj file is then pulled it via an svn:externals declaration when you update your project.
I checked in a project to SVN with about 15 references from one dev box then checked out the same project on a second dev box but most of the reference files are missing. Is it possible to checkin the reference files automatically?
Version control will only keep track of the actual files underneath the working folder. If the third party libraries are installed elsewhere on the machine, they will not be included in the source control at all.
You'll have to do one of these:
Ensure that the 3rd party libraries (eg, nunit, enterprise libraries) are installed on all required development machines.
Don't install the libraries using the normal installers at all, instead, add the individual dll's and other resources to source control as Vendor Branches, then bring them under your project by either branching them into your project location, or by adding an svn:externals definition.
Copy the required reference files under into your source locations, add them to source control and reference them from there.
I think it's hard for Visual Studio SCC tools to determine wether or not these files should be automatically added. If you're using the first scenario Jim T described, you definitely don't want that to happen.