Can I have a freehand in using any arbitrary folder hierarchy within a Visual Studio project? Does the runtime/VS actually care about how I create the folders?
Visual Studio doesn't care about the folder structure you use. Everything is typically tied together based on file types and the references in your project (csproj, vbproj, etc) file.
That said: in general it is best to stick to the conventions laid out by Microsoft for common files, since people are used to look for them in the places.
Related
I'm working ona project containing thousands of solutions (.sln) and tens of thousands of .cs/.cpp/etc files.
How can i find which solution(s) a source file is a part of?
Source files aren't part of a solution. They are part of a project, which in turn is part of a solution. The source file itself has no notion of being part of the project though. The project has a reference to the file but not the other way around. One source file can be part of multiple projects, which might be part of different solutions.
What you could do is parse the SLN and VBPROJ/CSPROJ/whatever files to see which ones refer to a particular source file. Those files are just text and contain various information about the solution or project, including what projects are part of a solution and what files are part of a project. You could recursively parse the files in folder to build up an entire tree representing the files in the projects in the solutions.
Note that most files are going to be referred to by relative paths in the project file.
Start with Visual Commander and then you can programmatically access your solution "DOM-style" using Visual Studio's Automation and Extensibility for Visual Studio API. Write a VS command in a .NET language that traverses a solution into its projects and then into the project items, dumping all files found (project items) into a log file, database, web service, what have you.
See e.g., this article HOWTO: Navigate the files of a solution from a Visual Studio .NET macro or add-in on how to navigate Visual Studio's DTE.
I know SO frowns on answers containing just links and not true help, but the documentation for EnvDTE in its various flavors is extensive and any code sample to demonstrate how to use it would be quite large. So I'm just giving you this strong hint: Look at the Visual Studio extensibility model, and hook into it easily via Visual Commander which does all the hard work of wrapping your code in a Visual Studio extension. From there you can use any reasonable technique (MSBuild, PowerShell, batch files) to load each solution into VS and run your new command.
This actually answers the question: For all source files used by any of my thousands of solutions, which solutions use them. But I see that you (#Sabz), below in a comment, give a reasonable way to answer the question for one source file at a time, which is more precisely what you asked.
N.B.: I have not (yet) used Visual Commander so I'm just assuming it works as advertised.
If I have a project called 'testing' in project A.
How can I share that folder 'testing' for project B in visual studio 2010?
The reason I would like to achieve about this is because when I change something in the folder testing of project A, I dont want to change the same things in project B.
Thanks in advance.
Maybe too late for the person who asked the question, but this is for people with similar problems. You can share folder contents with an extention 'Project Linker':
This builds upon the concept of linked files where you refer to the same file from two projects. This extention handles the management of that for an entire project. If you add a file to the project, it will be added too to the other project as a linked file. Same for deletes...
Attention: you need to have both projects in the same solution for this to work of coarse...
Extention VS2015
I used it in VS2010 and it's also availible for later versions.
You can't share folders in Visual Studio - they are logical constructs that are part of a solution or project.
The closest you can get is to add folders to the projects you need to share on and add all the files that you want to share as links. You will still need to manually synchronize all adds/deletes of files, but updates will come across all projects.
To make things easier, you may want to write a Visual Studio macro that synchronizes these folders for you (you can bind these to keyboard shortcuts and/or menu items).
If you put your solution (*.sln) files in the same directory they can share files in sub directories.
I have a solution in Visual Studio 2010 which contains multiple projects. All of those projects share a common directory for header files and library files. When I go to Tools->Directories it tells me this approach is deprecated and that there is a separate Directory properties for each project. Surely Microsoft don't expect me to now add these settings to each project individually. Is there not a top level property which all projects inherit and then this project specific property? Am I missing something or do I really need to do this per project now?
What you want to use are called PropertySheets.
When used right they are very powerful, especially for large projects.
With these you can specify much more common things, than just only different directories.
I'm currently using Visual Studio 2010 Professional. In my entire experience with Visual Studio (since version 6), a C++ project structure was always virtual. In other words, when I move files around and create folders in the project, this had no bearing on the actual structure on the filesystem. I've always had to manage the two independently (the filesystem structure and the project structure).
Is there a way to make C++ project structure in Visual Studio act as it does in C#, whereby all move/copy/create folder/etc operations in a C++ project directly affect the corresponding file system hierarchy?
Thanks in advance.
I'm afraid it's not possible, since Visual C++ and Visual C# handle "folders" quite differently.
In Visual C++, folders are more akin to filters, for example a "Source Files" folder might be hinted as a filter to contain .cpp files, while a "Header Files" will contain .h files.
However there's a workaround, described here : Visual Studio projects with multiple folders
Can someone briefly explain to me the difference between Visual Studio's solution file (.sln) and project file (.vcproj).
It seems to me opening either one open the correct solution/project in Visual Studio. Is one the super-set of the other?
Note: I am currently using Visual Studio 2008 working on a project that was brought forward from Visual Studio 2005 (I believe).
A solution is a set of projects. If you need more than one project in your software, then go with solutions. I.E.: A Class Library Project + A Web Application Project.
A project file typically corresponds to a single module: EXE or DLL or LIB. A solution manages a collection of project files.
A solution is a collection of projects. Visual Studio is made so that it cannot function without a solution, so if you open a bare project, it will generate the solution automatically (or try to find one).
One solution can contain zero or more projects. Everything is in projects, so a solution with zero projects doesn't contain anything at all besides the solution properties.
Visual studio keeps track of where the projects are used, so if you open a project file, it will open (IIRC) the last solution where it was used.
When you create a project from scratch, a solution is also created, but it's not shown until you add another project to it. It looks like you have only the project open, but it's actually a solution containing the project that is open.
Specifically project files are intended to contain the data required to build the files in the project into an exe or dll. This file is utilized by the local compilers or with systems such as Team Foundation system and server side build agents.
Solutions are a client (IDE) construct designed to manage collections of projects, which in effect is a collection of different build definitions and associated files.
Solution files are typically made up of multiple project files.