This lightweight extension will detect whenever two instances of Visual Studio are running with the same window title and change the window title of Visual Studio to include a folder tree with a configurable min depth and max depth distance from the solution/project file.
This is a perfect solution and, like others said, you wonder why VS doesn't include it by default.
My TFS branch folder is always the parent to the solution, so I used [parent0] to get the branch's folder name. It wasn't obvious from the descriptions. And [parentPath] didn't work for me in this case because I wanted to use a "Farthest parent folder depth" of 10 for a document with no solution but only the branch name for a solution.
Also, TyWeb stated that you can't show the whole path, but that's not true. Just set "Farthest parent folder depth" to a high enough value (10 was deep enough for my projects) that will traverse deep enough to pick up the drive letter.
Perfect! A google search lead me to this extension and the default title option (containing-folder\solution) is exactly what I need to tell which solution folder relates to which Visual Studio 2013 instance.
Very limited documentation. There is NO WAY this product can display the FULL file path. I would not recommend installing this product! I used the Visual Studio Window Title Changer by István Pásztor (http://visualstudiogallery.msdn.microsoft.com/2e8ebfe4-023f-4c4d-9b7a-d05bbc5cb239) and I was up and running in 2 minutes. A far superior product if you want to display the FULL file path.
Hi cpmcgrath, thanks for your suggestion. I am not sure it would be possible to manipulate the start screen, but will look into it and keep you posted.
A workaround in the meantime would be to hover the links to see the full path.
At my computer solution MRU list for VisualStudio 2013 is saved in registry in:
There are values "File1", "File2", etc...
If value data for "File1" is:
and value data for "File2" is:
than you can change the value data to:
to differentiate branches in start screen MRU list.
It would be cool if some plugin could automate this registry tweaks for VS2013.
But I think this does not work on VS2010. Not sure if it works for VS2012.
Unfortunately, I am not aware of any way to change the color/font format in a window title. It is certainly possible (everything is possible), but may require very unorthodox hooks. You are free to play with the extension's source code if you would like to check this further.
Hi i'm using Visual Studio 2013 with a tfs2012 back end. Since updating to the latest version the rename has stopped working. If i switch the debug output on i get the following output.
RenameVSWindowTitle: UpdateWindowTitle exception: System.InvalidCastException: [A]Microsoft.VisualStudio.TeamFoundation.VersionControl.VersionControlExt cannot be cast to [B]Microsoft.VisualStudio.TeamFoundation.VersionControl.VersionControlExt. Type A originates from 'Microsoft.VisualStudio.TeamFoundation.VersionControl, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.TeamFoundation.VersionControl\v4.0_18.104.22.168__b03f5f7f11d50a3a\Microsoft.VisualStudio.TeamFoundation.VersionControl.dll'. Type B originates from 'Microsoft.VisualStudio.TeamFoundation.VersionControl, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.TeamFoundation.VersionControl\v4.0_126.96.36.199__b03f5f7f11d50a3a\Microsoft.VisualStudio.TeamFoundation.VersionControl.dll'.
at ErwinMayerLabs.RenameVSWindowTitle.RenameVSWindowTitle.GetNewTitle(String pattern)
at ErwinMayerLabs.RenameVSWindowTitle.RenameVSWindowTitle.UpdateWindowTitle(Object state, EventArgs e)
Hi, I have rolledback to 2.5.0 while I am looking for a fix. Please uninstall and reinstall if no update option is proposed. Sorry for the inconvenience.
It seems the assemblies needed to support TFS (the feature added by 2.6.0) are not compatible across versions of Visual Studio...
Which is not easy to test for me unfortunately.
You can fix this with reflection. That way your plugin doesn't have to have dependencies on TF assemblies and you can load the correct version at runtime. For example for VS2013 you can use the following assembly reference: "Microsoft.TeamFoundation.VersionControl.Client.Workstation, Microsoft.TeamFoundation.VersionControl.Client, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
You can obtain the typeinfo for the WorkspaceInfo class similarly.
For vs2012 and 2010 you just replace the first digit of the assembly reference version to dte_version: 184.108.40.206 and 10.0.0.0 respectively. I could get the workspacename of a VS2013 workspace name from a VS2010 instance with this technique.
I don't know whether different Visual Studio versions load and use different assembly versions than their own in some circumstances... My guess would be that they always use their own version but I havent check this.
I actually fixed this already in the current release, by simply loading the required object without strong typing: "dynamic vce = this.DTE.GetObject("Microsoft.VisualStudio.TeamFoundation.VersionControl.VersionControlExt")"
This way I don't even need a version number so it should be future-proof :).
That solution is indeed nicer, I went the reflection route because I wanted code that compiles with older VS versions too. As I see VersionControlExt is available only for VS2012 and later according to msdn, if you use Workstation.Current.GetLocalWorkspaceInfo then your code will work for VS2005-VS2013 if the objects come from the right assembly version. I've tested it as I have all versions installed at work.
Good point, I had not tested workspaceName under VS 2010 and it does indeed not get replaced. No one has complained so far, but I already have a possible fix thanks to your suggestion. The only issue is that I am not able to test as I am not a TFS user myself, so I will wait until someone needs this and is willing to test before releasing into the wild.
I am only looking up assembly by short name "Microsoft.TeamFoundation.VersionControl.Client.Workstation" instead of the fully qualified name, do you think it would not work?
Nice job with your extension by the way :).
Thank you! I've used your extension before but I created a very big mess on my hard drive with many projects that have different directory structures. My first plugin to aid this was basically the same as yours, I just modified the config so I could add several option pages depending on the solution filename. Then I thought it would be fun to mess around a bit with expression evaluation and this project was a good fit. My plugin is much more complicated, its rather for "hardcore" users. :-)
Although on the msdn page of Microsoft.VisualStudio.TeamFoundation.VersionControl.VersionControlExt class I can switch only to VS2012 and VS2013 I've found forum entries where people said it is accessible in VS2005 while it isn't in VS2008. With my VS2010 I could also query it without problems so it is most probably an msdn documentation bug. I think you should stick to your current solution if people don't complain. The DTE.GetObject() works differently than my code that uses reflection, DTE.GetObject() call returns COM references and in my opinion a specific version of the dte reference probably always returns its own versioncontrol objects. I've compiled a plugin in VS2010 with dynamic typing and under VS2013 the plugin queried the right interface with GetObject(). Additionally a problem with Workstation.Current is that it isn't visible to COM.
I'm also far from being a TFS user, I just downloaded and installed the 90day VS2013 trial (http://www.visualstudio.com/en-us/downloads) and since the basic TFS service is free for 5 users (http://www.visualstudio.com/products/visual-studio-online-overview-vs) I've created 2 test workspaces. You could give it a go, the setup is easy and then you have a testbed.
This post inspired me in finding out a new feature to implement in my extension in the near future. My extension sets the title by evaluating a user defined expression. By introducing a new "exec" function call that is performed periodically by the expression evaluator (for example every X seconds defined by the user) the expression could use the output of a custom command as part of the titlebar of Visual Studio. The custom command could be a git command, or a custom script of the user that further customizes the output and exitcode of some other external command(s). This gives an extra layer of freedom in setting the titlebar.
+1 virtual points for your post :-)
Am I missing something or can I not simply show the whole path of the active file like C:\WhatSoEver\SolutionFolderParent\SolutionFolder\subproject\folder1\folder2\myfile.cs or relative to the solution like SolutionFolder\subproject\folder1\folder2\myfile.js
Or should parentX works relative from the file as well? Only able to get it working relative to the solution file.
First of all thanks for a great extension.
A nice feature to add is renaming the "Recent Projects" section in the start page.
I have the same solution that i use under different branches all the time, it will make it much easier to detect which one i want to open.
I used to have "SolutionName(FullSolutionPath) - ..."
but now it says "SolutionName(SolutionParentDirectory) - ..."
Seems like this is a difference in meaning of [parentPath] between 2012 and 2013 version.
How do I get FullSolutionPath in 2013 version?
By the way there is a bug in 2012 version it says C:MyFolder\Folder2 instead of C:\MyFolder\Folder2 i.e.: missing first backslash
Hi Jens, you need to specify "Farthest parent folder depth" = 20 (for example, could also be 100 depending on how deep is your folder structure) in options to show the full directory no matter what.
When you installed on VS 2013 it did not copy the config from your 2012 installation, this is why you are seeing the default behavior of only one parent folder shown.
Regarding the bug you mentioned, it is well spotted and after checking it is due to an unexpected design of a function used to build the path: http://stackoverflow.com/questions/1527942/why-path-combine-doesnt-add-the-path-directoryseparatorchar-after-the-drive-des?rq=1
I may implement a workaround in a future release, but stripping the slash could actually be preferred as it reduces the title length (and it should be less troubling than before to know it is an expected behavior).