I am using CPPCheck with the visual studio plugin. In the settings menu for it there is a an option 'Edit Global Suppressions'. What I would like to do is use the option 'File excluded from check (C# regex)' to stop cppcheck from looking through a large single-file header-only test framework file I am using called Catch. When I run 'check current project with cppcheck' I have to wade through a large number of messages from code I didn't write, nor am interested in fixing.
I am not good with regex but I have tried a lot of combinations to get it to ignore this file without success. Is there an obvious regex statement I haven't come across or is this feature not working. I didn't see an issue in the VS plugin repo so I'm willing to bet its just me.
P.S. The file is stored in the usual place for a visual studio C++ project:
D:\Libraries\Documents\Visual Studio 2015\Projects\ReliableControls\ReliableControls\catch.hpp.
Here is a short list of entries I've tried... that I can remember. (ReliableControls is the name of the project).
^ReliableControls\catch.hpp$
^ReliableControls\catch\.hpp$
^catch.hpp$
^catch\.hpp$
EDIT
Here is the list of the defaults in the exclude file window. I've tried following similar patterns.
^moc_.*\.cpp$
^qrc_.*\.cpp$
^ui_.*\.h$
So, we are in this process of migrating XAML Builds to vNext (2015) Builds on TFS, and we are trying to "do things as clean as possible", since we had many, many customizations on the XAML builds that could be avoided and actually gave us problems along the way.
One major issue we are facing is with paths and "global files". Let me explain:
There are some files that, for commodity reasons, we have on a single place and every SLN file on that Collection refers them. Those files are such ones as Code Analysis RuleSets, Signing Files (SNK), etc. So the change is made in one place only and it affects every build.
Well, in XAML Builds we have a Build that runs with CI that downloads (Gets) those files, and since we hammered-in the same exact pathing for TFS and Machine (with a environment variable for the beginning of the path), the path is the same on the Developers and Build machines. However, this creates dependencies between builds and workspace issues.
My question here is, is there a configuration that I am missing that allows referring to files in other branches other than the build one? Since I’m trying to keep the build machines as “disposable” as possible, it’s running with an Agent Config Out of the Box: No custom paths, no hardwiring.
I already tried referring the files directly with their source control path, for example. The only options I’m seeing are either creating a PowerShell/CMD Script that downloads those files right into the same folder as the SLN or keeping it “as it is” and use relative paths putting a “Build” Build Step before the actual Build Step so it downloads the files to the server.
Isn’t there an “Elegant” way of doing this? Or is our methodology wrong from the get go?
You can add a Copy Files step to copy the files that the build needs:
I'm working on transferring our old C++ codebase from the Perl-based build process we were using (I know, I know) to a custom TFS build. One of the things I need to do is edit a version.h file that bakes some version info into our code.
However, when I create my workspace and try to edit any of the files with a custom activity of mine, it reports that the workspace is write-only. How do I remove this restriction? I can see that Activities.CreateWorkspace has a security option, but I can't find any good documentation on how I can use that.
Any TFS gurus willing to help me out?
You can use the "File" activity from the TFS Community Build Extensions to toggle the read-only flag on the file(s).
Alternatively you could create your own activity from their source.
As part of a test process, I'm trying to create an empty MSBuild Platform Target for MVS 2010 whose only job is to call a batch file when I click "build". I want to completely ignore the build and link process of the c++ files, just call a batch file (perhaps with the post-build events?).
So far I've duplicated the Win32 platform at \MSBuild\Microsoft.Cpp\v4.0\Platforms and named it "TestPlatform", and started hacking away at it and managed to disable the build step, but it, quite reasonably, fails during the link step when it cant find my SampleProject.o file that the build file did not generate.
I've ordered the book "Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build" book by Hashimi and Bartholomew, but while it gets here I would appreciate if anyone has any words of wisdom on the subject. Specifically:
1 - How do I bypass the link step.
2 - How do I add a custom step to call a DoSomething.bat file instead
Thank you for your help :)
For my particular case, I found that adding a copy of the C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32 platform (C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\TestPlatform) and adding the TestPlatform to my project configuration was enough to bring out the TestPlatform tab in the Configuration Manager dropdown menu.
To make it not compile or link anything but still run postbuild events the easiest way is to select in project properties:
Configuration Properties / General / Configuration Type : Utility
This seems to bypass all building steps but does call the postbuild events, where I simply put a call to a batch file.
It's not exactly what you are proposing, but a different way of achieving some of the same results is found here: run a custom msbuild target from VisualStudio
That shows how to wire up a command in the IDE to call a custom target in your project. So you could wire up an IDE command to call your RunThisBatchFile target in the current project.
Alternatively, you could override the rogue targets with a condition, something like:
<Target Name="Link" Condition="'$(Platform)' == 'TestPlatform'">
...
You may need to find a bunch of these and I'm not sure if it is 100% possible to get around the InitialTargets that may be defined for a C++ project file.
This is all covered in "MSBuild Trickery"
I am trying to import an existing c++ application's source into visual studio to take advantage of some specific MS tools. However, after searching online and playing with visual studio, I cannot seem to find an easy way to import existing c++ source code into visual studio and keep it structurally intact.
The import capacity I did find flattens out the directories and puts them all into one project. Am I missing something?
(This is all unmanaged C++, and contains specific builds for win/unix)
With no project/solution loaded, in Visual Studio 2005 I see this menu item:
File > New Project From Existing Code...
After following the wizard, my problem is solved!
Switching the "Show All Files" button shows the complete hierarchy with all directories and files within.
If the New Project From Existing Code... option isn't available, you'll need to add it in Tools > Customize...
I am not aware of any general solution under the constraints given - specifically having to create many projects from a source tree.
The best option I see is actually creating the project files by some script.
Creating a single project manually (create empty project, then add the files),
Configure it as close as possible as desired (i.e. with precompiled headers, build configurations, etc.)
Use the .vcproj created as skeleton for the project files to be created
A very simple method would file list, project name etc. with "strange tokens", and fill them in with your generator. If you want to be the good guy, you can of course use some XML handling library.
Our experience: We actually don't store the .vcproj and .sln in the repository (git) anymore, but a python script that re-genrates them from the source tree, together with VS 2008 "property sheet templates" (or whatever they are called). This helps a lot making general adjustments.
The project generation script contains information about all the projects specialties (e.g. do they use MFC/ATL, will it create DLL or an EXE, files to exclude).
In addition, this script also contains dependencies, which feeds the actual build script.
This works quite well, the problems are minor: python requried in build systems, not forgetting to re-gen the project files, me having to learn some python to make adjustments to some projects.
#Michael Burr "How complex are the python scripts and whatever supporting 'templates' you might need?"
I honestly can't tell, since I gave the task to another dev (who picked python). The original task was to provide a build script, as the VS2008 solution build was not good enough for our needs, and the old batch file didn't support parallelization. .vcproj generation was added later. As I understand his script generates the .vcproj and .sln files from scratch, but pulls in all the settings from separate property sheets.
Pros:
Adding new configurations on the fly. Some of the projects already had six configurations, and planning for unicode support meant considering doubling them for a while. Some awkward tools still build as MBCS, so some libs do have 8 configs now. Configuring that from hand is a pain, now it just doesn't bother me anymore.
Global changes, e.g. moving around relative project paths, the folder for temp files and for final binaries until we found a solution we were happy with
Build Stability. Merging VC6 project files was a notable source of errors for various reasons, and VC9 project files didn't look better. Now things seem isolated better: compile/link settings in the property sheets, file handling in the script. Also, the script mostly lists variations from our default, ending up easier to read than a project file.
Generally: I don't see a big benefit when your projects are already set up, they are rather stable, and you don't have real issues. However, when moving into the unknown (for us: mostly VC6 -> VC9 and Unicode builds), the flexibility reduced the risk of experiments greatly.
Create a new empty solution and add your source code to it.
For example,
File>New>Project...
Visual C++>Win32>Win32 Console Application
Application Settings>
- Uncheck "Precompiled Header"
- Check "Empty Project"
Project is then created. To add existing code:
Project>Add Existing Item...>
- Select file(s) to add
Recompile, done!
In the "Solution Explorer" you can click on the "Show All Files" button to have Visual Studio display the files as they exist on the file system (directories and all).
In my opinion this is an imperfect workaround, but I believe it's the best available. I'm unaware of a plug-in, macro or other tool that'll import a directory into an actual project with folders that mirror the file system's.
I know this question is already marked correct, but I was able to import existing code into a project with Visual Studio 2008 by doing "File" -> "New Project from existing code". The directory structure of my code was retained.
You can always switch view from project menu
For eg. Project->Show All Files
The above will display the files in unformated raw file system order
Not sure of older versions but it works on VS 2010
I understand you, I have the same problem: many .cpp and .h files organized in many folders and subfolders with include paths written for this folder structure. The only way you can do to import this folder structure together with the source files is to use "Show All Files" and then right-click on folders and select "Import in Project". This works for me when I am using C-Sharp projects. But it does not work for my C++ Projects. I am still searching for a solution...