I'm using Visual Studio 2010.
A sloppy project refactoring left 50% of my project header files listed as external dependencies.
Is there any way to get a list of the "external dependency headers", and move the ones in the project directory to the Include Files folder?
Related
Is it possible to add nuget content files to a project as a link from the packages folder. Like it works for assembly references.
The background is that I have several projects which include the same set of files (various types). I don't want these files in project folder and the source control tree.
Currently we use the "add as link" feature in Visual Studio to a common folder.
Is there any way to instruct Visual Studio 2010 to keep my .h files and .cpp files separate from the project files and databases that VS generates to manage the project? Specifically, I would like to have a set up where the project files are in the VS install folder and the source files are in a completely separate folder in my Dropbox, and monitored by git.
You can put the .cpp and .h files wherever you want. A project file just lists the locations of the source files. Create the .cpp and .h files where you want them, perhaps with Notepad, and then use "Add Existing File" to add them to the project. (Right-click on the project name in Solution Explorer and choose "Add Existing File".)
Source files are represented in the project file using relative paths, so if both the sources and the projects are on the same disk drive, the sources will be represented something like "..\..\..\..\MyFiles\work\SuperCalc\Input\parser.cpp". If they're on a different drive, then they'll use absolute paths like "D:\MyFiles\work\SuperCalc\Input\parser.cpp".
A detailed example of a source file and build file layout which uses this technique is presented in this StackOverflow response about organizing Visual C++ source files. You may find it helpful.
As an aside, if you really want to store your project files in the VS install folder, which is under C:\Program Files\Microsoft Visual Studio 10.0", then you'll need to run VS in Administrator mode, because C:\Program Files is a protected directory.
Im setting up a svn repository and wondering where i should put the dll files.
What Ive currently done is put them in the /bin/debug folder and then link them in my project file in visual studio.
is this the way to do it?
I presume you are asking about third party dll files, because the output (exe/dll) files generated by the project are better left unmanaged by SVN, because they are regenerated on each and every build.
What I usualy do is create a Lib folder, that is on the top level of my source tree, and put all needed references there, usually in additional folder divided by tool or by functionality (logging, emailing, apis, etc, etc...)
You should not put anything from the bin/Debug or bin/Release in your source control. If you do that, you will lose them when you clean your solution or your projects.
What you have to do is create a folder, within the solution folder for example, and reference the dlls in your projects. Any third-party dll that is in the references of a project will be copied to the bin/Debug or bin/Release folder when the project is compiled.
We typically have a seperate folder called dlls or something where we keep all 3rd party dlls/assemblies
Dlls are only needed at runtime. For a quick fix, you may copy your dlls in the Debug folder where your .exe file is. This Debug folder is at the same level as the solution .sln file in Visual Studio. Which thing you will have to do each time you start a new project... Debug folder
A better solution would be to copy all third party dlls, plus all the corresponding .h and .lib files, in 2 folders, say C:\dev\include and C:\dev\lib, and then add these 2 folders to your path environment variable once for all. This way, you'll be able to access them from all your projects, without having to copy them over and over.
Now, if you want someone to be able to run your project on another computer, you'll need to copy all needed .h, .lib and .dll files in your project in a separate folders that you create, say include and lib again, in your project directory where your own program files are, as mentioned in the previous posts. Project folder
PS. Sorry, it would not let me upload the 2 screenshots, so click on links.
I typically put it in a Lib folder within my Visual Studio project solution folder. I would also create sub folders all the way to indicate whether the dll is for a 32 bit or 64 bit build and also which version of Visual Studio was used to build it. So something like this: Lib\WIN32\VC2015\ . Then in the Project Properties of the project, under the Debugging Configuration Property, I set Environment to
PATH=$(SolutionDir)Lib\WIN32\VC2015;%PATH%
By doing this, I can have separate dll folders for different project configurations if I want to and also the dll files are in a good place to check into source control as well.
If a VS2008 project is created initially with a web app project, and class projects are added, and the structure is like this:
Parent Folder
Web App Project Folder - (solution Files in this folder)
Class Project 1
Class Project 2
...
do you see any problems with moving the .sln and .suo files to the parent directory?
Parent Folder - (solution Files in this folder)
Web App Project Folder
Class Project 1
Class Project 2
...
I adjusted the .sln project directories and the solution seems to be working fine, but I'm wondering if this action will break something I didn't anticipate.
Only the project files determine their build outputs - solutions only link projects together into a logical entity, so that they can be loaded at the same time in a Visual Studio instance. If the projects are still the same, nothing's broken.
And the .suo file can be safely deleted. It's a user-specific file that simply retains a particular user's options for a solution. It contains nothing that's important to projects, build settings etc.
You can open your .sln file with whatever editor you'd like, even notepad, and see that it contains only references to your project files in it, you can modify it so that the relative paths to your project files in it match your layout. VS wouldn't have anything against it.
All build settings are stored in project files, so you don't loose any configuration changes you've done in your projects.
This has to do with source control, I'm using VSS and the Visual Studio 2008 plugin. When the DLL of a referenced project gets included in a project (and checked into VSS), on the next build it will fail because those files aren't checked out as part of the build process and will be read only.
I could exclude the entire bin folder and all dlls, but that is where I put my static dlls (ie. the ones that aren't rebuilt as part of the solution) and interestingly, Visual Studio treats dlls other than outputs of other products as excluded files just fine.
In VS2005, the VSS plug in didn't automatically add the output of referenced projects as files pending check in, but in VS2008, it does.
Anyone run into this issue or find a work around?
It's better to not check in the bin folders at all. Move the dependencies to a common lib folder, and reference them from there. That will make sure they're copied into the bin folder. You can then explicitly check in this lib folder.
Other files/folders to avoid checking are the obj directory and the ncb file. I'm not sure how "smart" the VSS integration is in this case.