Viasfora: a Visual Studio 2022 extension for text colouring and presentation tricks

Rainbow braces colour the editor by nesting depth

Viasfora is a Visual Studio 2022 extension whose main pitch, in the README's own words, is that it enhances the text editing experience. The flagship feature is rainbow braces, which colour parentheses, square brackets, and curly braces according to their depth. In a deeply nested block of C# or JavaScript, the point is that you can see which closing brace belongs to which opening one without counting lines.

Around that sit three colourisation features for keywords. Flow control keywords are coloured, so if, else, foreach, and the rest stand apart from ordinary identifiers. LINQ keywords get their own treatment, which is useful in a language where query syntax and method syntax both appear in the same file. Visibility keywords are coloured as a third group, picking out public, private, protected, and internal.

String handling is the other half of the colourisation work. Escape sequences inside strings are highlighted, so a \n or a \t does not read as ordinary text. C and C++ format specifiers inside strings are highlighted too, which matters in native code where printf style strings are everywhere.

Each of these is a small thing on its own, and the value is cumulative. The README presents every feature with a screenshot from viasfora.com, which is the pattern: a catalogue of editor refinements rather than one large feature.

Text obfuscation hides code during a presentation

The feature that no built in editor has is text obfuscation, and it is aimed squarely at people who demo code. The README describes it as an easy way to hide text in the editor during presentations, based on regular expressions. You write a pattern, the matching text is hidden, and the slide stays readable.

The interesting part is where the pattern applies. A regular expression can match anything the editor holds, not just identifiers. That means you can hide a method body, a specific string literal, a licence header, or an entire block, depending on what you write. The limit is whatever the regular expression engine can express, and the README does not document any preprocessing of the pattern or a preview of what will be hidden.

Configuration is done in a dedicated dialog, and the runtime control is a menu command in the Visual Studio menu bar: View, then Obfuscate Text. The feature is therefore a toggle rather than a per region annotation, and the pattern is global to the editor for as long as it is on. The README does not say whether the setting is per document or per solution.

This is the reason to install the extension, and it is also the reason to be careful with it. Obfuscation that is too broad hides the code you meant to show, and because the mode is a menu toggle rather than an inline marker, you have to remember to turn it off before you start editing for real.

XML editing additions: prefixes, matching tags, namespace resolution

The XML section of the feature list is the most substantial part of the extension. Four things are added to the built in XML editor.

Namespace prefixes are colourised, so the prefix on an element is visibly different from the element name. Closing element tags are coloured, which is a small but effective cue when scanning a long document for where a block ends. Element tags are matched, so the editor relates an opening tag to its closing tag. And namespace prefixes are resolved, with the screenshot for that one captioned as an XML prefixes tooltip.

Together these add up to something that is easy to underestimate until you work in a document with a lot of namespaces. The default editor handles XML, but the default editor does not colour the parts of the syntax that help you read a large document quickly.

The rest of the extension is a short list. Presentation Mode is listed separately from obfuscation, so the two are not the same thing. There is simple modelines support, and there is an editor margin for extension developers, which is a developer facing feature aimed at people writing other Visual Studio extensions rather than at end users. Every option is configurable from the Visual Studio Options dialog, which is the point where the extension stops being a set of hard coded behaviours.

Most features cover a wide set of languages, but not all of them

The language support section is where the practical limits of the extension become visible. The README says most features include support for the following languages.

* C/C++
* C#
* VB, VBScript
* F#
* JavaScript
* SQL, U-SQL
* TypeScript
* Python
* PowerShell
* CSS, SASS, LES
* S
* R
* HLSL
* Fortran

That list is long, and it covers most of what a polyglot .NET shop touches. The caveat is the word most. The README does not say which features are excluded on which languages, so a Python developer should not assume that every rainbow brace and every keyword class behaves identically to the C# case, where the classification rules come from the C# language itself.

Some entries in the list are also hints about the implementation. SASS and LES appear as separate items, and LES is a lesser known stylesheet language, which suggests the extension identifies stylesheet languages individually rather than through a general stylesheet parser. U-SQL alongside SQL suggests the same. HLSL is the shader language used in graphics pipelines, and Fortran sits at the end of a list dominated by web and .NET languages, so it is a plausible late addition rather than a first class target.

For a decision maker, the useful question is not which languages are listed but whether the one you care about behaves as you expect, and the README does not answer that beyond the list.

Installing the extension and building it from source

The README does not give a command line installation, and there is no package manager entry for an editor extension of this kind. The distribution route is the extension itself, obtained from the official site at viasfora.com or from the project's release page, and installed into Visual Studio as an extension. The release page is also where the version history lives, and the README points to a specific older tag for a specific reason, described below.

The build instructions are short because the toolchain is a single requirement. Visual Studio 2022 is needed for building from source. The repository layout supports that: a Viasfora.sln solution at the root, a src directory, a tests directory, a themes directory, a Global.props file, and a root.marker file, with an appveyor.yml file driving continuous integration. An .editorconfig is present too, which is a reasonable sign for a project with a large number of source files.

The C# language is the primary one for the project itself, which is the usual choice for a Visual Studio extension. The tests directory and the CI configuration are the parts a reviewer would look at to judge whether changes are covered, and neither the README nor the repository listing says how much of the behaviour is under test.

For a user rather than a contributor, the practical advice is to install the prebuilt extension and ignore all of this.

A custom licence and a three year gap in the release history

The licensing here needs reading rather than assuming. The repository is classified as Other, meaning a custom licence that GitHub cannot map to a known category, and the terms live in a license.txt file at the repository root rather than in a LICENSE file with a recognised name. For a personal tool that is usually not a problem, but anyone shipping Viasfora inside a corporate build, or contributing changes and wondering about the terms of that contribution, has to read that file. This is not a licence you can reason about from memory, since it is not one of the standard ones.

The release history has an odd shape. Version 4.4 was published on 2022-05-09, version 4.5 on 2023-07-04, and version 4.6 on 2026-02-01. Nearly three years passed between 4.4 and 4.5, and the version numbers tell you the project moved from the 4.x line with no sign of a 5.0 renumbering.

The other date in the README is the one that matters for anyone on an older IDE. The last version supporting Visual Studio 2019 and previous releases is v4.3, linked directly from the README. So there is a clean cut: 4.3 and earlier for Visual Studio 2019, and 4.6 as the current release for Visual Studio 2022. That cut is the practical upgrade cost, since adopting the current version means moving to Visual Studio 2022 as well.

The last push to the master branch was on 2026-10-04, and the project is not archived, so work continues after the 4.6 release.

Editorial conclusion

Viasfora suits developers who edit in Visual Studio 2022, present code in front of an audience, or work in a mixed language solution where keyword and string colouring saves time, and it is a good fit for anyone who wants these editor touches without leaving the IDE. It is the wrong tool if you need Visual Studio 2019 support, because the last release covering that IDE is v4.3, or if you need a licence with a known set of redistribution terms, because the project ships a custom licence.txt that GitHub cannot classify. Before installing, read license.txt, check that the current version targets Visual Studio 2022, and test the obfuscation command on a scratch file, since the feature hides text with regular expressions and a bad pattern can hide more than you intended.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. tomasr/viasfora on GitHub