There’s a lot of interest in the developer community about the new version of Visual Studio, which is in preview currently. This week we released Visual Assist 2021.3 (build 2420), and Visual Assist includes beta support for the Visual Studio 2022 Previews.
Visual Studio Preview
Visual Studio (VS) 2022’s main change—and it’s a significant one—is that it will become a 64-bit process. Since Visual Assist (VA or VAX) runs as a plugin, in-process, we needed to build a 64-bit version of our plugin DLL. Those who have upgraded 32-bit code to 64-bit code before know that, even in well-architected code, it takes some work even just to review code to ensure it is correct. In addition, the new version adds and modifies a number of APIs we rely on to interact with the IDE. Adapting to those was the most significant change for us.
We’ve tested fully against VS 2022 Preview 2, and in fact the installer says ‘Preview 2’. There are some known regressions:
VA Quick Info not appearing when triggered by keyboard in VS 2022 [case: 146063]
Source Links example plugin does not load in VS 2022 [case: 146012]
Changing from Cascadia to another font for italicized system symbols requires restart in VS 2022 [case: 145979]
plus a few others.
Visual Studio 2022 Preview 3 was released two days ago—overlapping timing with our release—and our regression tests are showing some failures. Currently we believe those are because of changed behaviour in a Visual Studio API which we use when verifying in-IDE behaviour (ie not an issue in VAX itself), but it is always possible that once that is resolved further test failures will need to be resolved. However, we believe the current build is well worth trying out on Preview 3 as well.
Many of our customers strain the Visual Studio IDE, with many plugins and SDKs installed. Both to help them, and because we believe it’s part of being a good member of the Visual Studio ecosystem where our plugin sits alongside others, last November we greatly reduced the in-process memory usage largely through (spoiler: the full blog is worth reading) use of memory-mapped files.
Now that Visual Studio 2022 is a 64-bit process, that work is not necessary for VS2022. For older versions of Visual Studio, those techniques are still used, so if you’re using VS 2019 or even VS 2005 with Visual Assist 2021.3, you’ll still benefit from the lighter memory impact within the IDE.
When we did that work, we also focused on performance to ensure that the changes to memory access had either zero or a positive impact. The blog notes that for heavy usage, we had equal performance; for small projects, VAX actually was a bit faster. Despite no longer needing the memory usage code we added, VS 2022 benefits from that performance work as well, plus some more work we’ve done while adding support. Since it’s a beta build, and Visual Studio itself is in preview, we do not have hard numbers. But a rough guideline is that an operation like Find References that previously may have taken (say) two minutes will now take about one minute twenty seconds, or about two thirds the time.
It’s historically been very important to us to have swift support for new versions of Visual Studio, and this work is our foundation for quickly officially supporting Visual Studio 2022 when it is officially released. While the main focus of this release was VS 2022 support, there are other changes as well in 2021.3, which we’ll document in the What’s New. We know we have many customers using older versions of Visual Studio, and as well as those improvements today you can look forward to further improvements focusing on other, non-VS areas as we switch back to a more normal focus in our next release.
We’re really happy to be able to ship beta support for the Visual Studio 2022 previews, and providing an even faster Visual Assist is a happy bonus. We’ll continue to work and look forward to shipping full support when Visual Studio publishes its final release.
The first two releases of Visual Assist this year contain some great Unreal Engine quality-of-life improvements you may want to take advantage of.
While we’ve always announced features in our changelog and release blogs, we’re starting to blog in greater detail about some of what we change — our December blog about reducing memory usage started this — and this time we’ll dig a bit more into two changes improving using Unreal Engine with Visual Assist.
This applies only to versions 2021.1 and 2021.2, the first two versions this year. If you’re reading from the future, there’s likely much more for UE than is described here!
There are two notable items in these versions:
Improving parse times for Unreal Engine projects
Removing unwanted generated headers and symbols
These mean that your Unreal Engine projects should be fully usable with Visual Assist faster when you open them, and that Visual Assist only shows and uses methods and other symbols that you’re really interested in.
When a solution is opened in Visual Studio, Visual Assist (VAX) parses that solution. This generates the databases of symbols and other data which VAX uses to be able to implement features like GoTo Related, extra syntax highlighting, parameter info, and so forth.
Parsing can take time. Although VAX is not based around a C++ compiler (one of its strengths), parsing is analogous to compiling a project, and while you can use VAX right away, some features require that data before they will work. Unreal Engine solutions can be very large. Therefore, we spend a lot of thought on how to speed up parse time to make the time between opening a solution and having VAX fully functional be as short as possible.
Avoiding Unnecessary Parsing
This following is going to sound ridiculously simple, and it is. What’s the best way to spend less time doing something? Not to do it.
We do focus on optimisations; the parse engine is heavily multi-threaded; the database uses considerably less memory than it used to; and other techniques. But ultimately, the best way to reduce parse time is to do less parsing.
Unreal Engine projects include plugins. These are additional libraries that add features to your game or project (in-editor or at runtime.) The UE editor lets you enable and disable these, so it’s common to have several installed but only use a subset of them. Yet, the presence of plugins is a key item that makes parsing a UE project lengthier. We added an option to turn off parsing them.
In 2021.1 we added an option to disable indexing these plugins. When off, the default, UE plugins were not parsed.
However, we realised this was based on a flawed understanding: that if plugins are third-party (as plugins often are) then you may not need them to be parsed into VAX’s memory: after all, we thought, you’re unlikely to do a ‘find references’ on an internal method of a third-party library. Omitting them from being parsed would not affect day to day use of Visual Assist. But we got feedback that it was more common than we thought for plugins to be first-party: that is, for UE developers to move parts of their game or project’s functionality into a plugin. That means that it was necessary to parse some plugins, and so a simple on/off parse all-or-none toggle was not useful.
In 2021.2 we expanded the setting so that Visual Assist can parse plugins that are genuinely used by your project, only. Today the ‘Index Unreal Engine plugins’ setting has three options for parsing plugins:
None: don’t parse anything in the Plugins folder. This reduces parse time the most
Referenced: parse only plugins references by the project, and referenced by default. Depending on how many plugins you have installed that are not used, this still reduces parse time. It is the recommended setting
All: parse all plugins; there is no reduction in parse time.
Real-World Performance Improvements
The amount of time saved by not parsing unused plugins depends on the complexity of your Unreal Engine solution and the specific machine on which Visual Studio runs, but some real-world measurements are as follows:
The absolute values may vary but we expect the relative percentage to be broadly applicable.
If you open a file from a plugin folder which was not parsed (either not referenced, or the above setting was set to None), then you will see a notification message that the file was not parsed and Visual Assist won’t provide your expected functionality for that file. This is shown only once, and won’t be shown again until Visual Studio restarts.
Avoiding Parsing UE-Generated Files
Saving a very useful change for last — there are many places Visual Assist shows you the symbols and files it’s aware of. The two main windows are Open File In Solution which lists all headers (and other files), and Find Symbol will list every symbol in the database. Unreal Engine, however, generates header files, and these include generated symbols, neither of which are useful in practice when coding on your UE project in Visual Studio.
Voila, a new setting, which means Visual Assist won’t show *.generated.h files, and the Find Symbol dialog is not polluted with generated symbols either. The setting is called ‘Index generated code’ and is off by default. That is, the default is aimed at clean results within Visual Assist, to not index these generated files and store those generated symbols. You can always turn it back on if you want the old behaviour.
Unreal Engine with Visual Assist 2021.1 and 2021.2
The above covers only the first two releases this year, and we have more planned. However, the parsing speed improvements (including our followup for more granular parsing of plugins) and removing generated files and symbols by default should the general ‘quality of life’ using Visual Assist with Unreal Engine. As always, feedback is welcome!
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
Whole Tomato prides ourselves on our ability to support continued development of our product. To that end, we revised our renewal policy for Standard licenses to ensure that customers are able to benefit from ongoing development of Visual Assist. Encouraging customers to leverage maintenance increases the productivity of developers by making new features at their disposal and increases resources that allow us to keep up with releases of Microsoft Visual Studio. This change in policy does not impact Academic or Personal licenses.
Customers who have been off maintenance less than a year can request a quote to restart maintenance the date of purchase. Term will be for a full year. Cost to renew is $119 per user. This offer expires March 12th, 2019.
After March 12, 2019, customers who have been off maintenance less than a year can request a quote for maintenance. Term will be for a year beginning the date their prior maintenance expired.
Customers who have been off maintenance for more than one year should contact us for a customized quote.
Visual Assist evolves frequently and significantly. If you’re after new features, ever-improving usability, increased performance and the latest innovations, staying current on maintenance allows you to get access to all updates to Visual Assist.
World Class Support
You’ll receive our world class support for the term of your maintenance period. Our support team consists of experts at troubleshooting, problem diagnosis, and problem resolution. A maintenance and support contract includes front-of-the-line technical assistance via email, website and discussion forums.
Peace of mind
Your team depends on Visual Assist for day-to-day activities and having a guaranteed direct line of contact to a committed support team offers that peace of mind. Renewing ensures that the privileges of software maintenance and your day is uninterrupted.
Whole Tomato Software will exhibit at the Game Developer Conference this week, March 21-23, in San Francisco. If you attend the expo, stop by booth 123 to see the latest features in Visual Assist, share your wishes for the product, and pick up some nifty swag.
If you follow news from Whole Tomato, you know that Microsoft released several builds of Windows 10 with bugs that caused Visual Studio to crash when Visual Assist was installed. More recently, Microsoft introduced a change in Visual Studio 2017 15.5 that causes the Code Inspection feature of Visual Assist to crash.
If you use Visual Studio 2017 and updated to 15.5, disable Code Inspection in the options dialog of Visual Assist. The next build of Visual Assist will include a fix that will let you re-enable the feature.
If you run Windows 10 Version 1709 (Fall Creators Update), your installation of Windows 10 must be up to date in order to use Visual Assist. Microsoft’s December 12th update to OS Build 16299.125 includes a required fix for a CreateWindowEx() failure.
If you run Windows 10 Version 1703 and deferred installation of the Fall Creators Update, you are free to un-pause Windows Update and upgrade to 1709.
If you prefer to remain with Windows 10 Version 1703, you must run at least OS Build 15063.729, released November 22nd, in order to have a required fix for a broken hook mechanism.
Thank you for your patience as we grapple with the bugs and crashes.
If all goes well, the next post in this blog will simply announce a new build of Visual Assist.
Two bugs in recent updates to Microsoft Windows 10 cause Visual Studio to crash when certain extensions, including Visual Assist, are installed. Microsoft fixed one of the bugs, a broken hook mechanism, in its November 14, 2017, update.
If you run Windows 10 (64-bit) Fall Creators Update (Version 1709) and you cannot rollback, install Visual Assist build 2238 to mitigate the CreateWindowEx() failures. If Visual Studio continues to crash, disable Visual Assist and wait for another update from Microsoft, mid-December at earliest, before resuming normal use of Visual Assist.
The Windows 10 Fall Creators Update (FCU) 1709 contains a bug that causes CreateWindow() and CreateWindowEx() to fail unpredictably. The bug prevents Visual Assist from rendering all components of its UI, and eventually causes Visual Studio to crash.
Microsoft has acknowledged the CreateWindow() bug and is investigating its cause, but the bug will not be fixed—at the earliest—until the December Patch Tuesday. If you want to use Visual Assist until Microsoft releases a fix, defer installation of the Windows 10 Fall Creators Update.
Separately, Microsoft broke Windows hook procedures in Windows 10 Build 15063.608, issued Sept 12th. The hook bug causes Visual Studio to crash intermittently, e.g. when opening certain dialogs of Visual Assist. Microsoft has acknowledged the bug and is scheduled to release a fix on November Patch Tuesday.
Several bugs in recent updates to Microsoft Windows 10 cause Visual Studio to crash when certain extensions, including Visual Assist, are installed:
Windows 10 Build 15063.608, issued Sept 12th, broke Windows hook procedures located in high memory.
Windows Version 1709 (Fall Creators Update), released Oct 17th, broke also CreateWindow() and CreateWindowEx().
Microsoft is actively seeking resolutions. Fixes should be released on a Patch Tuesday.
If you run Windows 10, and:
You want to try Visual Assist, wait for the problems to be resolved before starting your trial.
You use Visual Assist, you have not yet installed the Fall Creators Update, and:
Visual Studio crashes when you open dialogs of Visual Assist, disable Visual Assist. You are likely suffering from the broken hook mechanism.
Visual Studio does not crash, keep your version of Windows, i.e. delay installation of the Fall Creators Update.
You use Visual Assist, you installed the Fall Creators Update, and components of the Visual Assist UI fail or Visual Studio crashes, disable Visual Assist or try rolling back to the previous version of Windows. You are likely suffering from CreateWindow() failures.