VisualBug Alpha soon to be released

Development is about to continue
January 14, 2016
Repositories finally working
March 20, 2016

VisualBug Alpha soon to be released

VisualBug Alpha Logo VisualBug Alpha soon to be released | VisualBug

It’s been close to a year when the last version of VisualBug was released. Now I can happily announce that the next version is soon ready for publishing. I’ve thought a while about the development of VisualBug and I eventually decided to restart the Beta. The first two versions weren’t much of a help, barely able to be used in productional environment. Though the next version won’t be ready for that either, it’s a whole lot different than the others. Just the injection alone is worth it. The whole user experience was redesigned. In this post I’ll show off some of it as it’s pretty much in that rock-solid state it should be for this version. After all I’ll restart it as Alpha – as it does not really meet the definition of Beta.

I will announce and promote the first real version in some developer forums and would appreciate anyone who’s using and testing it. Work will continue instantly after the release as I want to see it in it’s full shape as soon as possible. Once the most needed features are implemented, it’ll leave Alpha and go into Beta until it’s fully tested and equipped with all features for it’s first full release.

What happened throughout the year

The first version was equipped with a simple injector. It was working, but only with very few applications. WinForm applications excluded. Async-support excluded as well. This restricts appliances to a minimum. The injector was disabled in the second version as it was buggy and not really working that well. Throughout the year since the last release the injector matured into a very well working system. Combined with an analyzer it recognizes most cases and injects code appropriately. The BugSpy tracking engine was abstracted so that you can use it with both WinForm as well as WPF applications.

Performance was drastically improved. The current tracking engine runs asynchronously in another thread on low priority so that the actual application isn’t blocked. WPFs DependencyProperties now are fully supported thus making the BugSpy tracking engine using it’s changed events for notification. This reduces the amount of pulls and thus increases performance about quite a bit. But actually pulling was removed completely. Even native .Net properties and fields can be tracked without requiring BugSpy to pull the values all the time. Since most people use native members in their applications (and DependencyProperties aren’t even natively supported in WinForms) this will boost performance a lot. Instead of pulling VisualBug uses it’s injection process to inject invalidation-calls which notify the tracking engine about changes to properties and/or fields. Therefore invalidation gets only called once values are really changed. Values aren’t pulled instantly, though. The tracking engine keeps a stack of invalidation targets and pulls them over time. Thus the whole process doesn’t block the application in any way.

Analysis was introduced bundled together with the newly introduced IntelliSolve. The analysis comes in handy especially with custom monitoring. If you refrain from using injection, VisualBug will analyze your custom tracking implementation and notify you about any issues or errors you may have done. And that in detail – it will even suggest you the right code and explains to you easily what the problem is and gives you a simple and easy-to-understand solution with code samples fitted for your code (as you can see in the screenshot).

VisualBug Analyzer IntelliSolve Preview VisualBug Alpha soon to be released | VisualBug

Projects were also introduced in the new version. These allow you to store your settings in the future and will provide us with room for a lot of improvements for VisualBug’s workflow. For now there are only few options. The first thing is to add some assemblies to the build process. One is chosen as entry point. If none is chosen or all assemblies are libraries, VisualBug will only inject monitoring features but not the engine bootstrap. Furthermore you can now set some injection options. This includes debugging like showing a console at startup of your application, setting the log levels that are output, attatching a debugger at startup, enable tracing and writing PDB-symbols. Last but not least you can set some output options like overwriting the target assemblies or a specific output directory. These settings will be used later once the commandline-support is fully implemented to specify settings more easily without having a huge list of commandline arguments.

The User Interface was completely revamped. Except for the color scheme there’s nearly nothing left from the last VisualBug version. We added a menu bar which provides you with the most important features, all available via keyboard shortcuts, application settings which allow you to tune VisualBug the way you want it to be, a whole docking interface which allows you to arrange your workspace the way you can work best with, an errors and warnings panel which shows you any issues and errors which show up with extremely detailed information thanks to IntelliSolve, an output panel for more detailed information (if you require so) as well as the new LiftMenu which gives you access to the utmost important features for super fast injection. More about IntelliSolve will be revealed in another post soon.

TCP/IP connections are another huge feature. The old named pipes based system was cut out and a more performant and smoother working TCP/IP communication system was introduced. This allows you to also monitor via the Internet which will be a huge feature coming in a future version. It is not yet ready for that purpose as it’s missing necessary security functionality but this will surely be to come sooner than you think. Another improvement is multi-monitoring. Not yet introduced but will be in the final version. From then on you can monitor more than once instance of your application or multiple applications (or application-parts) at the same time without interferences. Each monitored process will have it’s own monitoring environment.


And that’s not even half of what has changed but the most important and noteworthy changes.

Will Alpha be closed or open?

The Alpha phase will be closed. Everyone can apply for testing and will get access to it as soon as possible. But in order to ensure quality I’ll equip every tester with the necessary information and access to the bugtracker. If people don’t want to thoroughly test VisualBug but just test it out once for evaluation, then I’ll allow that as well. But I’d be glad about everyone who is willing to test VisualBug thoroughly troughout the pre-release phase.

What is to come?

The foundation has been laid. Now it’s time to implement the important features. Once VisualBug is polished and streamlined for the first Alpha version we’ll focus on those important features that are still missing: Array data types, nullable types, graphs, trend indicators, logging support, command and event invocation, network monitoring, …

Moreover the first Alpha will get an streamlined update service. From then on updates will be delivered smoothly to yours once they’re ready for testing. In case you want to leave any suggestions or have something to ask, you’ll be able to send us a mail directly via the feedback form. If you encounter any errors in VisualBug (that can be prevented), you’ll be able to send us a detailed report per mail once you open the IntelliSolve overview of that error (that report is pre-generated then, so you just have to click on send).

HTML Snippets Powered By :