The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Visual Studio Team Edition for Software Developers
Targeted at software developers, this edition of the Visual Studio Team Suite adds a range of code analysis and profiling tools that encourage code testing to be brought forward in the development lifecycle. Ian Murphy tests them out. (Copy now revised for Beta 2!)
Author: Ian Murphy
Last updated: May 2005
NOTE: This article is based on Beta 2 of the software, so the features described may differ from those of the final release. There is a common belief that developers don't worry about quality assurance (QA), but for the vast majority this is not true. As they go through their development cycle they spend considerable time testing their code to ensure that it does what they expect. With Visual Studio Team Edition for Software Developers, Microsoft is hoping to promote more effective testing earlier in the development lifecycle by providing developers with the tools they need to do it properly. The code analysis tools This is where you can set the rules that are used by Code Analysis, and whether they should generate a Warning or an Error. Once you have enabled and configured PREfast, you should rebuild your project. If there are problems then these will be shown in the Error List. Double-click an error and you are taken to the offending code. This is a nice feature and will help you quickly solve a lot of problems, particularly as it is not only simple problems that can be identified. More serious problems such as leaking or uninitialised memory can also be detected. When a problem spans a large section of code, the IDE highlights everything that is affected through a yellow line down the side, a useful feature that can make problem solving much easier. Click on any error and it will take you to the offending line of code so that you can fix it. Using FxCop The code profiling tools Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the
prior consent of the copyright holder.
The Developers edition is not a replacement for the existing Integrated Development Environment (IDE). Visual Studio 2005 Professional Edition remains the replacement for Visual Studio 2003 Professional Edition, and indeed forms the basis of all three of the Team Editions. What the Developers edition adds is a client to Team Foundation Server, a set of tools for detecting common errors in code, and ‘best practice’ guidelines.
The guidelines cover everything from how to conduct design and code reviews through to the use of the various debugging and code analysis tools that come with Visual Studio Team System (VSTS). In between there are some important guidelines dealing with writing secure code, and the use of check-in to manage quality code. Particularly significant here is the ability for project managers to set policies that prevent code from being checked in until it’s passed specified tests.
The secure code guidelines should be part of any developer approach today, and the guidelines provided do set out a solid and workable methodology. However the use of the check-in process is even more important. There are several vendors today who offer similar tools. Enerjy, for example, already use the check-in process to prevent the developer from checking in code that doesn't meet specified programming standards. This is a good first step as it controls the quality of code from the moment it is written. Over the last few years we have become lazy as our IDE checks our syntax as we type. However, there is a big difference to having the right syntax and having code that meets programming standards.
The tools provided with the Developers edition cover two areas, namely code analysis and performance analysis (or code profiling). There is also overlap with the Testers Edition in the provision of unit testing and code coverage, but we will cover these in our article on the Testers edition.
The Developers edition comes with two tools supporting code analysis; one for managed and the other for native code applications. The first is based on PREfast which Microsoft uses in its own Trustworthy Computing code reviews, and which is targeted at native code such as C/C++. The second is based on FxCop which was used by Microsoft to test managed code during the .NET Framework development cycle.
PREfast is a tool that Microsoft developed in-house and then released a while ago as part of Windows CE 5.0. It is also available in the Windows Driver Development Kit. PREfast is designed to work with C/C++ native code, and requires careful attention to detail. FxCop can currently be downloaded from Microsoft’s GotDotNet Web site.
PREfast is driven by rules that specify coding policies that cover naming, globalisation, design, security, reliability and so forth. The rules provided are not exhaustive and we understand that you will be able to add new rules.
By default, every rule is enabled and generates a warning once compilation is completed. However, you can change their setting so that any breach results in an error and a failed compile. You can also manage this from your code by including a header file listing all the rules and their default state. You can then upgrade warnings to errors or disable warnings using the #pragma directive.
If the project is registered with Team Foundation Server then you can turn any item from the Error List into a Work Item, simply by right clicking the error and selecting Work Item.
FxCop is designed to do for managed code what PREfast does for C/C++. It is enabled in a similar way to PREfast. To turn it on you need to go to the Project menu and open the properties for the project. If you want to disable any of the rules then you simply open up the appropriate section and removing the tick. This works the same as in PREfast except you can't change warnings into errors, only enable or disable the rules.
The output from FxCop is very similar to that from PREfast too. Double-click on a warning and it usually take you to the problem, although not always. For example, if code is not broken but just missing, it doesn’t stop the code from compiling or being deployed, and you are not taken to the relevant location to add the new code. Instead you must resolve the problem yourself.
There is a clear warning here about over-reliance on tools. Inexperienced developers will still have problems, even with tools like PREfast and FxCop at their disposal. This is where linking the check-in process to the passing of various tests is important, as it will prevent problems like this from getting into the core code base.
To suppress a message, you right click and select Suppress Message. A suppressed message will be shown with a set of lines running through it. Once suppressed, however, there appears to be no way to reverse your decision and include it.
It is also possible to add rules to FxCop, although this is poorly documented in Beta 2, and requires you to write quite a bit of code. However, with its inclusion in the Developers edition, and with the underlying SQL Server repository, it may just be that Microsoft will build a rule engine into the database that can be exposed by FxCop and even by PREfast.
One unknown here is how long both PREfast and FxCop will be supported as standalone products. As they are an integral part of the VSTS it would not be surprising if Microsoft stopped supplying the current versions, particularly as this would stop Visual Studio 2005 Professional users getting hold of these tools and gaining a significant part of the functionality available in the Developers edition.
Application performance has become a major issue today. To help developers get an understanding of how their code is performing, the Developers edition includes some tools that allow you to profile your application. There are two distinct approaches: sampling, which reports on what is happening at the time the sample is taken, such as what is running and the state of the stack; and instrumentation, which uses probes to monitor such things as memory and processor activity, and the behaviour of functions.
To profile your application you start with the Performance Wizard. There are just three simple steps: Select the application, choose Sampling or Instrumentation, and Finish. When you are ready to gather the sampled information you go to the Performance Explorer, right click on the application and select Launch.
The next step is to work through some test operations so that the profiler can capture information. Once you have finished you close the application and the wizard generates a report.
There are several things that you can investigate from the report but of common interest is likely to be the frequency that a particular function is called. If you have a function that appears to be called more than you would expect, you can right-click on the report to have the source code opened.
If you want to look more closely at a particular module you should consider using the Instrumentation rather than the Sampling approach. As before, once the wizard is running, you work with the application to allow the wizard to gather enough information. In this case what you are looking for is signs of excessive time or resources being consumed by a particular function. From here you can drill down more deeply into the code and look for variables that appear to be wrong or code that appears to be constantly looping.
Perhaps one of the most important things that you can get from an Instrumentation report is a view of how memory is being managed. You might find that a particular function uses more memory than expected, or that during execution the memory consumption continues to rise. This is almost certainly caused by memory not being returned to the pool, or by a memory leak. Either way, you can now locate and deal with the problem long before the application is sent to the QA team for more detailed testing.
That said, these profiling tools should not be considered as just a pre-QA set. If code is returned or an error report is raised, you can use these tools to get more detailed information than the report may contain.
Before you can use any of these tools you need to have a good working knowledge of your environment. These are not tools to be given to junior members of the team. They require training and experience in order to get the best out of them. Nevertheless, such an approach to code testing is long overdue.
Introducing the Visual Studio Team System Visual Studio Team Foundation Server Visual Studio Team Edition for Software Architects
