Overview of Visual Studio Team System 2010 for Developers (Part 1)
In this two part article we will take an overview of various features and tools of Team System 2010 for Developers. In the first part we will check the features which were existing in VSTS 2008 and any changes in those. In the second part (next article) we will go in the details of new features added in the Team System 2010 for Developers. To get an overview of Visual Studio Team System 2010 for Architects, check my article over here VSTS 2010: Overview of Team System 2010 for Architects
Ultimate aim of any organization is to improve profitability while doing business. Software development tools and IDE allows organizations which develop software to improve profitability by providing higher productivity of the involved people and better quality of the developed product. Visual Studio provides built in tools for high productivity and any addition of tools for that reason will only have incremental benefit. In early versions of Team System, Microsoft provided many tools to improve quality of the product which is being created. Those tools are:
· Static Code Analysis
· Code Profiling
· Unit Testing with Code Coverage
· Code Metrics
Let us find out if there are any enhancements in each of these tools and features.
Static Code Analysis: Principal of this feature is to analyze code when it is being compiled and ensure that it follows the coding guidelines and best practices. These coding guidelines and best practices are configured through the rules that are embedded in the policies which can be toggled on or off. If code does not adhere to those standards then a warning is shown. Showing warning is a default behaviour which can be overridden for certain rules so that if those are not being followed then an error will be shown instead of a warning. Static code analysis trigger can be set to either at compilation time or at check-in time (by enabling a standard check-in policy). It can be also executed on demand by selecting the option of “Run Code Analysis” from the context menu of the project in the solution explorer. Settings of Static Code Analysis are done from the “Code Analysis” tab of the properties of the project. Let us now see changes that have been incorporated in the Beta 1 of Team System 2010 - Developers.
1. Rule Sets: Team System 2010 – Developers offers ‘Rule Sets’ which are, the sets of rules that are preselected for some specific conditions. Those rule sets are:
i. Microsoft Minimum Recommended Rules – Focus on most critical problems in the code. Rules under this set are for Design, Globalization, Interoperability, Portability, Reliability, Security and Usage.
ii. Basic Design Guidelines Rules – This set ensures that best practices for distributed applications which can be maintained easily are being followed. It includes rules for Maintainability, Naming and Performance in addition to the rules defined in Minimum Recommended Rules.
iii. Microsoft Extended Design Guidelines Rules – These rules expand on the set of rules provided in Basic Design Guidelines Rules.
iv. Basic Correctness Rules – These rules focus on logic errors and common mistakes done during the use of .NET framework APIs.
v. Microsoft Extended Correctness Rules – These rules expand on the Basic Correctness Rules with extra emphasis on COM Interoperability and Mobile Computing.
vi. Microsoft Globalization Rules – As the name suggests this set of rules focus on globalization (multilingual software development) only.
vii. Microsoft Security Rules – To catch maximum number of security issues, this rule set can be used.
viii. Microsoft All Rules – This rule set can be used initially to determine where the focus should be and then use the specific rule set.
2. There are two variations of customization that are possible. First one is to select multiple rule sets which are appropriate. The second variation is to create our own rule set from basic rules. Process for creating our own rule set from existing rules is as follows:
a. On the code analysis tab of the project properties, select Microsoft All Rules rule set.
b. Deselect either the entire groups of rules or some of the rules by un-checking them.
c. Click on the save button. Give an appropriate name to the file and save it under “\Program Files\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\Rule Sets”. The file will have an extension “.ruleset”.
d. Open the file in the editor like notepad and change the name and description suitably. Save the file back.
e. First time you may have to browse and select the .ruleset file that you have created but then onwards this ruleset will be available in the drop down.
Extension to rules to add new rules can be undertaken if necessary. It requires use of FxCop SDK in the .NET class library project.
Code Profiling: It is a tool using which we can find out the bottlenecks and other performance issues in the created code. In VSTS 2008 we could do it in two ways, either by sampling or by instrumenting the code. In the Team System 2010 – Developers there are more options available to us.
1. CPU Sampling – Measures CPU-bound applications with low overhead. This can be used in general applications as starting point and if necessary we can profile the same application with other options.Profiling by sampling can be done either on the projects which can output executable or launchable web applications or on already compiled executable or on ASP.NET application.
While profiling is being done, it starts the application, after compiling if necessary and then collects data while execution is going on. We may change the default value of interval for sampling by going to the properties of the performance session. We can set markers to know exactly when a certain data item was collected. After application execution is over, it shows the summary report.
Profiling report has been enhanced in Team System 2010 – Developers, to show graph of CPU usage by default. We can select some part of the graph which probably has gone beyond some threshold limit and view details like warnings for that part only. This is called filtering the samples. This report also shows the Hot Path which is the most expensive call path based upon the sample counts. There are multiple views to the report which can show Call Tree, Modules, Caller / Callee stack, Functions being called, Function Details, Marks which are embedded to identify points in execution, Processes, Lines and IPs. We can do comparison of reports of two executions of the sessions so that we can view of any improvement in the performance is achieved by refactoring the code.
2. Instrumentation – Measures function call counts and timings. Although this is more accurate compared to sampling, it is invasive and so it puts more load on the application server. Instrumentation is addition of lines in each method at the run time to count the number of calls to that method and to keep track of how many times that method was called. Any method which gets high number of calls as well as takes high amount of time to execute is a bottleneck operation and should be focused for improvement of performance.
Profiling the code using instrumentation through Visual Studio Wizard does instrument all the methods in the selected assembly for adding the instrument code and it may be unnecessary to instrument all methods. We can do selective instrumentation and then profile the assembly using some command line tools. This is more efficient and flexible compared to using Performance Wizard from Team System 2010 for Developers. The order in which these tools should be used are:
i. VsInstr.exe with /exclude or /include options to do selective instrumentation.
ii. VsPerClrEnv.exe to set the environment variables for managed code profiling
iii. VsPerfCmd.exe to collect the performance data during profiling session
iv. VsPerfReport.exe to generate report from collected data.
3. .NET Memory Allocation (Sampling) – Tracks managed memory allocation so that we can find memory leaks if any. This option interrupts the processes to collect data on every event of memory allocation for a new object on CLR and for every event of garbage collection. Upon memory allocation, it collects the increments the exclusive sample count of the function which is executing and also increments the inclusive sample count of all the functions in the caller stack including the function which is executing. When the garbage collection happens it collects the data of number and size of the objects and the generation in which they were collected.
4. Concurrency – Detects threads waiting for other threads. This profiling method enables you to collect two types of concurrency data:
i. Resource contention data includes information about every synchronization event that causes a function in the profiled application to wait for access to a resource.
ii. Thread execution data includes information about processor utilization, thread contention, thread migration, synchronization delays, areas of overlapped I/O, and other system events.
Unit Testing with Code coverage: Unit Testing framework provided in Team System 2010 – Developer, allows us to create unit tests for any number of methods in a class library or a webservice. Simple method to create unit test is to right click on the method to be tested and from the context sensitive menu, select ‘Create Unit Test’. Wizard creates a Test Project if it does not exist or utilizes an existing test project, creates a .cs or .vb file as per our language selection, gives reference to the class library to be tested and writes the code for test. Generated code consists of a class with TestClass attribute, a property for storing TestContext object which can be used to store the data from databinding, a method with TestMethod attribute and a set of optional methods for housekeeping. In the test method, it generates the code for the instantiation of class which contains the method to be tested, sets the values to parameters to be passed and sets value to the expected return. Then it executes the method to be tested and compares the obtained return value with the expected return value. If they are same then test passes and if they are different then the test fails. It is possible to do the databinding to the parameters and expected return so that we can execute the same test multiple times in one shot for different conditions. All these features are as were present in VSTS 2008. Details of those are provided in another article http://www.dotnetcurry.com/ShowArticle.aspx?ID=127. An interesting feature is to either create a new workitem andattach test results to that or to use an existing workitem and attach those test results to that workitem.
Code coverage is to check how many lines of code in the method being tested are covered (tested) by the test that we have written. To enable code coverage, we can open the file Local.testsettings and open the tab Execution Criteria. In the collectors section we will select the code coverage and check the checkbox for that row. Click the advance button and select the assemblies that need to be instrumented for code coverage.
Now if we run the tests then code coverage is calculated and is shown as statistics. If we want to view the code which is covered and not covered then we can view those by clicking on the button for ‘Show Code Coverage Coloring’.
A feature related to unit testing called Test Impact Analysis has been added in Team System 2010 – Developer. We will go in the details of that in my next article.
Code Metrics: This is again a feature which was added in VSTS 2008. It measures the maintainability of the code and provides the index of it on the scale of 0 to 100. Higher the index better is the maintainability of code. Details of this feature, which have remained unchanged since VSTS 2008 are provided in my article Using Code Metrics in Visual Studio Team System 2008.
Summary: In this article we have taken an overview of some of the features of Team System 2010 – Developers. Features that we have seen were either available as they are in VSTS 2008 or were available in VSTS 2008 but enhanced in Team System 2010 – Developers. In the next article we will see the details of features which are added in Team System 2010 – Developer. Some of them are Historical Debugger and Test Impact Analysis.
If you liked the article, Subscribe to the RSS Feed or Subscribe Via Email
Subodh Sohoni is a VSTS MVP, MCTS - Microsoft Team Foundation Server - Configuration and Development and also is a Microsoft Certified Trainer(MCT) since 2004.