Import Existing C++ Source Code into Visual Studio

Question

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)

Solution 1

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.

Solution 2

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...

Solution 3

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!

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[pinvoke]

John: There are hundreds of existing cpp files-- that is the approach I have already tried. Each folder needs to be treated as a separate lib/dll (and there are like 30+ folders)

[John Dibling]

@pinvoke: to paraphrase a sucky 80's band, "porting is hard to do."

[Michael Burr]

This sounds quite interesting to me. How complex are the python scripts and whatever supporting 'templates' you might need?

[wip]

"The directory structure of my code was retained." I tried it, all my files were "flatly" listed under the "Source Files" filter.

[martinako]

After trying for a while I was about to give up on the idea of importing the source tree automatically. I found the same, the files were flat under the "Source Files" but then you press the "Show All files" button and they switch to the same tree structure as in the file system, if you press that button again they go back to flat structure.

[android927]

This doesn't work. Visual studio just dumps all the .h files into the "Header Files" folder and all the .cpp files into the "Source Files" folder. It does not preserve the folder hierarchy at all.