Roughly 15% of all Visual Studio developers have used Dotfuscator Community Edition (CE) to prevent reverse engineering (and I think we can all agree that this is a relatively specialized requirement). If you accept the next uncontroversial assumption that more developers would want to know who is using their software, how and why than would be concerned about reverse engineering – then we can also assume that the new Dotfuscator CE that includes application monitoring capabilities will be adopted by perhaps 2X or even 3X more developers – or between 30% to 45% if the 6 million+ Visual Studio users.
This next series of posts will outline specific opportunities for entrepreneurial developers to build solutions targeting the millions of .NET developers likely be using these new capabilities as VS2010 reaches general availability. For an earlier example of this, see my blog entry how to make $5 from every .NET developer on the planet.
Post 1 – Code coverage!? I got your code coverage right here pal!
If you think development teams would benefit from being able to readily reconcile testing code coverage results with beta usage code coverage to improve quality and reduce development costs – read on…
With VS2010 Dotfuscator CE feature tracking, you can stream back feature usage during a beta release that can provide a complete picture of what methods were called, in what order and on what technology stack. If only there were an easy way to not only visualize this in the context of the application’s code base but also to overlay this information on earlier testing code coverage results to ensure I have tested what is being used and my beta users are using what I think needs to be tested! That might be an opportunity…
We’ve got an “opp” for that! (apologies to the iPhone ad guys). If you have evaluated VS Beta 1, you may have already noticed that VSTS 2010 Architecture is a completely new release which leaves behind the current Distributed System Designer and the underlying System Definition Model (SDM ) and replaces them with the Unified Modeling Language (UML), Domain Specific Languages (DSLs) and other tools that are not related to UML. The specific tool I want to point to here is the Architecture Explorer (AE). AE visualizes relationships inside code using the Directed Graph Markup Language (DGML). By extending the DGML, one can use the Architecture Explorer to create visual models of assemblies – post-build – combining both the relationships inside the code (this comes with AE out of the box) and testing and usage coverage results by extending the styles already included in AE. In short, The Architect Explorer with its DGML support and the ability to extend/modify styles offers an ideal means to quickly reconcile usage data with testing code coverage (and platform and framework coverage as well).
This screen shot shows a generic rendering inside the VSTS Architecture Explorer. The rendering is entirely driven through XML data and, as such, can be easily extended to provide specialized views that are relevant across the entire lifecycle of an application.
In this case, the color schemes (or fonts or sizes) can be driven by:
The level of testing completed as reflected inside a TFS repository to quickly answer the questions
- Testing status – how much testing has been completed?
- Testing the right things – are there components that should be getting more (or less) attention?
The level of usage by beta test users as reported via the instrumentation capabilities included in Visual Studio 2010 Dotfuscator CE to quickly answer the questions
- Beta adoption sufficient – have enough users actually run the software through its paces?
- Critical path coverage – are the new components being exercised as expected?
- Testing coverage map to usage profile – combining both testing data and usage coverage data can identify areas of code that are not being tested sufficiently given the patterns of usage that are being observed? (mash up)
- Platform/framework coverage – are enough users evaluating on Vista SP1 or .NET 1.1 or …?
- What exceptions have been detected that have not been reported through other channels?