Basically, I want one of my folders to appear above the other folders as a type of "special folder", similar to how Properties has it's own special place even though it's a folder, same with App_Data, etc.
Is this possible?
By default, Visual Studio doesn't support adding special project folders. The Properties folder is hard-coded to behave the way that it does.
However, anything is possible with code. You could build an extension to do this, but it wouldn't be simple. You'd probably need to mess around with the IVsHierarchy or even implement a project subtype.
Basically, I want one of my folders to
appear above the other folders as a
type of "special folder", similar to
how Properties has it's own special
place even though it's a folder, same
with App_Data, etc.
Is this possible?
Yes:
Do it manually through the IDE
Write your own script to
generate/modify your *.sln/*.vcproj
For (1) "manual" on solutions in the IDE: Solution Explorer, right-click on Solution node==>Add==>New Solution Folder.
While typically the folders are sorted alphabetically (I'd insert a leading underscore to force your special folder to the top), solution folders inserted manually on my MSVS2008 leave the new folder "at the top", even though it should have bumped down when alphabetically sorted. However, folders under a Project (which are called "Filters") are always sorted alphabetically, and added similarly from the right-click, and then you can modify their "filter properties" with file name globs for what you want in there (e.g., add a filter glob for "*.MY_EXTENSION1;*.MY_EXTENSION2").
We chose (2), and we generate our own *.sln and *.vcproj, adding our own folders/filters. I've not seen any utilities on the web to help with that (so we had to write our own). The formats are not too hard to reverse engineer, but it's largely undocumented XML, so you have to experiment. There are only a couple good web articles explaining what's in the file, like this one:
http://tim.oreilly.com/pub/a/dotnet/excerpt/vshacks_chap1/index.html?page=4
On the "bright side", the files are only XML, so in developing our scripts we merely made changes through the IDE, saved, and compared the "diffs" for what change we want. Those changes are what our scripts insert when we modify our files. So, if you modify the file manually, you can similarly just "diff" the file to see what changed, and make your own script. (IMHO, this is the fastest and easiest route, since tools generally do not exist to manipulate these files.)
Tools like CMake and QMake generate *.vcproj/*.sln, but don't really do the folder customization thing like you're talking. However, we look at their output too, because, "there's more than one way to do things" in these files, and the files seem to have many undocumented features for doing different clever things that somehow these tools have "discovered" (so you can try to copy their generated output).
We found the .NET APIs to work with these files as too much work, and not really designed for that type of manipulation, but YMMV.
VS 2012 has a feature that I just found, and it solved this problem for me. It may not be new to VS.
Create a folder under the project with a leading "_" (to get it sorted first).
On the folder's properties set "Namespace Provider" to false.
VS (or ReSharper?) code analysis then does not complain that "the namespace does not match file location", which was the source of irritation for me that would otherwise have kept me from going this route.
Although there is no easy way to add Custom Folder, there is an easy way to "steal" Properties custom folder.
Add a regular folder to the project. For example MyCustomerFolder.
Open proj file xml. Find line
<AppDesignerFolder>Properties</AppDesignerFolder>
replace with
<AppDesignerFolder>MyCustomFolder</AppDesignerFolder>
Reload the project.
Now you've got a custom folder, that will always stick to the top.
Related
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
I've created a project and built out a several model classes. I've decided that I'd like to recycle them as a separate framework. In doing so, I want to change my class prefix of those files. The issue is, of course, that I now have to batch rename my files and my classes. I could use the refactor tool, but I have tens of classes, so it would be tedious. Is there a good way to automate the process? For reference, I'm using Xcode 5.
For anyone looking for an answer, I think I have a solution, although it's something I'd like to see built in to Xcode. I've filed a radar.(#15261680)
I had three things to worry about here:
The class names themselves. The class prefixes didn't match the framework that I wanted to put them in.
The file names. Even if I did a careful global search and replace and changed the class prefixes, the file names would be wrong.
The Xcode project references. Xcode keeps a list of your files, and I had to be sure that Xcode would know where to find my files, in the event that I renamed them.
What I did:
I did a global search and replace. Instead of clicking "Replace All", I used the "Review" pane, so I was able to exclude about ten or so cases that I wanted to keep with the original prefix.
I found a utility to do a batch rename. Now my files and classes all match nicely.
Uh oh! Xcode doesn't know where my files are, now. To fix this, I opened the .pbxproj file and did another careful search and replace. (I made sure to quit Xcode first, so my changes wouldn't be overwritten automatically.)
This was a bit of an involved process, and I was hoping that there was a tool or Xcode feature to help me do this, but alas, not yet.
Shouldn't vcxproj.filters be embedded in the .vcxproj? As it stands I have to check this in to source control so others can see the folder structuring in the solution.
According to what Dan Moseley says in this question, they also wanted to separate the tree structure from the build specific information because changing the tree structure would cause an update to be made to the project file, and that in turn would trigger a rebuild. By moving the logical view of the project to a separate file this is avoided.
They were embedded in fact, in previous versions of Visual Studio. The extension was still .vcproj and the filters were stored inside the project file. However, as of 2010 it was decided to pull the .filter information into a separate file.
It is really up to the design teams now to decide whether to add this source control or not. If you want all the developers to have the same structure (for reasons of communication) it might be wise to check them in. If you want to allow each developer to use their own logical view, then don't.
The vcxproj file contains the commands for the msbuild environment. So it contains the files that should be built and the arguments for the compiler how to build/link etc. the source files.
Due to this, the development team decided that the 'view' of the files in the solution explorer should not be contained in the msbuild file, but in another file.
So this was done to separate the build settings from the view you have.
I have a solution with many many projects, I did not write this project but it's an open source project (mysql++) , I need to include an include path to all projects. I would like to just globally add this include path to the solution and have it cascade down to all the projects... is this possible? I dread thinking about having to do the same thing for each individual project.
Thank you,
Alessandro Ferrucci
Visual Studio lets you modify many projects at once. Simply click the first in the Solution Explorer, shift-click the last, and right-click the group to get to the project properties. Now any changes you make affect all projects you selected.
Don't do this if individual projects have different include path settings and they must continue to have different settings. Changing the include path in this way will make them all the same. This may be fine even if they currently have different settings if you can agree on a path that makes sense for all the projects.
If each project has to have a different include path, the best way I know to do what you want is to open all the project files in a plain text editor, search for AdditionalIncludeDirectories, and paste the MySQL++ include directory plus a semicolon into the string that follows. Be sure to do this for all places that attribute appears in each project. At minimum, there will be two: one each for Release and Debug builds.
EDIT: If you use a good text editor, this can be a lot faster than doing the same operation inside Visual Studio. I recommend Vim, if you already have vi skills. Its . command to repeat the previous edit makes the "search, navigate, change" cycle much faster.
In an earlier question, I've found out that sadly Solution Folders are not real folders inside a directory.
I wonder if there is an AddOn or Macro that adds this functionality? i.e. when I create a Solution Folder, it created a real folder. When I Create a new Item (Right Click => Add => New Item) it automatically moves them into that folder, removing causes it to delete it from disk (after asking) etc.
This is for Visual Studio 2005, although we might upgrade to 2008 in a few months.
As of now, this doesn't seem to be possible in either VS 2005, 2008 and 2010 and there is no AddIn for this.
I too thought it was a strange idea. However it can be a useful tool to logically group projects in solutions without necessarily moving around folders in the file system.
I suspect you need this for revision control tool. In that case Look at AnkhSVN.
Maybe what you want is to add files to a solution folder as «links», i.e., keeping the files where they are but giving them a different organization inside the solution.
(when you add an existing file to a solution folder or to a normal project folder, if it is in a different corresponding physical folder, the file is copied).
It usually stays unnoticed, an option in the «Add > Existing Item ...» dialog where you can choose "Add As Link", instead of the "Add".
This allows to share files amongst projects, or, simply, organize them differently.
What I oftem miss is the possibility to add "virtual" folders inside a project, for organizational purposes, without breaking the namespace/folder best-practice.
Can't really get the point you want to add this function.
Sometimes you want to know if it can do this , however, the answer may be no. But it is not necessary means you can't achieve your original goal, there still a few ways to work around it without this.
Additionally, VS solution suppose to be the shortcut of your project settings and should not been included in any hard-code, the solutions may be various between the PCs and IDE envrionment.
I didn't really use VS2005 much, but have been using VS2008 for the past year.
It has a tick box for creating a solution folder when you create a new solution/project.
If you then use the "Solution Explorer" window you can create and manipulate folders and class files within them. This will actually create new directories that match.
Deletion of files from within the Solution Explorer will also delete the actual files from disk.