February 2008 - Posts

• Microsoft Suggestions

  I was asked recently what I thought Microsoft could do to improve the developer experience. I had to think about this one, but not for long. First, I have always said that having the source code to the .NET framework would make things much easier – hence why Reflector is so popular. But I can't very well make this suggestion because it has already been done. I would however love to see the SharePoint assemblies added to Microsoft's source server. My next suggestion has been that Microsoft should release a developer version of their server operating systems like they do for SQL Server: fully featured, but not licensed for production. For years I ran Windows 2003 Server on my laptop. And I used it too – multiple websites in IIS, DNS so I didn't have to remember crazy ports, etc. While this afforded me the luxury of developing software in the same environment that it would be deployed to, it wasn't without its pitfalls. For starters, in order to run antivirus, I had to buy the corporate version. I couldn't just install a home edition of Norton for $40, I had to buy the corporate edition for much more. It was also tougher to set up and use as a day to day development platform. My last suggestion? More on the humorous side, can someone please tell the Certification team that Visual Studio now has IntelliSense and design-time syntax checking? You know, since at least version 6? Some of these questions, and I can't actually give you a real one, are very annoying: John works for Acme Widgets, and has to build a utility to read XML files into a set of existing classes. Which code method should he use? XmlSerializer.Deserialize XmlDeserializer.Deserialize XmlSerializer.FromXML XmlDeserializer.FromXml Who cares!? Let's focus on real, project changing stuff, like when to actually use xml serialization versus binary serialization, etc. Posted Feb 29 2008, 11:37 PM by Steve with no comments Filed under: Microsoft

• From the Forums: Add Reference and the GAC

  It is a very popular misconception that adding an assembly to the GAC will enable it to show up in a project's Add Reference dialog in Visual Studio. Unfortunately, and to the chagrin of many, this is not true. This myth is perpetuated every time we install a third party component or library, it shows up in the GAC, and we can then add it from the Add Reference dialog. But there is something else going on under the covers. The Add Reference dialog is path-based, meaning it uses physical paths on the file system, retrieved from the registry. The root key is: HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\   Posted Feb 29 2008, 11:13 PM by Steve with 2 comment(s) Filed under: Visual Studio

• From the Forums: FXCop 1.35

  There have been a number of questions on the MSDN forums about where one might download FXCop version 1.35. It seems that GotDotNet has got up and gone, and that's where FXCop used to live. I found that you can download the FXCop 1.36 BETA from the Microsoft Web site, but 1.35 was nowhere to be found. One option to get FXCop 1.35 was to install the Windows SDK for Windows Server 2008 and the .NET Framework 3.5. This is an awfully big package just to get FXCop though. Fortunately, David Kean was kind enough to upload the 1.35 version for folks to download on the new MSDN Code site, and blog about it. You can grab it here: http://code.msdn.microsoft.com/codeanalysis/Release/ProjectReleases.aspx?ReleaseId=553 Posted Feb 29 2008, 11:08 PM by Steve with 2 comment(s) Filed under: TFS, Tips

• Team System Link Love: 1

  I'll try to publish a links with some - [daily|weekly|monthly|infrequent] - frequency. So we'll kick this off with issue #1, and while some of these aren't exactly new links, they are ones I refer to a bit, so I guess it's as much for my benefit as yours. Administration and Setup: Backing Up and Restoring Team Foundation Server Data on the VSTS UE blog Team System Licensing White Paper download from Microsoft Visual Studio Team System Guidance on CodePlex Team Build: Setting up Source Server for TFS Builds on the Jelle Druyts blog TFSBuild.com Build Recipes Launched on Grant Holliday's blog API: Definitive List of Events Supported by TFS from Charles Sterling's blog Visual Studio Products and Extensions for Visual Studio on MSDN Posted Feb 27 2008, 11:48 PM by Steve with 2 comment(s) Filed under: Team System

• SOX 404: Part 2 - Separation of Duties

  NOTE: This series of articles are written as introduction to complex subjects. They are general in nature and highly condensed. They are not intended to be legal advice or counseling in individual cases and cannot substitute for consultation with a knowledgeable attorney or other competent adviser.   Part 1: Introduction Part 2: Separation of Duties   Part 3: Documentation   Part 4: Approvals   Part 5: Testing   Part 6: Auditing   Part 7: Summary and Review In part 1 of this series, we looked at Section 404 of the Sarbanes-Oxley Act of 1999 and how it impacts IT departments. In this section, we'll look at the security requirements of SOX and how to configure user and role security and permissions for the TFS server, individual team projects, Windows SharePoint Services, SQL Server Reporting Services, and Windows. We'll also take a look at the Team Foundation Server Administration Tool and the TFS Permission Manager, both of which can help centralize and manage security administration. Separation of Duties is a cornerstone of SOX, requiring that no one individual have control of every aspect of a business process. Responsibilities should be assigned to individuals in such a way as to encourage checks and balances within the system and minimize the opportunity for unauthorized access and fraud. Team Foundation Server is well grounded on the principles of security: Identification, Authentication and Authorization through the use of Users, Groups and Permissions. By default, Team Foundation uses NTFS authentication, and can also use basic or digest authentication as well as SSL and ISAPI filters. Permission delegation in team Foundation Server is multifaceted and complex because Team Foundation Server is not an application, it is a platform. In this installment of our series on SOX 404 compliance, we'll take a look at security, permissions, and recommended settings at the server and project levels, as well as source control, areas and iterations, work items, Team Build, and finally SharePoint Project Portals and SQL Server Reporting Services. In closing, we will take a look at the tools available to manage security both within Team Foundation and across the platform. Server Security The first step is to properly secure Team Foundation at the server level. Out-of-the-box, Team Foundation Server provides a good baseline for defining separation of duties at the server level with global groups and permissions. Default Groups Team Foundation Server is installed with three default security groups: Team Foundation Valid Users Team Foundation Administrators Service Accounts The Group Membership dialog allows for the creation and deletion of the server-level groups, as well as the ability to define groups and users within the global groups. It is important to remember that groups can be defined in a hierarchical manner. The hierarchy for the first two levels is: Team Foundation Valid Users Service Accounts Team Foundation Administrators (setup account) Team Foundation Administrators Service Accounts BUILTIN\Administrators (setup account) Service Accounts (setup account) These default groups largely suffice in creating a high-level separation of responsibility: administrators are allowed to administer the server; and users are allowed to use the server. For a full list of the default groups and assigned permissions within Team Foundation Server, visit the Team Foundation Server Default Groups, Permissions, and Roles article on the Microsoft Web site. Permissions Team Foundation facilitates setting permissions assigned to global users and groups. The permissions include the ability to create new projects, edit server-level information, and administer the data warehouse. These permissions along with the default settings are: Valid Users Administrators Service Accounts Administer shelved changes Administer warehouse Administer workspaces Alter trace settings Create a workspace Create new projects Edit server-level information Manage process template View server-level information You may wish to evaluate your organizational process, and create additional global groups to further segregate the administrative duties assigned by these permissions. For example, you may want to limit Alter Trace Settings rights to systems administrators, and Create New Projects rights to Project Managers. To do this, since the Administrators rights cannot be modified, you would create new groups to assign users and roles to. How to Define Permissions Server level permissions can be defined in Team Explorer by right-clicking on the server node and choosing Settings | Security, or by using the TFSSecurity command line tool which is discussed in Utilities section later in this chapter. For more information, visit the Team Foundation Server Permissions on the Microsoft Web site. Suggested Permissions The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization. Project Security The second and more granular level of security is the team project level. The project-level groups are implemented in the process template, and users and permissions can be set on a per-project basis. One exception is any user who is a member of a global server group will automatically become a member of all team projects. Default Groups Team projects are created with four default groups which are members of the Valid Users group: Readers Project Administrators (setup account) Contributors Build Services For true separation, and because these groups are also used to secure areas, iterations, and source control, more descriptive groups are required. Microsoft provides suggested group names for both the Agile and CMMI templates at the bottom of the Team Foundation Server Default Groups, Permissions, and Roles article on the Microsoft Web site. While this is a good generalization, and the CMMI suggested groups are used below for the suggested permissions, it is further suggested to evaluate your internal process and the roles already defined within your organization when creating groups in Team Foundation Server. This not only tailors the groups to your structure, but simplifies the understanding and traceability of Team Foundation Server across your team and entire organization. Once the groups have been determined, the process template should be updated to both record this decision, and prevent manual group creation effort every time a new team project is created. We will discuss setting default groups in the project template in the next section. Permissions Permissions assignable to these groups: Administer a build Delete this project Edit build quality Edit project-level information Publish test results Start a build View project-level information Write to build operational store Separation of Projects When a user or group is added to a TFS group, the user is automatically added to the Valid Users server group, which has View Project Level Information by default. What this means is that any user will be able to see any project. If your organization requires user/project restriction, you must remove the View Project Level Information right from the Valid Users server group manually for each project that is created. Areas Areas in Team Foundation are used to represent various pieces of the solution. The recommended approach is to use leaf nodes to represent project deliverable, and non-leaf nodes to represent project competencies. Area-level permission can be set in Team Explorer or through the TFSSecurity utility. Note however that areas cannot be required fields for work items, however. Suggested Permissions The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization. Iterations Iterations are used to represent a project's timeline breakdown. Iteration-level permission can be set in Team Explorer or through the TFSSecurity utility. Note however that iterations cannot be required fields for work items. Suggested Permissions The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization. Project-Level Suggested Permissions The following table outlines the rights available at the project level and suggested roles and rights assignments. This is only meant to be a guide, and should be tailored to your specific organization. Process Template Team Foundation Server is a process agnostic lifecycle platform which uses process templates to define a specific development process. Two process templates are installed by default; Agile, which defines a lightweight, low-ceremony process; and CMMI, which defines a more document-centric, high-ceremony process. While these two templates contain well-defined process definitions, most teams find the Agile template to be too relaxed and the CMMI template to be too restrictive. The real value in these templates is through customization to adapt to your existing process. We are going to look at two areas of the process template related specifically to security: groups and permissions and source control. Work items, which are also an integral part of a process template, and compliance in general, will be discussed in the Approvals part of this series. Groups and Permissions In the Project Security section above, we looked at groups and permissions on a project-by-project basis. In the process template, however, you can define default users, groups and permissions to be applied to each new project when it is created. Along with having to perform less manual effort for each team project, defining groups and permissions in a process template also helps to promote reusability and transparency. For each group, there are a set of permissions and areas where the permissions apply. Detailed descriptions of these permissions and areas can be found in the Groups and Permissions Process Template Plug-In article on the Microsoft Web site. Suggested Permissions The following table outlines the rights available in the Groups and Permissions section of a project template and suggested roles and rights assignments. This is only meant to be a guide, and should be tailored to your specific organization. One thing to remember with project-level permissions is that the PROJECT DELETE_TEST_RESULTS, PROECT CHECK_IN, NAMESPACE MANAGE_EVERYONE_GROUP, and NAMESPACE CHECK_IN are not valid for the Agile or CMMI included process templates. Source Control Source control permissions can be set on files and folders from within Team Explorer or from the Tf command line utility. While it is not possible to set default source control permissions from the Process Template Editor, you can manually edit the 'Version Control\ Version Control.xml' file in the process template. Along with setting default permissions, it is also suggested to evaluate your source control tree at various stages of development to determine if any additional rights should to be applied to a particular source tree node. For instance, you may only want users who are members of the Testers group to be able to check-in and check-out code from a test project. Suggested Permissions The following table outlines suggested permissions and roles at various project levels in Team Foundation Server. This is only meant to be a guide, and should be tailored to your specific organization. SharePoint Project Portals Windows SharePoint Services (WSS) is utilized by Team Foundation Server as a collaboration portal to house project documents such as requirements, designs, Excel spreadsheets, and more. Roles and Permissions SharePoint portals are created with four default roles and permission levels Administrator (Full Control) – has browse access to the project portal. Web Designer (Design) – can add new content to existing document libraries and lists. Contributor (Contribute) – Can create new document libraries and lists, as well as customize pages. Reader (Read) – Has full access to the project portal. Suggested Permissions The following table outlines suggested permissions and roles for Windows SharePoint Services. This is only meant to be a guide, and should be tailored to your specific organization. Reporting Services All data for Team Foundation Server is stored in a SQL Server data warehouse. This makes it ideal to use SQL Server Reporting Services to create and provide reports based on the stored data. Roles There are two site-wide and four project-level roles built-in to SQL Server Reporting Services. Site-Wide Roles System Administrator System User Project-Level Roles Browser Content Manager My Reports Publisher Report Builder Permissions Permissions (Reporting Services tasks) are granted to the predefined roles outlined in the previous section. Suggested Permissions The following table outlines suggested permissions and roles for SQL Server Reporting Services. This is only meant to be a guide, and should be tailored to your specific organization. Service Accounts In a compliance environment, it is important to regulate service accounts in addition to users and groups. For more information about managing service accounts, visit the Managing and Resetting Service Accounts and Passwords page on the Microsoft Web site. Utilities There are several utilities that can assist in creating and modifying users, groups, and rights. Microsoft TFSSecurity – A command line utility installed with Team Foundation. Tf – A command line utility installed with Team Foundation for working with source control. Microsoft Israel TFS Permission Manager – A graphical utility to administer permissions across all three platforms: Team Foundation Server, SharePoint and SQL Reporting Services. CodePlex TFSAdmin - A graphical utility to administer permissions across all three platforms: Team Foundation Server, SharePoint and SQL Reporting Services. More Information For more information about the topics discussed in this chapter, please visit the following resources. Overview of Team Foundation Security on the Microsoft Web site Team Foundation Server Permissions on the Microsoft Web site Team Foundation Security Groups on the Microsoft Web site Team Foundation Installed Help, located at %Program Files%\Microsoft Visual Studio 2005 Team Foundation Server\1033\TFSAdmin.chm on the Application Tier. Setting Permissions in Team Foundation on CodePlex. Resources SOX Permissions Worksheet Posted Feb 18 2008, 05:41 AM by Steve with no comments Filed under: TFS, security, compliance

• SOX 404: Compliance Not Found? (updated)

  Redux of original post. NOTE: This series of articles are written as introduction to complex subjects. They are general in nature and highly condensed. They are not intended to be legal advice or counseling in individual cases and cannot substitute for consultation with a knowledgeable attorney or other competent advisory. In case anyone has forgotten the scandals of Enron, Tyco, WorldCom, Arthur Anderson, and others, the years 2000 through 2002 were rocked by countless fraud and accounting scandals involving large corporations. Investors lost billions of dollars and the markets tumbled. In response, the Sarbanes-Oxley Act of 2002 (SOX) was enacted on July 20th 2002 in response to these scandals. President George W. Bush signed it into law, stating it included "the most far-reaching reforms of American business practices since the time of Franklin D. Roosevelt." For IT departments, there are two critical sections of SOX with which they need to be concerned. The first is section 404. Section 404, along with being the most contested and costly part of the bill requires a company and its external auditors to report on the sufficiency of the company's internal controls over financial reporting. This means that IT systems that specifically address financial risks may be within scope. The second critical section deals with penalties. Failure to comply could lead to $5 million in fines and twenty years in prison. The text of section 404 is as follows: SEC. 404. MANAGEMENT ASSESSMENT OF INTERNAL CONTROLS. RULES REQUIRED- The Commission shall prescribe rules requiring each annual report required by section 13(a) or 15(d) of the Securities Exchange Act of 1934 (15 U.S.C. 78m or 78o(d)) to contain an internal control report, which shall— state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting. INTERNAL CONTROL EVALUATION AND REPORTING- With respect to the internal control assessment required by subsection (a), each registered public accounting firm that prepares or issues the audit report for the issuer shall attest to, and report on, the assessment made by the management of the issuer. An attestation made under this subsection shall be made in accordance with standards for attestation engagements issued or adopted by the Board. Any such attestation shall not be the subject of a separate engagement. Fortunately, there is a practical solution. This post begins what will be a seven part series outlining how to achieve regulatory compliance using Team Foundation Server. Team Foundation Server provides not only an integrated approach to Application Lifecycle Management, but also the necessary tools and frameworks to be compliant with SOX. Each part of the series focuses on a specific concept in SOX and highlights the relevant areas of Team Foundation Server. These concepts are Separation of Duties, Documentation, Approvals, Testing and Auditing. Separation of Duties Separation of Duties is a cornerstone of SOX, requiring that no one individual have control of every aspect of a business process. Responsibilities should be assigned to individuals in such a way as to encourage checks and balances within the system and minimize the opportunity for unauthorized access or fraud. Documentation Any changes happening within a software system requires good documentation, including which work items are fixed, and how work items are fixed, tested, and released. Devoting effort in documentation from the start provides a foundation for a compliant development environment, and introductory documentation for an audit. Approvals SOX requires that changes made to financial reporting systems or controls follow a structured, rigorous approval process. Team Foundation work items support this approval requirement through the work item workflow, which can be customized to each environment. Testing Testing, and specifically regression testing, has been frequently recommended in audit reports as a method of ensuring that a system is still functional after a change has been made. Team Foundation includes robust testing tools, and can store test results as a documented history for auditors. Auditing Auditing requires proof of proper audit and control procedures. In most cases, the data required to compile reports for audit purposes is spread out across disparate systems in the enterprise. With an integrated approach to ALM and central data warehouse, Team Foundation can easily be customized to provide detailed audit reports. Before embarking on this adventure, it is important to note that not all companies are required to comply with SOX. Only US publicly traded companies, and foreign companies required to report to the SEC, are required to comply. Not all IT systems are required to comply either: only systems with a direct impact on financial reporting. As a final note, while this series specifically addresses Sarbanes-Oxley compliance using Team Foundation Server, the methodologies can be applied for any company in a highly regulated industry who must closely track their development process. Examples of such regulations include HIPPA, the Gramm-Leach-Bliley Act of 1999, SEC Rule 17A-4, and FACTA. Posted Feb 18 2008, 05:40 AM by Steve with no comments Filed under: TFS, compliance

• Ch-ch-ch-ch-Changes

  I used to really dislike Mercedes. I didn't care for the way they looked, and I thought they were, well, stupid. I swore I would never drive a Mercedes and I would ridicule them when I saw one on the road or in a parking lot or a driveway. But I was at a used car dealer looking at cars recently, and a Mercedes caught my eye. After taking it for a test drive I now have a Mercedes-Benz sitting in my garage. Somehow my distaste in Mercedes changed. I'm not sure what happened really, though I'm sure the low price and better gas mileage helped. And it is really fun to drive! I also used to seriously detest writing documentation. I would think about what a useless waste of developer resources it was to have to write down how to perform the task it was I just performed. I would avoid it whenever possible. But as you may have guessed, something switched inside of me. I don't harbor the inner feeling of annoyance to documentation anymore. In fact, I rather enjoy it. Well, most of the time. Lastly, and this is hard to admin (I'm bearing my soul here), but when the first version of .NET was released, I hated it. I was so appalled that Microsoft would go and change the very thing that gave me a paycheck. Sure, ASP.OLD and VB6 were a pain to work with, but the prospect of learning another seemingly brand new language was overwhelming and frightening. Of course, I don't think I need to go to great lengths to detail how this has changed. For starters, there is a possibility you may have gotten to this page through my second domain name: www.dotneticated.com. And I am. I speak at regional user groups and code camps, and I have even been called an unofficial .NET Evangelist by my peers. I now advocate that .NET is the greatest thing to happen to Windows since it got a GUI. I don't know what causes these changes. Maybe it's because I'm getting older, maybe they are a result of certain experiences in my life, or maybe I'm just going a little goofy, which is the most likely conclusion. I mean, who wants to write documentation and drive a Benz? Write .NET certainly, but write documentation? Whatever the reason though, it is hard to deny that as we look around at our environment and ourselves, things are always changing. If they weren't, we might still be wearing diapers. And in the case of .NET, what a welcome change it turned out to be. So it strikes me as somewhat odd now when I hear developers complain about how requirements for one project or another have changed. Why is it that we so readily accept the changes around us, the changes in our environment, yet when they occur in the course of software development we are astounded? If I had to hypothesize, I might guess that maybe it is just a facet of how the developer mind works. Or maybe it is because we deem ourselves as creative folks whose work is made perfect merely by virtue of its existence. Of course we are still getting paid to make the change, but that doesn't enter the equation. No, if I had to give a rational answer, I might say the problem lies in the notion that we now have to do more work, and that more than the work itself, in the arduous process we have to follow to do the actual work. To me, the concept of process used to be as exciting as getting underwear for Christmas. Even worse, it felt like a giant, maniacal, overbearing monster whose sole purpose was to make my life as difficult, tedious, and boringly repetitive as possible. I could never understand why it had to take an hour to change a static copyright on the bottom of an HTML page. And yet, the very thing I used to despise most about software development is now the very thing I find myself advocating for. This change took place a little while ago when I studied for, and subsequently passed the IBM 839 test and became an "IBM Certified Solution Designer - IBM Rational Unified Process V7.0" (ICSD RUP7), which is way too long of a title. I like to call it my ICSOO certification (IBM Certified Something Or Other). But what I discovered is that I don't hate process, I hate bad process. In fact, I found that I regularly use and subsequently appreciate good process. Let me emphasize that, I appreciate GOOD process. While I was studying for the RUP exam, I found myself realizing two similar, yet distinct concepts: A good, well planned process is beneficial to an organization beyond the scope of micromanagement. A good process can actually improve a developer's performance, quality, and job satisfaction. Through my continuing study into process and process frameworks, one concept keep coming back to me – a unified tool for process enablement. Part of any good process is the right tools to enable the process, and what I've found is that Team Foundation Server is just that tool; an integrated, flexible and easy-to-use Application Lifecycle Management (ALM) platform. Team Foundation Server is what I like to call process agnostic, a process enabler, and a process integrator. Process Agnostic While many tools force users to conform to a set, out-of-the-box SDLC, Team Foundation Server is based on the Microsoft Solutions Framework (MSF), which is a "defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft"1. Out-of-the-box, Team Foundation Server comes with two MSF process templates: Agile and CMMI, which provide process frameworks for both high-ceremony and low-ceremony environments. These are only meant to be templates, however. Through the free Team Foundation Server Power Tools add-in from Microsoft it is possible to modify an existing process or even create your own from scratch. No longer is one required to use tools which enforce an arbitrary process the manufacturer thought was a good idea. The Process Editor tool allows you to define default users and groups, areas and iterations, source control properties, and even work item workflows and forms for your process template. By creating your own process template, you can also ensure that business and project management knowledge is not lost when the next project comes around. Process Enabler For many companies, their processes leave a lot to be desired. While they may have a process, those processes often leave out important facets of the development lifecycle, such as document management, use cases, and appropriate testing. For instance, how many times has a project gone awry because of discrepancies and subsequent mis-development due to a lack of versioning of the requirements documents? To help alleviate this problem, Team Foundation Server has strong integration with Microsoft Windows SharePoint Services, and consequently Microsoft Office Word, thereby providing document storage, management, and versioning capabilities. Process templates contain work items specifically for creating and tracking use cases and scenarios to aid in the understanding and design of an application or system. And the Team Suite products contain strong testing capabilities. Working remotely, whether working at home one day a week or as part of a distributed or outsourced project team, can be more challenging due to domain, bandwidth, communication limitations, and other restrictions. To support communication and productivity for distributed teams, Team Foundation Version Control supports HTTP communication, and Team Foundation Server includes a caching proxy, which caches file content at the remote location, and is optimized for high-latency, low-bandwidth, and cross-domain environments. Team communication is enhanced through work item tracking, Visual Studio Team System Web Access, and the project's SharePoint portal. Process Integrator By and large, most processes use a whole host of disparate and disconnected tools which invariably leads to a loss of performance for the project team. These include tools for documentation, defect and enhancement tracking, source control, and the development environment itself. Team Foundation Server was built to integrate the various aspects of the SDLC under one platform, including project management, stakeholder management, testing, architecture, software and database development, auditing, build management and deployment. By doing so, some of the most costly aspects of process and change management are removed. Through a project's SharePoint portal, Team Explorer, and the newly released Visual Studio Team System Web Access, project and product managers, stakeholders, business analysts, auditors, and other members of the project team can view and add work items, download, upload, check-in and check-out documents from the project's SharePoint portal, view reports, view change sets, differences, and histories, and even start and stop builds. There are also utilities to support synchronization with project server and creating work item from Microsoft Office Outlook, and reports for auditing purposes can be created. In the Visual Studio Team Suite 2008 Architecture Edition, project management, architects, business analysts and subject matter experts can model the logical datacenter, applications (including SOA) and application systems, the settings and constraints on those applications, and finally how those systems deploy into the logical datacenter. A Visual Studio solution stub can then be implemented which is infused with that knowledge via process guidance and solution policies. If you are developing multiple applications, custom prototypes can be saved to expedite the creation of future distributed systems. The Visual Studio Team System 2008 Development Edition provides a plethora of resources for the application developer. An integrated environment means a developer doesn't have to leave the environment in order to view and update work items, check-in or check-out code, or perform tests, static code analysis, run code metrics, or test application performance. In addition, a feature called shelving lets you store work-in-progress that is checked out on the server without affecting the existing checked-in code, and makes it available to other developers for code reviews and testing. In the Visual Studio Team Suite 2008 Tester Edition, testers can author, execute, and manage tests and related work items – all from within Visual Studio. Testers can create unit tests, web tests, performance and load tests, test lists, and even evaluate code coverage. During the development process, developers can create unit tests, which can then be integrated into a testers test portfolio. I have only covered a few of the many integration features built into Team Foundation Server and Visual Studio Team Suite. For more in depth coverage, check out the Visual Studio 2008 Product Comparison and Visual Studio Team System 2008 Team Foundation Server on the Microsoft Web site. Conclusion For any organization who is stuck in the mire of a bad process, there is much to be excited about with Team Foundation Server and Visual Studio Team Suite. Change is almost never easy, and process can be a real project killer if it is not designed correctly. Now with Team Foundation Server you can create the right level of process for change and development, as well as integrate and streamline that process across your entire organization. Change happens, be ready. Additional Information What's New in Visual Studio Team System 2008 on the Microsoft Web site The Visual Studio Team System includes many new and enhanced features, which are summarized in this topic. Team Foundation Overview on the Microsoft Web site Team Foundation is a set of tools and technologies that enable a team to collaborate and coordinate their efforts on building a product or completing a project. Team Foundation enhances team communication, tracks work status, supports team roles, enacts the team process, and integrates team tools. Visual Studio Team System on the Microsoft Web site Visual Studio 2005 Team System is a platform for productive, integrated, and extensible software development life-cycle tools that helps software teams by improving communication and collaboration throughout the software development process. 1 http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx Posted Feb 17 2008, 06:57 PM by Steve with 5 comment(s)

• Speak up!

  I've been writing up a topic summary and stuff for the Tech·Ed U.S. 2008 Call for Content. Yesterday morning I logged into the submission web site, and was shocked to find out that the Call for Content had closed. My submission was going to be on regulatory compliance using Visual Studio 2008 Team Foundation Server, which I think would have been a good addition to the IT Professionals part of the conference. I didn't realize they were going to close it so soon. I also thought that it was being submitted through another channel, but that turned out to not be the case. So, if anyone knows how, or if I can still submit my topic, please speak up! Or maybe I should have spoken up sooner. Posted Feb 17 2008, 05:36 PM by Steve with no comments

• Testing the WinForms UI

  Yesterday I was engaged by a Test-Driven Development hardliner; a letter of the law type guy. He was very adamant that the .NET Framework and Visual Studio were grossly lacking because there is no way to test the UI, and Test-Driven Development requires a test to be written before any development can occur. The scenario given was that you have a form with a button and a label. When the button gets clicked, the label's text is set to "Hello World". He argued that evaluating whether the label's value was set to "Hello World" is not possible with the current testing framework in Visual Studio. At the time, I agreed with him; not about the severity of the issue, but that it wasn't possible. I am now retracting that assertion. I thought about that scenario quite a bit since yesterday, and how it might be achieved. First, I thought I might extend the base test type using the Visual Studio SDK (http://msdn2.microsoft.com/en-us/library/bb187323(VS.80).aspx) and provide a wizard which would generate code to use reflection to test the UI. Then, I thought maybe I could just write a whole bunch of code to reference in the tests; a UI Test Framework of sorts. I finally decided before I embarked down either path, I should open Visual Studio to, um, test out the basic assertion and mitigate the possibility that the reflection part might not be possible. First, I created a Windows Forms application with a button and a label and added a button click event handler which sets the label's text to "Hello World". Next, I went to the form's code view, right-clicked on the empty constructor, and choose "Create Unit Tests…." When the selection window opened up, I verified that the constructor and Initialize methods were selected, chose "OK". After Visual Studio created the test project and opened the test code file, I realized that I had missed the forest for the trees. The solution was much simpler than I had realized. In fact, the solution had already been built for me, and I wouldn't have to do any more work than I would for a normal unit test. See, behind the scenes, Visual Studio had detected that I was trying to create unit tests for a Windows Forms application, and had generated some extra code to assist. [TestMethod()] [DeploymentItem("WindowsFormsApplication1.exe")] public void InitializeComponentTest() {     Form1_Accessor target = new Form1_Accessor(); // TODO: Initialize to an appropriate value     target.InitializeComponent();     Assert.Inconclusive("A method that does not return a value cannot be verified."); }   The extra code, in part, is the Form1_Accessor symbol. Being the curious type, I checked in the bin directory for the test project, and found two new assemblies: WindowsFormsApplication1_Accessor.dll and WindowsFormsApplication1_Accessor.exe. Using Reflector, I ascertained that Microsoft had indeed built in the functionality and they had used Reflection as I had originally planned. So rather than writing hundreds of lines of code to add a feature Microsoft already had, I was able to get away with six lines of unit testing code to test the correct behavior of the button click: [TestMethod()] [DeploymentItem("WindowsFormsApplication1.exe")] public void ButtonClickTest() {     Form1_Accessor target = new Form1_Accessor();     target.InitializeComponent();     Assert.AreNotEqual(target.label1.Text, "Hello World", "Pre-click label text is not expected value.");     target.button1_Click(null, null);     Assert.AreEqual(target.label1.Text, "Hello World", "Post-click label text is not expected value.");     target.Dispose(true); }   Now all you Test-Driven Development guys can test happy! Posted Feb 05 2008, 10:30 PM by Steve with 2 comment(s) Filed under: Windows Forms, Testing