mayerwin / vs-customize-window-title

Customize Visual Studio Window Title - Visual Studio Extension

Customize Visual Studio Window Title - Visual Studio Extension

This is the official repository for:
https://marketplace.visualstudio.com/items?itemName=mayerwin.RenameVisualStudioWindowTitle

Initial release page here:
http://erwinmayer.com/labs/visual-studio-2010-extension-rename-visual-studio-window-title

Description

This lightweight extension allows changing 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, and the use of special tags to help with many other possible scenarios (Git, Mercurial, SVN, TFS...).

Solution-specific overriding rules are available as well to cover virtually any possible renaming needs.

It can also be configured so that the rules apply only when at least two instances of Visual Studio are running with the same window title.

Documentation

Full documentation is available on the Visual Studio Marketplace page.

Supported editions

Visual Studio 2015, 2017, 2019, 2022+.

Visual Studio 2017 and 2019 support has been temporarily dropped due to limitations imposed by Microsoft's Visual Studio Marketplace. The last stable release (5.1.0) supporting Visual Studio 2019 can however be downloaded here.

Visual Studio 2012 and 2013 support has been dropped due to new requirements imposed by Microsoft to speed up loading time with AsyncPackage. The last stable release supporting Visual Studio 2012 and 2013 can however be downloaded here.

Visual Studio 2010 support has been dropped due to limitations imposed by Microsoft's VSIX format to support Visual Studio 2017. The last stable release supporting Visual Studio 2010 can however be downloaded here.

You are welcome to contribute to this project!

vs-customize-window-title's Issues

Cannot download plugin

When trying to download this plug in I am getting error:

An error occurred while processing your request.
Reference #97.3e5f9e41.1488998323.18c10bb0

When is the version ready for Visual Studio 2017

Feature Request - Different title when building

I think it would be interesting to know which IDEs are currently building, in a similar vein to the current Debugging and Running fields.

Just a thought, I don't know if that information is available to the extension or not.

Show focused tool window?

Is it possible to show the focused tool window title? I do voice programming and we can set up commands to be available depending on what the window title is. This could be useful for when the terminal is focused, or the find window...

AssemblyInfo is not updated with package version update

Still points to 3.4.1 and not to 3.6.0

https://github.com/mayerwin/vs-customize-window-title/blob/master/CustomizeVSWindowTitle/Properties/AssemblyInfo.cs

[vsMajorVersionYear] is "15" in Visual Studio 2017

It should obviously be "2017".

VS 2019 16.2.x freezes (at least on solution/VS close)

Thx to JetBrains and MS we figured out the problem:

Sergey Kuks commented an hour ago
Thread 367
WARNING: Stack pointer is outside the normal stack bounds. Stack unwinding can be inaccurate.

ChildEBP RetAddr

00 b233e200 75a88503 ntdll!NtWaitForMultipleObjects(void)+0xc [minkernel\ntdll\wow6432\objfre\i386\usrstubs.asm @ 825]

01 b233e394 77a85723 KERNELBASE!WaitForMultipleObjectsEx(unsigned long nCount = 1, void ** lpHandles = 0xb233e3e0, int bWaitAll = 0n0, unsigned long dwMilliseconds = 0xffffffff, int bAlertable = 0n0)+0x133 [minkernel\kernelbase\synch.c @ 1551]

02 b233e404 77abaf86 combase!MTAThreadWaitForCall(class CSyncClientCall * pClientCall = 0x94b06b30, WaitForCallReason reason = WaitingForReply (0n0), unsigned long dwRetryTimeout = 0xffffffff)+0x103 [onecore\com\combase\dcomrem\channelb.cxx @ 7429]

03 b233e494 77abab51 combase!MTAThreadDispatchCrossApartmentCall(struct tagRPCOLEMESSAGE * pMessage = 0xb233e7e4, class OXIDEntry * pOXIDEntry = 0x00988bb0, class CSyncClientCall * pClientCall = 0x94b06b30)+0xe6 [onecore\com\combase\dcomrem\chancont.cxx @ 235]

04 (Inline) -------- combase!CSyncClientCall::SwitchAptAndDispatchCall+0x306 [onecore\com\combase\dcomrem\channelb.cxx @ 6026]

05 b233e5b8 77aba2dd combase!CSyncClientCall::SendReceive2(struct tagRPCOLEMESSAGE * pMessage = 0xb233e7e4, unsigned long * pstatus = 0xb233e7c0)+0x3e1 [onecore\com\combase\dcomrem\channelb.cxx @ 5722]

06 (Inline) -------- combase!SyncClientCallRetryContext::SendReceiveWithRetry+0x2d [onecore\com\combase\dcomrem\callctrl.cxx @ 1641]

07 (Inline) -------- combase!CSyncClientCall::SendReceiveInRetryContext+0x2d [onecore\com\combase\dcomrem\callctrl.cxx @ 571]

08 (Inline) -------- combase!DefaultSendReceive+0x75 [onecore\com\combase\dcomrem\callctrl.cxx @ 529]

09 b233e79c 77a798d4 combase!CSyncClientCall::SendReceive(struct tagRPCOLEMESSAGE * pMessage = 0xb233e7e4, unsigned long * pulStatus = 0xb233e7c0)+0x1bd [onecore\com\combase\dcomrem\ctxchnl.cxx @ 817]

0a (Inline) -------- combase!CClientChannel::SendReceive+0x75 [onecore\com\combase\dcomrem\ctxchnl.cxx @ 696]

0b b233e7c4 75825d81 combase!NdrExtpProxySendReceive(void * pThis = 0x46c2ddcc, struct _MIDL_STUB_MESSAGE * pStubMsg = 0xb233e8cc)+0xc4 [onecore\com\combase\ndr\ndrole\proxy.cxx @ 1961]

0c (Inline) -------- rpcrt4!NdrpProxySendReceive+0x1b [minio\rpc\ndr20\mulsyntx.cxx @ 1566]

0d b233ecb8 77b2d450 rpcrt4!NdrClientCall2(struct _MIDL_STUB_DESC * pStubDescriptor = 0x214ab1ec, unsigned char * pFormat = 0x214ab1d6 "3l")+0x561 [minio\rpc\ndr20\cltcall.cxx @ 1107]

0e b233ecd8 77b253ef combase!ObjectStublessClient(void * ParamAddress = 0xb233ecf0, long Method = 0n19)+0x70 [onecore\com\combase\ndr\ndrole\i386\stblsclt.cxx @ 227]

0f b233ece8 6b2f691a combase!ObjectStubless(void)+0xf [onecore\com\combase\ndr\ndrole\i386\stubless.asm @ 171]

10 b233ed58 3c529b8e EnvDTE80_ni!DomainNeutralILStubClass.IL_STUB_CLRtoCOM(<Win32 error 0n318>)+0x72

11 b233eda4 3c529966 CustomizeVSWindowTitle!ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.UpdateWindowTitle(<Win32 error 0n318>)+0x20e

12 b233edb4 733a7118 CustomizeVSWindowTitle!ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.b__36_0(<Win32 error 0n318>)+0x6

13 b233edb4 733a6cc0 mscorlib_ni!System.Threading.Tasks.Task.InnerInvoke(<Win32 error 0n318>)+0x28 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2884]

14 b233edd8 733a70ea mscorlib_ni!System.Threading.Tasks.Task.Execute(<Win32 error 0n318>)+0x30 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2498]

15 b233ee40 733c40c5 mscorlib_ni!System.Threading.Tasks.Task.ExecutionContextCallback(<Win32 error 0n318>)+0x1a [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2861]

16 b233ee40 733c3fd6 mscorlib_ni!System.Threading.ExecutionContext.RunInternal(<Win32 error 0n318>)+0xe5 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 954]

17 b233ee54 733a6f68 mscorlib_ni!System.Threading.ExecutionContext.Run(<Win32 error 0n318>)+0x16 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 902]

18 b233eec0 733a6e72 mscorlib_ni!System.Threading.Tasks.Task.ExecuteWithThreadLocal(<Win32 error 0n318>)+0xd8 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2827]

19 b233eed0 733a6dbc mscorlib_ni!System.Threading.Tasks.Task.ExecuteEntry(<Win32 error 0n318>)+0xb2 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2756]

1a b233ef24 7336dba2 mscorlib_ni!System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem(<Win32 error 0n318>)+0xc [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2704]

1b b233ef24 7336da0a mscorlib_ni!System.Threading.ThreadPoolWorkQueue.Dispatch(<Win32 error 0n318>)+0x192 [f:\dd\ndp\clr\src\BCL\system\threading\threadpool.cs @ 820]

1c b233ef34 7447ebe6 mscorlib_ni!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(<Win32 error 0n318>)+0xa [f:\dd\ndp\clr\src\BCL\system\threading\threadpool.cs @ 1161]

1d b233ef34 74481e50 clr!CallDescrWorkerInternal(unsigned long pParams = 0xb233efd0)+0x34 [f:\dd\ndp\clr\src\vm\i386\asmhelpers.asm @ 763]

1e b233ef88 744879f4 clr!CallDescrWorkerWithHandler(struct CallDescrData * pCallDescrData = 0xb233efd0, int fCriticalCall = 0n0)+0x6b [f:\dd\ndp\clr\src\vm\callhelpers.cpp @ 91]

1f b233effc 7448b673 clr!MethodDescCallSite::CallTargetWorker(unsigned int64 * pArguments = 0x00000000)+0x16a [f:\dd\ndp\clr\src\vm\callhelpers.cpp @ 655]

20 (Inline) -------- clr!MethodDescCallSite::Call_RetBool+0xb [f:\dd\ndp\clr\src\vm\callhelpers.h @ 423]

21 b233f07c 7448a059 clr!QueueUserWorkItemManagedCallback(void * pArg = 0xb233f297)+0x23 [f:\dd\ndp\clr\src\vm\comthreadpool.cpp @ 510]

22 b233f090 7448a0c3 clr!ManagedThreadBase_DispatchInner(struct ManagedThreadCallState * pCallState = 0x7448b650)+0x71 [f:\dd\ndp\clr\src\vm\threads.cpp @ 10273]

23 b233f134 7448a190 clr!ManagedThreadBase_DispatchMiddle(struct ManagedThreadCallState * pCallState = 0xb233f198)+0x7e [f:\dd\ndp\clr\src\vm\threads.cpp @ 10323]

24 b233f190 7448a1ff clr!ManagedThreadBase_DispatchOuter(struct ManagedThreadCallState * pCallState = 0xb233f198)+0x5b [f:\dd\ndp\clr\src\vm\threads.cpp @ 10577]

25 b233f1b4 7448b601 clr!ManagedThreadBase_FullTransitionWithAD(struct ADID pAppDomain = struct ADID, * pTarget = , void * args = , UnhandledExceptionLocation filterType = ThreadPoolThread (0n4))+0x2f [f:\dd\ndp\clr\src\vm\threads.cpp @ 10641]

26 (Inline) -------- clr!ManagedThreadBase::ThreadPool+0x10 [f:\dd\ndp\clr\src\vm\threads.cpp @ 10682]

27 b233f264 7448a45b clr!ManagedPerAppDomainTPCount::DispatchWorkItem(bool * foundWork = 0xb233f295, bool * wasNotRecalled = 0xb233f297)+0x102 [f:\dd\ndp\clr\src\vm\threadpoolrequest.cpp @ 761]

28 b233f27c 7448a349 clr!ThreadpoolMgr::ExecuteWorkRequest(bool * foundWork = 0xb233f295, bool * wasNotRecalled = )+0x4f [f:\dd\ndp\clr\src\vm\win32threadpool.cpp @ 1878]

29 b233f2e4 744feda1 clr!ThreadpoolMgr::WorkerThreadStart(void * lpArgs = 0x00000000)+0x3d3 [f:\dd\ndp\clr\src\vm\win32threadpool.cpp @ 2346]

2a b233fa80 775b0419 clr!Thread::intermediateThreadProc(void * arg = 0x6e1cdf48)+0x55 [f:\dd\ndp\clr\src\vm\threads.cpp @ 2872]

2b b233fa90 77cd662d kernel32!BaseThreadInitThunk(unsigned long RunProcessInit = , * StartAddress = 0x744fed50, void * Argument = 0x6e1cdf48)+0x19 [base\win32\client\thread.c @ 64]

2c b233faec 77cd65fd ntdll!__RtlUserThreadStart( * StartAddress = 0x744fed50, void * Argument = )+0x2f [minkernel\ntdll\rtlstrt.c @ 1163]

2d b233fafc 00000000 ntdll!_RtlUserThreadStart( * StartAddress = , void * Argument = )+0x1b [minkernel\ntdll\rtlstrt.c @ 1080]

These kinds of issues are almost always caused by a background thread trying to get back to the main thread using RPC instead of JTF. In this case it looks like the culprit is thread 367 (!), where ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.UpdateWindowTitle is calling some DTE method. The DTE method is STA and needs to run on the main thread.
The fix would be to transition to the main thread before making the DTE call. A workaround might be to disable the CustomizeVSWindowTitle extension.

Details:
https://youtrack.jetbrains.com/issue/RSRP-476094

Title not set in VS2019 title-bar

I just installed VS2019 (16.0.1) with the plugin (v4.3.3).
I noticed that the badge in the Windows task-bar has it's title set as configured.

However, the title-bar of VS2019 seems to show the name of the solution only instead of the configured title.

I suppose this has something to do with the new title location in VS2019, but I miss my configured title :-(
(FYI: when I enable the plugin's debug mode everything look fine)

Settings are not exported

I want to back up my settings for this extension, but when I use the VS "Import and Export Settings" wizard, it seems that they are not included in the export.

Customizable timer

Currently the timer is 5 seconds as not customizable.

Feature Request - Detecting a "root" location within the path

There are many cases people work within some workspace that has a root path. There can be multiple workspaces and it could be useful to see it or its part in the title. MSBuild has an interesting function called GetDirectoryNameOfFileAbove(, that looks for the specified file name in the specified folder and up, and returns the path the file is found in.

It could be nice to have a similar feature in the tool; the required path to display could be found by referring particular "anchor" file.

Issue with [svnDirectoryName] not working

Here is what I have it set up as. In this setup I don't have admin right in this Virtual Machine.

Here is the log requested when debugging is enabled.

CustomizeVSWindowTitle: SvnResolver.GetSvnDirectory() exception: System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at ErwinMayerLabs.RenameVSWindowTitle.Resolvers.SvnResolver.GetSvnDirectory(String workingDirectory)
CustomizeVSWindowTitle: SvnResolver.GetSvnDirectory() exception: System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at ErwinMayerLabs.RenameVSWindowTitle.Resolvers.SvnResolver.GetSvnDirectory(String workingDirectory)
CustomizeVSWindowTitle: SvnResolver.GetSvnDirectory() exception: System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at ErwinMayerLabs.RenameVSWindowTitle.Resolvers.SvnResolver.GetSvnDirectory(String workingDirectory)
CustomizeVSWindowTitle: SvnResolver.GetSvnDirectory() exception: System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at ErwinMayerLabs.RenameVSWindowTitle.Resolvers.SvnResolver.GetSvnDirectory(String workingDirectory)

Colorize the Title Bar/Change Themes

Enhancement Request -
We use TFS and have various branches based on where in the SDC the code is. Typically
Future -> MainDev -> Main -> Release Testing -> Release. We also have 3-4 branches off MainDev for large future projects. Names in the title bar helps with where we are but color would be easier to identify the branch. Having the extension perhaps change the theme applied based on the branch maybe an effective way to do that. I may have 3 copies of VS 2019 running pointing to different development branches but the Solution name and all the file names are the same. Color would indicate ate a glance where I am.

Using TFS branch name in title bar causes random unresponsive UI of up to 30 seconds

This error occurs randomly for me throughout the day while using this extension. To reproduce, simply include [tfsBranch] in the windows title setting.

It seems that the external tool takes a significant amount of time to find the current TFS branch. Are we blocking on the UI thread, or awaiting on a separate thread for the I/O?

Rename Additional Windows

Hello,

I just installed this tool to help me edit projects from the same git repository (with the same project name) simultaneously (since Windows builds slowly). It seems to work great from my initial poking and prodding.

However, I have my Output and Solution Explorer together docked in a separate window on my second monitor, with my files open in the main window. This separate window does not get the renaming niceness that the main window does, so if I were to have two instances of VS open to my separate instances of the project with the same name, it would be challenging to disambiguate them. Could a change be made so that ALL windows associated with a given project get renamed (even if all windows get the same name)?

Thanks!

Additional Notes:

Currently, my window titles correspond to this:

Primary Solution
Solution Path: .../primary/PROJECT.sln
Main Window Title: primary/PROJECT
Secondary Window: PROJECT

Secondary Solution
Solution Path: .../secondary/PROJECT.sln
Main Window Title: secondary/PROJECT
Secondary Window: PROJECT

What I would like is something like this:

Primary Solution
Solution Path: .../primary/PROJECT.sln
Main Window Title: primary/PROJECT
Secondary Window: primary/PROJECT

Secondary Solution
Solution Path: .../secondary/PROJECT.sln
Main Window Title: secondary/PROJECT
Secondary Window: secondary/PROJECT

Feature Request - Customize Tab Title

Is it possible to have similar functionality, but for tab titles?

For, Example I am interested in a title like:
[documentParentPath:1]\[documentParentPath:0]

It helps to have the window display this, but will be more productive to have it in the tabs.

Is it possible to include it in this extension, or it is something entirely different?

svnDirectoryName:X

Is there any way to "reverse" the index for svnDirectoryName?
We have multiple projects located in one svn server so we have something like

/prog1/branches/
/framework/prog2/branches/

and im only interested in the branch name.
Like it is now i cannot set global settings.
Maybe something like [svnDirectoryName:-1]?

Feature Request - startup project as a selection for title

I would like to submit a new feature, something that was available for a different VS title changer tool that I used for VS 2015, but wasn't available for 2017.

The startup project as a selection for the title.

Ex: Startup Project - Solution
Ex: My.Service.Host - My.Services.Sln

Feature Request - Has unsaved changes / IsAnythingDirty tag

When the solution contains unsaved changes, I would like to see that in the title of the window as a *
So i suggest the tag [hasUnsavedFiles] which results in "" when no unsaved files and in "*" when there are unsaved files

Extension causes VS to freeze sporadically

I've seen the "this extension has caused X seconds of unresponsiveness" warning multiple times today, for version 4.3.0. First time was 5, just a few minutes ago it was 6.

The only settings I've changed from defaults were the "solution in X mode" ones:
[solutionName] [[tfsBranchName]] (Debugging) - [ideName]
[solutionName] [[tfsBranchName]] - [ideName]
[solutionName] [[tfsBranchName]] (Running) - [ideName]

I've turned on the Debug option and can hopefully contribute something more substantial when this happens again.

svnDirectoryName is never set to anything.

I have SVN binaries directory set to "C:\Program Files\TortoiseSVN\bin" (and it's on my path), but my solution files under SVN managed directories have never set svnDirectoryName.

Escape bracket char is broken

In v.2.8.1, I was able to use [[gitBranchName]] to get [master] to display. This appears to be broken in v3.2.1 -- what displays is the literal [[gitBranchName]]. Is there some other way to escape the bracket char to get it to display?

Display user (administrator)?

Thanks for an amazing extensions.

We are running VS as a "normal" user and in some cases in order to attach to eg IIS we run it elevated. By default, VS then changes "Microsoft Visual Studio" into "Microsoft Visual Studio (Administrator)". I guess it's the [ideName] that changes? But we'd rather get rid of "Microsoft Visual Studio" since, well, yes, obviously we're running VS. Any ways we could get the "(Administrator)" part of the name though?

tfsBranchName does not work on VS2019

tfsBranchName does not work in VS2019, because it somehow fails to resolve the new vesions of the TFS assemblies, despite having "Specific Version"=false for the references.

Manual matching of the assemblies to the loaded assemblies in AssemblyResolve fixes the issue, though:

	YourVsixPackageConstructor()
            AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
        }

        private System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
        {
            if (args.Name.StartsWith("Microsoft.TeamFoundation.") || args.Name.StartsWith("Microsoft.VisualStudio.Services.")) {
                var aname = new System.Reflection.AssemblyName(args.Name);
                foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
                {
                    if (asm.GetName().Name == aname.Name)
                        return asm;
                }
            }
            return null;
        }

Get BranchName out of svnDirectoryName

Hi! [VS2019]
I am using svnDirectoryName to address SVN specific values, fine.
I can use svnDirectoryName:0 to get the current SVN directory path
I can use svnDirectoryName:1 to get the relative URL like abc/branches/xyz
And nothing more, because higer numbers results in empty string, right?

Is there a way to get the substring of svnDirectoryName:1 to address the last part BranchName, like svnDirectoryName:1:-1?

Support title in compact menu

Support change of the title when using the compact menu in VS 2019.

The compact menu can be activated in Visual Studio 2019 in Tools -> Options -> Environment -> Preview Features -> Use compact menu and search bar.

Without the compact menu:

With the compact menu - see the solution title to the right:

Display TFS Branch Name?

Hi,

I was wondering if it is possible to include branch names from TFS, like you can with Git?

Thanks for a great little utility, even without being able to get TFS branch names, simply being able to show directory names is enormously useful in identifying which branch you're working on.

Thanks again, Mark

changing window title for TFS - Code Review

Great tool!
I use TFS, wonder if is there a way configure window title when working on code review.

Kind regards
Luis

Does not work

Trying to use Solution override

Seems to have no affect

Add support for environment variables

I have a solution that I often have open with multiple Visual Studio instances, that differ only by the environment variables passed in when VS is started. It would be awesome to be able to print the contents of an environment variable into the title, maybe with something like [$myVar].

Feature Request - Generalisation of the title formatting

As far as I understand, the extension is capable of running of external utilities for gathering required information to generate the title (e.g. git). Why not give an option to run an external executable or cmd script with selected parameters chosen from the current extension options to let the external utility to generate a title content of its choice?

Slow VS2017 overall performance when title contains current Mercurial branch

Seems like it happened after recent automatic updates.

On quite large project scrolling started to lag a bit and switching between open tabs lasted like eternity (500 ms maybe). Also VS was eating 30-40% CPU in idle. After disabling vs-customize-window-title performance was back to normal.

I was using stock settings with Mercurial branch name added before everything.

Microsoft Visual Studio Professional 2017  (2)
Version 15.9.9
VisualStudio.15.Release/15.9.9+28307.518
Microsoft .NET Framework
Version 4.7.03190

Renaming fails if open document is project properties

Installed Version: 3.3.1 (installed just now (2016/10/13))
VisualStudio 2015 Professional Update 3

After installing the extension and re-opening VS, I recognized that the title has not been renamed. I did not change any of the settings for the extension so everything is default. When enabling the debug option, the output window shows this:

RenameVSWindowTitle: UpdateWindowTitle exception: System.ArgumentException: Value does not fall within the expected range.
at EnvDTE80.DTE2.get_ActiveDocument()
at ErwinMayerLabs.RenameVSWindowTitle.RenameVSWindowTitle.GetNewTitle(Solution solution, String pattern, SettingsSet cfg)
at ErwinMayerLabs.RenameVSWindowTitle.RenameVSWindowTitle.UpdateWindowTitle()

When switching from the project properties window to a normal cs file, it works. Switching back again leads to the shown issue. So I think one will only recognize this, if the project properties window was the last active document when opening a solution.

Error loading Extension

I've just attempted to open VS 2017 and I'm getting a load error.

From the Activity Log.

It would seem this is an issue with the latest update as this was working last week, before the update.

Regards,
John

Feature Request - Global IsAnythingDirty tag

A new tag that can be applied to the title to indicate if there are any unsaved changes in the solution

String Operators to simplify title?

I have a huge solution and to identify the project i am working on i need to pull more data than just the solution name or project path. These features are available but at the end title is not readable for me to identify. Can you add string operators like replace, substring, or at least if operator :). i dont know the technical side but it would be great. Thanks.

Workspace isn't updating

When jumping from workspace to workspace in Team Explorer, the Workspace name in the Title doesn't update.

Add [solutionFilterName] in addition to [solutionName]

Can't find this possibility in the current tool. Would be handy as i have started to actively use filters.

Add indexes to svnDirectoryName similar to path

I would like to have the indexing found with the path tag with the svnDirectoryName tag.
For example a branch I'm working on is "/Branches/Developers/<my name>/<branch name>" and all I really need is <branch name>.
I have a working solution to this if it's ok to submit it

Extension is disabled at startup

If I run VS2015 as administrator the extension is enabled. If I run VS2015 as normal user the extension is disabled at startup. If I enable the extension and I close and reopen the IDE the extension is disabled again.

System.ObjectDisposedException: Cannot access a disposed object.

VS2017 crashed when I try to close it. DebugDiag shows this stack for System.ObjectDisposedException

System.ObjectDisposedException    Cannot access a disposed object.    

EnvDTE80.DTE2.get_MainWindow() 
ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.UpdateWindowTitleAsync(System.Object, System.EventArgs) 
   System.Windows.Forms.Timer.OnTick(System.EventArgs) 
   System.Windows.Forms.Timer+TimerNativeWindow.WndProc(System.Windows.Forms.Message ByRef) 
   System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr, Int32, IntPtr, IntPtr) 

So MainWindow was already disposed during close and your UpdateWindowTitleAsync methode should check this.

//Edit:

on next start VS notified me that your extension was the cause:

Feature request: GitRepository

Feature request: It would be great if you could add a tag to get the gitrepository, as you have now to get the gitbranchname

title in taskbar does not match title bar

Hi,
I have a strange problem. I'm using this format: [solutionName]\[hgBranchName]
resulting in a title like so: Crm\fb-5.3-PRJ-504-1481-api-versioning

The title is displayed in the the title bar and in the task bar.

but after a few seconds after a build it changes to something ugly like this:
Crm\fb(fb-5.3-PRJ-504-1481-api-versioning) 5.3PRJ5041481apiversioning

This ugly string appears only in the task bar (or in output of tasklist /v). The title bar in visual studio is displaying the correct string.

When I update the format (add a space) it changes to the correct string again.
This is only happening since the last couple of weeks (can't tell for sure if it was the last update of this extension).

I activated debug mode, but there is nothing logged when the ugly title appears. Can I provide other details to track this down?

Global override settings not being picked up

Hi there - I have a global settings file set up to configure furthest parent depth, due to the structure of my SVN repository. The actual branch name in the path is configured to be a wildcard.

I have saved this file and configured the add-in to look at this config file using the "global settings override file path" setting. The problem is, however that the settings are completely ignored. The settings are being overridden by what is in the config dialog window, not the config file.

Is there somewhere else I need to set the addin to look at the config file, not at the config that is set up in the dialog window? Or is there something wrong with my config file? I've tried toggling the debug output but it doesn't give me any information apart from "RenameVSWindowTitle: Debugger context changed. Updating title."

Thanks!

<?xml version="1.0" encoding="utf-8"?>
<RenameVSWindowTitle>
  <SettingsSet
    Path="C:\SVN\branches\*\Primary\SubDir\MySolution-Primary.sln"
    SolutionName="MySolution-Primary"
    ClosestParentDepth="1"
    FarthestParentDepth="3"
    AppendedString="*"
    PatternIfRunningMode="[parentPath]\[solutionName] (Running) - [ideName]"
    PatternIfBreakMode="[parentPath]\[solutionName] (Debugging) - [ideName]"
    PatternIfDesignMode="[parentPath]\[solutionName] - [ideName]" />
  <SettingsSet
    Path="C:\SVN\branches\*\Secondary\MySolution-Secondary.sln"
    SolutionName="MySolution-Secondary"
    ClosestParentDepth="1"
    FarthestParentDepth="2"
    AppendedString="*"
    PatternIfRunningMode="[parentPath]\[solutionName] (Running) - [ideName]"
    PatternIfBreakMode="[parentPath]\[solutionName] (Debugging) - [ideName]"
    PatternIfDesignMode="[parentPath]\[solutionName] - [ideName]" />
</RenameVSWindowTitle>

Visual Studio minor version tag

Hi!

It's really nice extension!
However, what is really lacking to me is the IDE minor version.
The thing is that IMHO [vsMajorVersion] is not quite useful as it's quite rare when you work with different Visual Studio major versions at the same time (like 2015 and 2017), however, it is really handy to have minor version currently installed on your system (like 15.7.1) as these days VS updates very often and you always can see if you need to upgrade or not.

So, can you consider adding that as well?
Thanks!

NullReferenceException in Visual Studio 2015 on startup

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe

ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.UpdateWindowTitleAsync(object, System.EventArgs)

An unhandled exception of type 'System.NullReferenceException' occurred in CustomizeVSWindowTitle.dll
Object reference not set to an instance of an object.

This might be a conflict with the Clang Power Tools extension, which is also not loading correctly.

Update to asynchronous API for VS 2019

https://blogs.msdn.microsoft.com/visualstudio/2018/05/16/improving-the-responsiveness-of-critical-scenarios-by-updating-auto-load-behavior-for-extensions/

[startupProjectsNames] adds nothing to the title

My solution has .NET Framework and ASP.NET Core projects. Regardless of which project is set as the startup project, nothing gets added to the title string. VS2017 15.7.6.

The debug output keeps dumping this:

CustomizeVSWindowTitle: ReplaceTag (startupProjectsNames) failed: System.ArgumentException: The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))
at EnvDTE.SolutionClass.Item(Object index)
at ErwinMayerLabs.RenameVSWindowTitle.Resolvers.StartupProjectNamesResolver.GetStartupProjectNames() in C:\Users\erwin\Dropbox\Projects\GitHub\vs-customize-window-title\CustomizeVSWindowTitle\Resolvers\SolutionResolver.cs:line 47
at ErwinMayerLabs.RenameVSWindowTitle.Resolvers.StartupProjectNamesResolver.Resolve(AvailableInfo info) in C:\Users\erwin\Dropbox\Projects\GitHub\vs-customize-window-title\CustomizeVSWindowTitle\Resolvers\SolutionResolver.cs:line 29
at ErwinMayerLabs.RenameVSWindowTitle.CustomizeVSWindowTitle.<>c__DisplayClass53_0.b__0(Match match) in C:\Users\erwin\Dropbox\Projects\GitHub\vs-customize-window-title\CustomizeVSWindowTitle\CustomizeVSWindowTitlePackage.cs:line 479

[gitBranchName] is empty for detached head

The extension is truly awesome! However, [gitBranchName] behaves somewhat unexpectedly in case the repo in a detached head state. Specifically, the tag resolves to an empty string. When I first time installed the extension, I thought the feature was simply not working, since I was in the detached head state. I spent quite some time trying to understand what's happening.

Proposal: use a clear substitution in this case. Something like detached HEAD.

Add path arguments for git branch name

Hello,
Obiviously that's a feature request, not an issue :), but not sure how can I label it as such.
Would it be possible to allow setting the path arguments for git branch name, e.g. [gitBranchName:1]

The use case is - we have a project where branches are like so
/Production/1.0
/Production/2.0
/Production/1.0/dev/user/feature

So, with this approach, if I have a version 2.0 branch open, along with 1.0/dev/user/feature, my VS window title is not helpful, as it shows only "Producti....".
It would be good to see "1.0" or "user/feature" for example.

Cheers
Bartosz