Visual Studio Sensor Code Review

Documentation/Guides:

In general people seemed to like the documentation and guides (user and developer) that came with the sensor. There were three areas that needed further clarification or modification.

The first area was that NUnit and two NUnit tests were included with the original distribution, but documentation for its installation and how to run the tests was not created. In actuality, NUnit should have been removed from the distribution before it was released as the tests serve no real purpose and it would simplify working with the source code. A later distribution, released last night, corrected this issue.

The second area that needed clarification was "VisualStudioSensor - For Testing.AddIn" Some of the people working with the source code had errors saying that their project could not find "VisualStudioSensor - For Testing.AddIn" file. Further clarification of this must be included in the Developers Guide to help those working with the source code.

Lastly, it is apparent now that the sensor is only compatible with Visual Studio 2008 that includes the latest .NET Framework 3.5. The handlers and everything else we were using really hadn't changed much from Visual Studio 2005, so I had assumed (which is always dangerous) that the sensor would be compatible as long as the user had the .NET Framework 3.5. Also, apparently not all versions of Visual Studio 2008 come with .NET Framework 3.5 so I modified the guides to indicate that users and developers may have to install this as well.

Bugs/Limitations

Other than the NUnit reference error, the biggest limitation of the system is that only one instance of Visual Studio can use the sensor at a time. Because Visual Studio does not allow more than 1 solution to be opened in an instance at a time, this could present a real problem for developers who want to work with more than 1 solution at a time. At this point in time, I am not sure how to fix this problem but I will definitely look into possible solutions for this as it is a major system limitation.

Also, several people thought the data collected by the sensor was not very useful and was somewhat limited. I am not sure if this is really a Visual Studio sensor issue or an issue with the Hackystat sensor data type conventions. When developing the sensor we tried to follow the Eclipse sensor quite closely so that we could adhere to the sensor data type conventions. All I can say on this at the moment is it is my opinion that the user shouldn't be so interested in the data that is collected by the sensor, but rather in the ways that the data can be used, measured, and displayed. But having said that, this is something we will definitely look into further.

The sensor does not show it is running when a new solution is opened (and the other solution is closed). This type of feedback would be useful to a user who is working with multiple solutions in Visual Studio and will definitely be added to the next release (if possible).

Suggestions:

• Increased feedback on the status bar (perhaps a verbose mode) to give the user a better sense of what is going on.
• Limit the number of characters per line.
• Add DevEvents when the user accesses help.
• Add DevEvents for debug and release.
• Improve user/developer documentation.