I have used visual studio 2010 express for a while and have played with some extensive projects for quite some time. Since i'm nearing 50-60 files and thousands of lines of code, i've decided to do some source control for everything so that the project is more easily updated and accessible between all my devices, while also being back up.
I have used git before and am comfortable with it, but now when i made the commit and pushed it to a remote repository on bitbucket.org, i found that the .vcxproj files, while still retaining their correct file structure, also retained the include and lib directories for the device it was pushed from, meaning that when pulled down to another computer, those include/lib directories would be looking in the wrong directories, meaning i have to revise all of them every time i pull/push.
My question, Is there anyway i can push files to the repository such that the solution keeps the folder setup, but not the include and lib directory settings?
Edit:
After some research, i went looking into these so called property sheets in visual studio which are files that can be added to your project. The settings you set their take precedence over the settings of the project, but then the snag there is, if you add the individual property file to the project and then push the the .sln file, and the various .vcxproj files without that .props file, and then someone else clones from the repository, it won't open because it apparently requires that props file.
What i would like along these lines is a default .props file in the remote repository that, when cloned over, is no longer tracked, and then that user can just edit it for themselves. I don't know enough about git thought to make this happen. Does anybody have an idea?
I'm not sure what your problem is exactly, but here's my understanding:
Your project files contain absolute paths (e.g. "C:\myproj\include"). Replace these with relative paths (e.g. ".\include"). The "$(SolutionDir)" variable helps: if your solution file is C:\myproj\myproj.sln, then "$(SolutionDir)include" is the same as "C:\myproj\include". You can change the include and library directories in Project Properties > Configuration Properties > C/C++ and Linker, respectively.
Your project requires third party libaries - such as boost - and these are outside your project, say C:\boost. Unfortunately Windows/VS doesn't have a standard location for third party libraries, so you can either:
Include the library in your project. This is perfectly fine for small libraries, but it's not something you'd want to do with something like boost, which is both big and tends to be used widely.
Mandate that all devices set up these libraries in the same location, e.g. C:\sdk
Use an environment variable, like $(SDK_DIR) in the project, and all devices must set this environment variable.
Let me know if this helps.
What you're after are git's smudge and clean filters. You'll have to write a script for the cleaning, but sed'll probably do the job just fine, you won't need real xml parsing.
Related
I am trying to link to a folder that is not inside the project directory. To give an example,
If my project is in C:\project and I have a folder C:\shared, how can I manage to link C:\shared into the project (and being able to edit/view the files in Solution Explorer) without making a copy of the directory and placing it into the project directory.
I need this due to the fact that many projects will use this folder and it would be ideal to have them edit/use the same files rather than copy the folder into each project individually. That way if a bug is fixed in one project, all other projects will now use the fixed files as well.
For more context, this is a C++ project using Visual Studio 2019.
What I've tried/considered.
Additional include directories
Problem: This does not show the files in the Solution Explorer
Dragging/dropping the folder (or copy/pasting) as seen in another StackOverflow thread.
Problem: This just crashes my visual studio completely. The folder is quite large so I assume that's related to why.
Appreciate any insight on how to proceed. It's really unfortunate that this is a pain, I would think that something like this would be common, but all the posts I've seen related to it have either gone unanswered or could not be applied to my situation.
Thanks.
Shared Projects are the key here.. I just found out they existed. After creating one, drop the folder/files in the same directory that has .vcxitems file. Now in the project you want to include the shared folder, right click your solution, Add -> Existing Project and select your .vcxitems file.
Adding the libs in the source control and adding the correct paths to the Visual Studio solution does absolutely nothing. My local project compiles fine, but the online CI compilation fails every time.
LINK(0,0): Error LNK1104: cannot open file 'xxx.lib'
I've tried any possible combination of relative paths and settings that work in VS2015 at this point. The documentation is really scarce and all I was able to find was some ambiguous advice around TFS project files (which I don't have, because the repo is a remote GitHub repo) and workspaces (which I don't know how to set up). I'm also aware of this "NuGet" package thing, but I'd rather not have to construct an entire dedicated package for a couple of library files that I already have in the directories.
I can't believe there really just isn't a simple setting to include third-party SDKs though. Even including the libs in the source control is bad practice, so I might have missed something pretty big here. Any advice?
Following is my folder structure in local and VSTS:
In my local machine, lib file is placed in "test" folder under "MyCon" project folder:
The folder structure is almost the same after added into source control:
Path in Linker:
Settings if the lib file is in solution folder:
I have a project in VC++ MFC and works fine with the .mdb files. But just copying the project's .exe file on other system does not let the project work as it searches for the same path as mentioned in the code for the .mdb files and fails to find one. Also, apart from .mdb files, theres a need for certain .ocx files and io library suite to be registered in the system prior to the project's execution. How to overcome this problem?
You need to wrap up all the files into a package also known as installer. One of the most popular (and free) at the moment is Inno Setup. This will produce a single exe file that you will be deploying to users / other machines. You need to make sure that you include all the needed files, libraries etc in your setup.
This might be a silly question but I am still learning. I have read several books on creating application and creating a good directory structure. When people talk about creating a directory structure, do they mean the folders you make within the solution explorer (folders you actually find inside of a .sln file) or do they mean setting up and creating folders that reside in the same folder as your .sln file or your compiled application (.exe). I figured the solution explorer folders are different from a typical windows folder cause the folders I create inside my .sln file are no where to be found on my windows system.
Visual Studio has a strange way of dealing with "folders" in solutions. A "Solution Folder" is not actually a physical folder, but more of a virtual folder managed by Visual Studio. Your files may end up in the root directoy, but VS will treat them as if they are in a "folder." This is configured and managed in the VS .sln or project file.
I'm not a fan of how this works in Visual Studio, I don't get why they don't just put files in physical folders. It's up to you whether you want to fight VS and try to keep your files in physical folders, or if you want to just let VS manage it, but ultimately, it really doesn't matter.
a typical directory struction will be like
bin (binaries)
Src
->.sln
->common
->.prj
->Project1
->.prj
->Project2
->.prj
Lib (3rd party lib's)
Doc (documentation)
Tools (3rd party tools)
Setup (setup projects)
Test (test cases)
With C++ in Visual Studio your solution directories need not match the filesystem, but they can.
Typically people refer to the directory structure as the filesystem layout of the project.
It's typical to have visual studio directories called headers and source, you wouldn't lay your project out like this on your filesystem though.
Visual Studio directories aren't just virtual folders though, they can contain filter rules so when you add a file to your project it will automatically get added to the correct filtered folder. They can also specify whether the folder should be under version control or not. And whether they should be parsed for auto complete or not.
Typically on filesystem I will create 1 folder per project and rarely create subfolders inside an individual project. But in the solution explorer I will create top level folders which I put projects into (For example: "Server Components" and "Client Components"), as well as in project folders to group things logically together (For example: Config, GUI, Controllers, ...) so I can find what i'm looking for faster.
Inside .vcproj files There is a list of all source files in your project.
How can we use a macro to specify the path to a source file?
If we do this:
<File
RelativePath="$(Lib3rdParty)\Qt\qtwinmigrate-2.5-commercial\src\qmfcapp.cpp">
</File>
The compiler cannot find the folder:
qmfcapp.cpp
c1xx : fatal error C1083: Cannot open source file: '.\$(lib3rdparty)\qt\qtwinmigrate- 2.5-commercial\src\qmfcapp.cpp': No such file or directory
As you can see, our project compiles in several source files from QT. QT lives inside a folder of external libraries, and we don't want hardcode the path from our project to that folder (we have a very large solution)
The normal solution is to include the 3rd party includes, libs and source in source control with your own source, so you can track changes to your 3rd party dependencies with your source.
If this is the case, you should be able to use a relative path from each project to the 3rd party source files.
However if your solution is big, and it has project complicated settings you should look at CMake, even if you are only building on windows. CMake enables you to describe your build environment with common settings specified in only one place. More complicated cases can be handled with variables and macros. Then it generates your visual studio projects, or makefiles from this description. We introduced it to support a unix port, and now I use it for windows only development too.
VS projects are really clunky to use, opening and closing dialog boxes, setting things for debug and release. Each project with its own copy of the settings, but mostly the same as all the other projects.
If you add an existing file from a different drive, you'll notice an absolute path is used.
At least for v8.00, macros do not seem to be expanded. I tried VC, Ant, and OS macro forms - none worked.
There's always the sysinternals' junction option, a mapped network path, or a .lib with a macro spec set into the project/global source, include, and lib paths. Even with the lib package, you should be able to step into the source.
Try setting an environment variable for 'Lib3rdParty' to the appropriate relative path snippet.
..it should be mentioned that using property sheets gets rid of a lot of the clunkyness though