Lexx9999

[lexx9999]

Hi mayerwin,

fortunately you changed "Rename Visual Studio Window Title" to C#. Therefore I implemented an [alternateSolutionName] pattern.

alternateSolutionName supports either a .renamesln file (nearby .sln) or a central RenameVSWindowTitle.txt file for renaming.

Also I fixed the backslash removal (and UNC support) for parentPath, and optimized the replacement logic.

Finally I added a git directory option, for those guys like me who don't want to modify the PATH variable.

Interested?

BR Harald aka lexx9999

[mayerwin]

Thanks @lexx9999 for this PR. I have merged it and made substantial changes to your code afterwards to generalize the feature it provides.

Instead of only allowing to override the solution name, it seems best to support overriding the whole pattern (under the different IDE modes) and even other settings on a per solution-file basis, through JSON config files. I liked the 2 layers you suggested (one lower priority override possibly next to the targeted .sln file, which can be committed if need be, and a higher priority in a global config file that can be placed anywhere on the computer). I tried to make sure this would have zero performance impact on people who don't need these overrides (opt-in in settings).

This feature is quite welcome as it fixes a previous limitation and provides a welcome basis for future extensibility. Users will now be able to implement their own manual (possibly weird), already replaced, tag values in solution-specific pattern overrides.

I did a quick test and the updated extension seems to work, but do check on your end and let me know your feedback. I have already updated the Gallery to mention this update (with a link to the beta vsix), I would like more certainty this release is not going to break existing installs before marking it a stable (the objective is to support VS 2010+). I have not tested the extension thoroughly since the 2.8.1 stable version (which was in VB.NET), which nobody has complained about. Unfortunately Microsoft doesn't provide an easy way to test extensions on older VS versions.

[lexx9999]

Well... basically I like the idea of being more flexible. Unfortunately [alternateSolutionName], which was the reason of my changes, was kicked out, although in the copy pane it's still mentioned. The solution name matching is strange with EndsWith.

And in my opinion JSON is really not suitable for a configuration file (no comments), even worse one JSON dictionary per line is really bad if there are customized patterns. I was founded for data transmission, not for configuration. I therefore recommend XML, and each c/vb/..# developer should be familiar with it. Also the information is only loaded once, if you change something you have to restart visual studio, for every change. not good.

Therefore.. I'm currently working on a patch to

• switch to xml config (DONE)
• makes [alternateSolutionName] working again(DONE)
• detects file changes (with some delay) (Even in my earlier implementation it was no performance issue due to file time checks). (DONE, but have some better idea)
• updates Title right after settings change (DONE)
• clear cache on solution open/close/rename (DONE)
• refactor current settings into its own class (DONE)
• some way to copy/generate a default config (TODO)
• avoid having to grant permission when copying tags. (DONE)
• separate the pattern-control settings in a separate category (DONE)
• only reload config files if necessary (TODO)
• more flexible matching for solution paths/names (TODO) (currently a single full path or just name).

I'm not sure if it's a good idea to use newer language features if you want to use and debug it in older VisualStudio versions. Debugging used to work for me only well if .net runtime of the addin matches to VS ones.

I'm going to provide a PR once I have a stable version, likely takes some days.

[mayerwin]

Why do you need a standalone alternateSolutionName? You should simply write the whole pattern in a solution-specific file, where you can include your alternate solution name (hardcoded) as part of the pattern. I have not much against adding this tag (as an additional KeyValue pair in the config override), but I aim for extreme simplicity with this extension (while still providing enough optional and non confusing extensibility, which I believe the idea of offering a solution-specific configuration override helps with), this is I believe how it has been able to consistently keep a very high rating.

For the configuration file, I suggest switching to YAML. Not sure who would want to comment configuration elements (it's not supposed to be a very complex configuration file), but I like YAML, it is very human-readable, lighter and less error prone than XML (many people including me try to avoid XML whenever possible). YAML supports # line comments.

I agree that we could change the solution name matching to support wildcards instead of just end-of-string matching. I don't think supporting a RegEx would be appropriate, at least for now (I have yet to hear of a single power user who would make use of it for this simple extension).

The single loading of configuration overrides is on purpose; you are not supposed to change it once you have opened the solution (why would you?), and it therefore saves some unnecessary I/O. If you think we really need this, I recommend using http://stackoverflow.com/questions/721714/notification-when-a-file-changes for this purpose instead of checking for file date/time. If it doesn't cause any I/O while waiting for a file change (it seems event based), then maybe it could be enabled by default (provided users have already opted in for Solution specific overrides). If there is a continuous I/O overhead, it should be added as an Opt-in option (Boolean) so that most users are not penalized by it.

Regarding "I'm not sure if it's a good idea to use newer language features if you want to use and debug it in older VisualStudio versions.", Visual Studio 2015 Community Edition is free (thanks Microsoft) so anyone should be able to use it for development and debugging. Please note that these C# 6.0 language features should not impact the extension supporting older versions of Visual Studio (targeted C# Framework is still 4.0). Normally the VSSDK libraries referenced support Visual Studio 2010+, so even if you don't debug the extension against these older versions, it should still work (the DTE APIs are the same). And we are not doing anything complicated with the IDE (it is not Resharper :) so it shouldn't be too much of a reason for concern.

I look forward to seeing your PR, thanks for your contributions, your feedback is very welcome.

[lexx9999]

Well I have some special needs, because the solutions are generated out of source and estimated twice a month we need to delete the all built and generated files due to structural changes (It's a really huge project). Thats the reason for the global renaming. Right now I would not need the solution based files anymore, but I thaught others might use it.

Right now I have about 6 checkouts of the sources with each having 2 primary solutions, where I often have 4 solutions opened in parallel, plus some more where I don't need the renaming.

With the alternatesolutionname I have a setup like: path1/slnA.sln : n1 path1/dir/slnB.sln : n2 path2/slnA.sln : n3 path2/dir/slnB.sln : n4 path3/slnB.sln : n5 path3/dir/slnB.sln : n6 path4/slnB.sln : n7 path4/dir/slnB.sln : n8 path5/slnA.sln : n9 path5/dir/slnB.sln : n10 path6/slnA.sln : n11 path6/dir/slnB.sln : n12

With alternateName, I have the same patterns for all, thus I need a configuration of 12 names. Without I need 12_3 patterns, and if I wan't to change the pattern I need to change 12_3+1 places.

Load config once. Especially for the suggestion to solve alternateSolution as pattern, this would require 12*3 openings of solutions to verify all changes work. The biggest problem here is if you wan't to play around with settings. Your implementation reused the cache if the same solution was reopened. Meanwhile I use a filesystemwatcher (which was the idea) which leads to zero performance loss if nothing is changed plus almost immediate reload.

I get the point of ease of use. Since current implementation has almost no performance impact [solutionName] behaves now like [alternateSolutionName].

YAML would require a separate dll and is even less known as JSON/XML, therefore I would vote against it. Maybe I'll add support for both XML/JSON.

Regarding matching. Regex would not bring that big benefit, but for some users it could be interesting to use the same set of patterns for a set of solutions, like: full-example-without-alternate.xml I was already bored after creating two rename by pattern sets, therefore only two.

BTW: You don't wan't to replicate such complex patterns 3 times per solution, aren't you?

Despite regex could be useful if the regex captures can be used in the patterns. Maybe a futureversion ;)

If there would be UI for settings overrides, neither JSON nor XML would matter, still because all .net settings are xml .. prefering xml.

BTW: For you the override feature makes it really easy to test. You just need to customize patterns for some dummy solutions.

If you wan't to have a look at it, I submitted a draft to my fork of the repo.

attachments: vs-customize-window-title-examples.zip

[mayerwin]

OK, I can see that you have a quite particular heavy use case of solutions... I am fine with keeping a [alternateSolutionName] tag, hopefully you'll not be the only one needing it.

Let's go for the filesystemwatcher, since there should be no overhead for people who don't need this feature, it's always good to have and by auto-loading settings overrides will probably help avoid questions of people who have not RTFM :).

I like the repackaging of options into their own class and improve the merging process (my implementation with dictionaries was a bit quick & dirty).

I also don't like having to bloat the extension (right now it fits in an amazing 50 KB), so maybe we can forget about YAML and stick to XML with attributes (as long as the UI supports generating a config file, then I agree it matters less and default serialization format could be XML).

I agree with your comments on Regex (reusing captures in the pattern), let's keep that for a future version. Most people definitely don't need this, but if we can preserve the philosophy of a simple, easy to understand basic usage, and allow optional intuitive extensibility then it's a noble goal to achieve (Dropbox desktop client got the basic usage right but failed on the extensibility for example).

Regarding the 3 patterns for debugging, design and running, it is IMHO a small hassle (no one has ever complained). A copy paste is not that hard and we leave the responsibility on the user to use the pattern they really want for each mode (initially, this was to allow proper localized strings to be defined by the user himself). Most people probably don't change the default patterns anyway. If we really want to support a simpler one-liner pattern, an appropriate non confusing UI would then be to have a checkbox asking if the user wants to customize the pattern for each mode, if yes display the 3 full patterns (as now), if not only show a single common pattern and 3 fields to localize only the mode string (or localize it ourselves through other means if we can). But then good luck having a non confusing configuration file (which setting override takes precedence over which would not be obvious)...

Let me know when you have committed all the changes you are working on so that I can re-review (i have already checked your draft commit, but prefer to wait until you have finished implementing all your thoughts).

[lexx9999]

Ok, please have a look at the current state. Especially the settings editors ;) and settings overide file creation.

For simplicity solutionName now behaves like alternateSolutionName, because there is no performance difference, due to the optimizations made for config loading.

In addition to [parent] I just added support for (path means solution path): [parent-] [path] [path-]

With this ClosestParentDepth, FarthestParentDepth and [parentName] are somehow obsolete now.

What do you think about tolerating case mismatch like [solutionname] [SOLUTIONNAME](that's not a big deal with the new replacing logic)?

BR Harald

[mayerwin]

Thanks for your latest changes. Nice work. I just published a new 3.2.0 release, hopefully stable. Feel free to check the source code and final result. I have reviewed and incorporated your changes and made a number of bugfixes and adjustments.

I prefer not to enable case insensitivity for tag names for now. It is not too hard to respect camel casing and to get immediate feedback from the way the extension behaves if the tag is not working. However for solution file name path matching we can tolerate case insensitivity as Windows doesn't differentiate anyway. I have implemented what I hope will be a more intuitive [path:X:Y] and [parent:X:Y] format. I agree that ClosestParentDepth etc. should probably be deprecated now as the current default is equivalent to using [parent:1] in the pattern, but they should still be supported forever unless there is a very good reason not to. Or we should devise a migration path to convert legacy settings into proper tags (error prone). The legacy [parentX] tag still works but the preferred tag is now [parent:X].

I have moved the GUI you created to manage XML files to a dedicated section for solution-specific overrides (it didn't really belong to "Supported Tags").

Let me know if you encounter any issue or have any further suggestion.

[lexx9999]

Well at least the version I provided, works quite well.

I have moved the GUI you created to manage XML files to a dedicated section for solution-specific overrides (it didn't really belong to "Supported Tags").

Nice, I wasn't really happy with it.

I'm thinking about exposing the process-id as tag. That could be usefull to select the right process to kill in task-manager. Not sure if this would be of general interest.

Will take a look at the new version soon ;)