I'm using Visual Studio to code a C++ program, with its source repository managed by SVN. I'm trying to have the solution compliable on multiple computers. The problem is, the libraries and include directories differ on both computers.
For instance, on one, the libraries are in (for instance) e:\devlib\boost_46_1\libs\regex\build, E:\devlib\SDL-1.2.14\lib etc and on the other computer in c:\programming\lib\boost_46_1\libs\regex\build and c:\programming\SDL-1.2.14\lib
Likewise for includes - which have the added layer of complication as to needing to retain the folders in the #includes in the actual source code (such as #include )
How do I structure my folders/source/vs solution/computer to make the solutions be able to compile on any of my computers without me having to separately list the library folders and maintain different project/solution folders for each?
I do understand one potentially valid solution to be include the libraries in the folder structure of the source, so that all the library folders can be, for instance "../libs" and "../inc" or something. However, given the sheer size of (for instance) boost, this solution is undesirable - especially with source control.
Place any third party libraries into a folder in your solution, place under source control and reference from this solution rooted folder.
Don't worry about the size; since these won't change that often, you will retrieve them infrequently.
Related
I'm learning Visual Studio 2015 Community. I'm a seasoned programmer, but new to VS, and the file representation is confusing me. I've created a solution, and added an existing project. VS is showing me all project files (In my case a C++ project, so .c, .cpp, and .h files) on one tree level in Solution Explorer.
In contrast, if I open said project in something like Sublime Text, VS Code, notepad++, or the like, I see the proper directory structure as it sits on the disk drive; as one would see it in File Explorer/Finder or ls/dir in a terminal.
I have done my homework before I posted, and in the following thread, #Andrey states:
I am afraid there is no such concept in MSVS like "directory
structure". Moreover, MSVS doesn't really need it because it uses flat
projects and hierarchies are based on project level, not on the
file/directory level.
As there is no such thing - you can't have it neither automatically
nor manually. MSVS has solution folders which is quite different thing
and there isn't much sense in expressing real folders as solution
folders.
Visual Studio as Code Browser : How to preserve the directory structure?
Is this true? There is much meaning in the arrangement of files, and the flat representation in VS makes a project harder to understand; file location in the directory structure are important. Is there a way to view the proper directory structure in VS?
In my situation, I'm working with Quickfix, which supports multiple versions (4.0, 4.1, 4.2, etc.). Each of these have different classes and files with the same name.
As you can see from the screen shots below, they are all neatly arranged in different folders on disk, but VS's representation of these files is immensely confusing:
I found the answer given by #Paul Easter in the thread below to very helpful in understanding this "quirk," which is really a "feature." A different concept of project structure is at work:
But as for the reason you do not want solution folders to behave like
"physical" folders is because your solution layout may not necessarily
use the same convention as your source control layout. Solution
folders allow you to customize the hierarchy of your projects so that
you can group projects and items together any way you like, and then
decide you don't like it and change it again without having to go
through the nightmare of moving source control items around and
irritating the rest of your team.
Visual Studio Solutions Folder as real Folders
Is this a good idea? I can see where some people would like it, as it allows them to arrange project files as they wish. At this point, I dislike it; I'm sure in part because it is new to me, but also for these two reasons:
1. In an organized project, the directory hierarchy is not arbitrary; the Principal Engineer arranges files in a certain way for good reasons.
2. It adds a layer of abstraction between the VS file representation and the operating system structure. I like direct access to the files that I'm working on; with the VS system, I feel oddly and eerily disconnected from the underlying files in VS. I must admit a fear that this layer has its anomalies, and will cause problems for me.
I am currently developping an application in MS VS2010 that's based on a client-server architecture with one project for each part in VS. Until recently, they both had their own repositories in Hg, but I decided to move them together as there are quite a few files that are now shared.
I have been using hard links to make sure that the changes on one file are propagated to the same file in the other folder/project. However, if you clone the repository or check out from the online repository, the hard links are broken.
I have read up as much as I could on both soft & hard links with Hg, and neither of them seems to be a good, portable solution at this point. What method of sharing the files between the two projects would you recommend, keeping in mind that I would ideally like a clean structure that is also reflected in VS?
Best regards,
Max.
You could use Mercurial's sub-repository feature to put your shared files in an external repository and share it in the places you need. There's also the guest repository extension, which is relatively newer and lighter-weight than a sub-repo.
Instead of solving it in version control, however, I would re-arrange your Visual Studio project so that your shared code compiles to an assembly that your client and server assemblies use and depend on. Share code at the assembly level, not the code level.
If you really must keep your existing structure, I would use NTFS junctions (similar to UNIX-style soft links) to junction in the shared code where it needs to go. You would then add these junctions to your repository's ignore list (in .hgignore). Create a PowerShell script that you and other developers can run that will initialize your repository with the right junctions.
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
I am wanting to setup a project and potentially an existing project to be SVN version controlled. I am using uberSVN for the svn server. I have installed AnkhSVN for visual studio.
Currently, the team I am working with is using visual source safe and one of the problems we have is when someone adds a reference to a DLL, it modifies the project file as you would expect, but our paths are different between different team members (XP boxes, 7, you get the idea). What I was wanting is making the project file ignored when checking in/out so that we don't mess up the references for everyone else.
Is there a way I can make SVN ignore these files within the plugin? One of the side effects of this is a person would not know if a new file has been added in the project as this modifies the project file. Other than telling everyone "hey, you need to manually add this file to your project," is there a cleaner way of doing it?
If you copy the DLL to a folder inside your VS solution folder before linking to it, I think the project link will be relative not absolute. So you can check the DLL and the updated VS project into your configuration management and everyone should be able to share it.
You should start using virtual paths for development work; that way each team member can keep work-related files at any physical location but the virtual path (the one seen by tools is always the same.
For example, my team does all work under Q:\. My physical source for work is under physical path C:\Work\<project_name> where the project_name part depends on the project. When I want to work on a given project, I map the Q:\ virtual path to the right physical path using
subst q: c:\work\project_name
When I need to switch, I run a similar command. This way there's no need to worry about different paths on different computers. This worked very well for the whole team and eliminated most issues you describe above. The only thing you need to make sure is that everyone always uses the virtual path (Q:), not the physical path when dealing with project-related files. For my team it took about a week to get used to that, after that there were no more problems.
Your project file is an important part of your project so ignoring it in the source control tool will eventually lead to problems. I recommend you don't do it (even if you can).
Edit:
If you have DLL-s in different physical folders on different machines, the best choice is to copy those DLL-s (and their dependencies) to a known location. It's fine that they can't run from there, as long as the compiler finds them.
This known location could be inside your virtual path or a common physical path (if the same DLL-s are needed for multiple projects). You can use Dependency Walker to determine what dependencies you need for native DLL-s and Reflector for .NET DLL-s.
If the size/number of DLL-s is so large that creating a copy is not an option, you can actually tell AnkhSVN to ignore certain versioned files when committing changes. Right-click the file, select Subversion > Move to Change List > ignore-on-commit. After this the file will show up in the commit dialog unselected but you can still commit it if you manually select it.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.