This release represents a turning point for our development team. We’ve made great strides in fixing bugs associated with Visual Studio 2019 and have focused our attention on the future. A major lift in this release was our move to Clang 9. Future releases will leverage Clang in new ways so stay tuned! But Build 2353 wasn’t all about groundwork, Code Inspection has some nifty new features:
+ Code Inspection checkers are now more configurable. Further customize when Visual Assist alerts you of potential improvements.
+ Code Inspection UI is now searchable, and exposes more advanced information.
+ Code Inspections can now be selectively disabled in sections of your code using comments. If you don’t want to change a section of code, you can choose to not be alerted of potential improvements without disabling checkers globally.
+ New UI allows fine grained control of the resources Visual Assist will use when parsing. Reduce the impact of the initial parse of a new solution, especially in extremely large solutions where parsing may take several minutes. (Unreal Engine developers take note.)
The last build of Visual Assist, i.e. build 2341, introduced a bug for users of Microsoft Visual Studio 2019. If you use Microsoft’s newest IDE and installed build 2341, download and install build 2341.2.
Build 2341.2 requires software maintenance through 2019.08.05.
The steady stream of functional and quality improvements to Visual Assist continues despite the recent hiccups with new purchasing and licensing systems. (Those systems are being ironed out.)
Visual Assist build 2341 improves one of its earliest features—enhanced syntax coloring—with the ability to set separate coloring for namespace identifiers and qualifiers, and enum members. Separate coloring of namespace identifiers and qualifiers was implemented primarily so the qualifiers can be dimmed, making it easier to read “remaining” code.
Another early feature of Visual Assist, Quick Info, became an enhancement to Visual Studio when Microsoft introduced its equivalent eons ago. Visual Assist build 2341 enhances the feature yet again by including in tooltips comments from parent classes. The additional comments are especialy valuable when referencing methods that override well-documented ones. Comments for the current symbol now include those from the immediate parent class, and the root parent.
Finally, build 2341 improves Encapsulate Field, a refactoring that lets you restrict or filter access to a member field. Encapsulate Field now allows an accessor to be omitted.
Build 2341 requires software maintenance through 2019.07.11.
You’ve spoken, and we’ve listened! Our recent website and license migration failed to deliver the high quality experience you deserve.
Recently, Whole Tomato migrated our website to a new backend technology and a much needed new license technology for Visual Assist. There have been some hiccups, and some of the changes to licensing resulted in delays sending licenses to customers, and concerns expressed to us. We’ve heard you. In this post we’d like to cover what changed and why for both the website and licenses, as well as what steps we are taking to address concerns.
Whole Tomato Website
We migrated the main Whole Tomato website, wholetomato.com, to the same backend used by other Idera websites. This retained all existing content and ensured our web team only needs to maintain one server stack.
However, there is no reason to ask for licensed customers’ information again when downloading a new build of Visual Assist for which you are already validly licensed. This has been pointed out to us, sometimes quite vocally, both through support and online. We hear you. The website no longer requires customers to enter personal information to download new builds.
The new website should also be more stable and faster.
At the same time, we also changed the technology used to generate and validate license serial numbers for Visual Assist. Once again, this is to ensure a single technology is used across multiple products. It’s also a benefit for you because this licensing technology reduces uncertainty about licensed usage and decreases over deployment compliance issues, which is something that many large customers request. No one wants to be in a situation where audits are necessary – you don’t, and we don’t.
It’s a great goal, but customers have reported two issues: delays in generating new serial numbers after purchase and concerns about individual registration data, even for large volume serial numbers.
Let’s look at the current license options available, and changes we plan to introduce in the future.
Current License Options
When you purchase a Visual Assist license, you have the following options:
As an individual:
You purchase and get a serial number. You need a user account (see below) on our website, and your serial number is registered against that account. You can use this serial number on multiple VMs, so long as the serial number is used only by the same person.
As a company:
You purchase and get a serial number, one per developer. Just as for individuals above, each serial number must be registered against a developer’s EDN account. Each developer can use it on multiple VMs.
You purchase a multi-user serial number. This is a single number that is valid for multiple people. Just as for normal serials, when any individual developer installs and registers Visual Assist, they will need their own user account. Each developer can use it on multiple VMs.
There are also some temporary options that you may have seen if you encountered issues: a manually generated legacy serial number using the old license system, and an eSlip file, which is a single license file shared for a team but requiring an internet connection. We’ve used these for limited cases when none of the above licenses work for a team due to technical reasons.
The licensing changes are new to us too, and we may not have clearly explained them when you purchased or contacted Support.
What is a user account? User accounts provide a single licensing account across all Idera-owned products. Create yours here, and then use those login credentials when registering your license.
Right now, the webpage is not ideal, and we’ve had some feedback about that too. More on what will change there below.
Licenses In The Future
The majority of issues we’ve seen have been to do with a missing use case: a team with multiple developers who either wish to not register individually or need to use the license in a disconnected environment. We believe it’s reasonable for personal or individual users to register via an account, but we understand it’s a barrier for some larger teams.
Within the next week, we are adding a new license option to address this scenario. If you are a large company with many developers, or you operate disconnected from the net, you will be able to purchase a network named user license. This is a single license shared by the whole team. Individuals can use it on multiple VMs. No internet connection is required: instead, you run a license server on your internal network, which manages all verification without contacting us.
You’ll be given this license option if you purchase Visual Assist for a team of five or more, or by request to our sales / licensing team.
Running a license server may not be ideal for some teams with strict IT requirements. If your team is unable to use this option, you can always contact our sales or license teams to discuss some other options we can make available.
This retires eSlip licenses (except through licensing support requests) and legacy serial numbers, leaving three license options:
Personal use, or multiple individual developers: individual serial numbers, registered for each developer through your user account.
Multiple individual developers in a small team: a multi-user serial number, registered for each developer through your user account.
Multiple individual developers in a large team, or by request for small teams: a network named user license, with no registration or internet access required.
We also expect the speed of license generation to be faster at the same time we introduce this new option. Note our staff don’t work weekends, so if you order on a Friday, you may not get your serial number until Monday. Orders during the week should be next-day or sooner, and we aim to process each one within a few hours.
License support requests are also now handled by a dedicated team with experience with this license technology. That means they are familiar with the issues you may encounter and should be able to speedily resolve them. They have a dedicated email address: email@example.com. (You can email this directly. If you contact normal support, your email will also be forwarded to and handled by the dedicated license team.)
In addition, we are replacing the user account website, with a planned launch date in early July. This is a brand new version of the user account website, built in Ext JS, where you will be able to create an account and view all your registered products and serial numbers. It will be quite minimal, clean, fast, and should be a lot clearer to use than the current website.
We rolled out a new website and new license system, and neither was quite perfect
You will not need to enter personal information to download your licensed software
The license system and where and how to use your account may not have been well explained, and we hope the above makes it clearer
We’re introducing a new license option, Network Named User License, that works better for large teams and teams who work offline
In prior versions of Visual Studio, the VAssistX menu is opened via a single Alt+X. That shortcut, fortuitously, now opens the Extensions menu. In Visual Studio 2019, a subsequent X opens the VAssistX menu within the Extensions menu.
If you are a keyboard user of Visual Studio 2019, use Alt+X, X to reach any VAssistX command previously reached with Alt+X. And when you in the documentation for Visual Assist, know that you must use Alt+X, X every time you read Alt+X.
Those looking to restore old behavior in Visual Studio 2019 might find Extensions in Main menu useful. If you try the extension and want a single Alt+X to open VAssistX, use ‘Tools | Customize |Commands’ to change the accelerator key for Extensions, e.g. from &x to &i.
Extensibility has long been a strength of Microsoft Visual Studio, but extending the IDE too greatly can impede its startup. Thus, many developers are familiar with Visual Studio’s yellow status message that suggests an extension is likely causing slow startup. To alleviate slow startups, Microsoft has encouraged partners to load their extensions asynchronously. That encouragement is now a requirement in Microsoft’s latest IDE. In Visual Studio 16.1 Preview 1, extensions must load asynchronously.
Visual Assist build 2331 supports Visual Studio 16.1 Preview 1, and therefore loads asynchronously. In the new IDE, Visual Assist loads as soon as possible, often without noticeable delay. But, there are a few startup scenarios, e.g. when starting Visual Studio without a solution, that do expose subtle changes in loading.
You will know that Visual Assist is completely loaded in Visual Studio 2019 if the extension responds as you expect, or when notice appears in the status bar.
Visual Assist is not completely loaded if it looks or feels broken in the moments after startup, before a solution is loaded, or within seconds of loading a solution. Signs of incomplete loading include a toolbar that begins with disabled icons,
empty tool windows,
and failure to respond to commands in an editor window.
If Visual Assist is not completely loaded, coax it along by opening a solution, then wait a few seconds. If you try a command in an editor window and the command doesn’t work, simply retry it. Loading should have completed in the interim.
Build 2231 also adds a new command to insert a file path into the active document. The command is useful when working in strings and comments. Access Insert-Path via the VAssistX menu (Alt+X, T, P).
Build 2331 requires software maintenance through 2019.04.19
Microsoft’s recent spate of builds of Visual Studio 2019 is driving the recent succession of builds of Visual Assist. Build 2324 is no exception. It’s only feature of note is support for Visual Studio 2019 RC.
If, for some reason, you are still using Visual Studio 2019 Preview 1-3, Visual Assist build 2324 will install to your IDE, but know that Visual Assist is no longer supported in the environment.
Build 2324 requires software maintenance through 2019.03.08.
For those experimenting with Microsoft Visual Studio 2019, you will be pleased to know that support for Visual Assist in the preview releases of the new IDE is underway.
The two builds of Visual Assist, builds 2316 and 2318, were introduced in short succession to support the first two previews builds of the new IDE. Both builds install to all previews of the IDE, including to Preview 3, despite our installer’s claim it’s installing to Preview 2. Support is beta quality. See release notes for known issues.
Build 2316 includes several bug fixes, and just one additional improvement. The build improves access to the command to insert VA Snippets of large or infrequently used blocks of code. Open the VA Quick Action and Refactoring menu (Shift+Alt+Q) in whitespace, and select Insert VA Snippet.
Build 2318 includes support for a new licensing system that 1) includes a customer portal to track new licenses and their renewals of software maintenance, and 2) simplifies the adding of licensees to a team with the new licenses.
Beginning with build 2318, you can register a new license of Visual Assist using VAssistX | Help | Register. If you have a two-line activation key, you can reach the traditional enter-key dialog by opening the registration dialog, then clicking “Legacy product registration with two-line activation key” at its bottom.
Build 2316 requires software maintenance through 2019.02.05, and build 2318 requires maintenance through 2019.02.17
Honestly, the title of this post should be “Visual Assist build 2302 has been available for a long time”. I have been lax in writing.
Fortunately, if you enable notifications of new builds in the options dialog of Visual Assist, you would have discovered build 2302 not long after it was released. And if you clicked through a what’s-new link, you would have learned what improved with the build. I write today primarily for those who do not get in-product notifications of new builds yet follow these build announcements.
Build 2302, released mid-December, is a follow-on to build 2301—a build that did not reach the threshold of in-product notifications. Hence, this post describes what’s new in builds 2302 and 2301.
If you are one to “access the future of Visual Studio” and are already experimenting with Visual Studio 2019, build 2302 has preliminary support for the preview build of the IDE. See our release notes for known issues.
For those of you who have debugged multi-threaded applications, you have undoubtedly been annoyed by the debugger’s switching to a thread you are *not* debugging only because another thread hit a breakpoint. You lose context and have no easy way to return to debugging of the first thread.
Build 2301 introduces a command, Bind Breakpoints to the Current Thread, that does what its name implies. When enabled, other threads that hit breakpoints are automatically continued, and you can debug in peace. Toggle the command via icon in the Visual Assist toolbar, or entry in the VAssistX menu (Alt+X, B, T).
Build 2301 introduces another command, Skip All Breakpoints, to improve the debugging experience in Visual Studio. Until the build, switching between the debugging of different parts of an application was cumbersome. One could not tell the debugger to honor only breakpoints in a single part of an application; one had to skip unrelated breakpoints individually, or disable and lose them all. With Skip All Breakpoints, you can effectively toggle all unrelated breakpoints so they are skipped automatically. To debug one part of an application, Skip All Breakpoints, then return breakpoints in the one part to their default state. Get to the command via icon in the Visual Assist toolbar, or entry in the VAssistX menu (Alt+X, B, B).
For those who use Source Links to connect substrings in comment blocks to external applications and websites, you will be pleased to know that Visual Assist [finally] supports sharing of link definitions. When a solution is open, create a shared solution definition via the Add-button drop-down.
Shared solution definitions are created in a subdirectory of the solution directory, .va\shared\SourceLinks, that can be checked into source control that, in turn, makes the shared definition available in read-only mode to all users of Visual Assist.
Builds 2302 and 2301 also improve support for Unicode and UTF-8, and improve code generation for users of Unreal Engine 4 (UE4).
Build 2302 requires software maintenance through 2018.12.13.
Visual Assist build 2291 is a minor release that fine tunes several, well-loved features–ones that seem never to be finished.
Find References (Shift+Alt+F) in Visual Assist is the big brother of the like-named command in Visual Studio. (At one time, Visual Assist provided the only version.) The results window of the Visual Assist command has long allowed collapsing of project and file nodes, but the UI to that ability was ill-suited for large solutions. Build 2291 changes that. New commands in the context menu of a results window let you collapse and expand all nodes, or collapse just the file nodes.
Collapsing all nodes is especially useful before a Find (Ctrl+F) in the dialog, because the Find automatically expands the next node that contains a found string, making it easy to locate only references of interest.
VA Hashtags, a favorite of those who have learned to use the feature, has long allowed hiding and unhiding of “noisy” hashtags. But, unhiding could be applied only to all hashtags. Build 2291 changes that. With the build, and assuming hidden hashtags are shown dimmed, unhiding is now available on individual per scope of hiding: project, directory, file, and hashtag.
Open File in Solution (OFIS) (Shift+Alt+O), arguably the most-used feature of Visual Assist, also received a small improvement. A previous build introduced the persistent filter–a filter applied automatically, every time the OFIS dialog opened. That filter can now be toggled per dialog–applying and not applying the persistent filter. Use Ctrl+R to toggle the persistent filter.
Finally, build 2291 continues our ongoing commitment to Unreal Engine 4 (UE4) with several game-development tweaks to the code-generation features of Visual Assist.
Build 2291 requires software maintenance through 2018.09.21.