第 39 页

Of course, when they are ready to check the file back in, there must be a process of reconciliation

to ensure that their changes do not overwrite any changes made by another developer. Merging

changes can be a difficult process and can easily result in loss of changes or a final code set that

neither compiles nor runs. This model offers the luxury of allowing concurrent access to files, but

suffers from the operational overhead during check in.

adding the solution

Once a SourceSafe repository has been created, the Add to SourceSafe dialog appears, which

prompts you for a location for your application and a name to give it in the repository. SourceSafe

works very similarly to a network file share — it creates folders under the root ($/) into which it

places the files under source control.

fiGure 13-3

250 .

chaPter 13 code conSiSTency ToolS

Although it is no longer required with SourceSafe, many development teams

align the SourceSafe folder structure to the directory structure on your computer.

This is still considered a recommended practice because it encourages the use of

good directory and folder structures.

The Source Code Control (SCC) API assumes that the .sln solution file is

located in the same folder or a direct parent folder as the project files. If you

place the .sln solution file in a different folder hierarchy than the project files,

then you should expect some “interesting” source control maintenance issues.

solution explorer

The first difference that you will see after adding your solution to source

control is that Visual Studio 2010 adjusts the icons within the Solution

Explorer to indicate their source control status. Figure 13-4 illustrates

three file states. When the solution is initially added to the source

control repository, the files all appear with a little padlock icon next to

the file type icon. This indicates that the file has been checked in and is

not currently checked out by anyone. For example, the Solution file and

Properties have this icon.

Once a solution is under source control, all changes are recorded,

including the addition and removal of files. Figure 13-4 illustrates the addition of Form2.cs to

the solution. The plus sign next to Form2.cs indicates that this is a new file. The tick next to the

SourceSafeSample project and Form1.cs signifies that the files are currently checked out. In

the scenario where two people have the same file checked out, this will be indicated with a double

tick next to the appropriate item.

Checking in and out

Files can be checked in and out using the

right-click shortcut menu associated with

an item in the Solution Explorer. When a

solution is under source control, this menu

expands to include the items shown on the

fiGure 13-5

left in Figure 13-5.

Before a file can be edited, it must be checked out. This can be done using the Check Out for Edit menu

item. Once a file is checked out, the shortcut menu expands to include additional options, including Check

In, View Pending Checkins, Undo Checkout, and more, as shown on the right in Figure 13-5.

Pending Changes

In a large application, it can often be difficult to see at a glance which files have been checked out

for editing, or recently added or removed from a project. The Pending Checkins window (accessible

from the right-click context menu off the Solution Explorer or via the View menu), shown in Figure

13-6, is very useful for seeing which files are waiting to be checked into the repository. It also

provides a space into which a comment can be added. This comment is attached to the files when

fiGure 13-4

source Control .

251

they are checked into the repository so that

the reason for the change(s) can be reviewed

at a later date.

To check a file back in, you should ensure

that there is a check against the file in the

list, add an appropriate comment in the

space provided, and then select the Check In

button. Depending on the options you have

specified, you may also receive a confirmation

dialog prior to the item’s being checked in. If

the Keep All Checked Out option shown in

Figure 13-6 is checked, the files being checked in will remain in the checked out state, even after the

check in has completed successfully. This can be useful if you are in the middle of a set of changes

and want to commit your current changes so that other developers can access them.

One option that many developers prefer is to set Visual Studio to automatically check out a file

when it is edited. This saves the often unnecessary step of having to check the file out before editing.

However, it can result in files being checked out prematurely; for example, if a developer accidentally

makes a change in the wrong file. Alternatively, a developer may decide that changes made

previously are no longer required and wish to revert to what is contained in the repository. The last

button on the Toolbar contained within the Pending Checkins window is an Undo Checkout button.

This retrieves the current version from the repository, in the process overwriting the local changes

that were made by the developer. This option is also available via the right-click shortcut menu.

Before checking a file into the repository, it is a good idea for someone to review any changes that

have been made. In fact, some organizations have a policy requiring that all changes be reviewed

before being checked in. Selecting the Compare Versions menu item brings up an interface that

highlights any differences between two versions of a file. Figure 13-7 shows that a Form Load event

handler has been added to Form1.vb. Although not evident in Figure 13-7, the type of change is also

color coded; additions (such as the Say_HelloButton_Click method) are highlighted in green text,

and red and blue lines indicate deleted and changed lines.

fiGure 13-6

fiGure 13-7

252 .

chaPter 13 code conSiSTency ToolS

Because source files can often get quite large, this window provides some basic navigation shortcuts.

The Find option can be used to locate particular strings. Bookmarks can be placed to ease

navigation forward and backward within a file. The most useful shortcuts are the Next and Previous

difference buttons. These enable the developer to navigate through the differences without having to

manually scroll up and down the file.

Merging Changes

Occasionally, changes might be made to the same file by multiple developers. In some cases, these

changes can be automatically resolved if they are unrelated, such as the addition of a method to an

existing class. However, when changes are made to the same portion of the file, there needs to be a

process by which the changes can be mediated to determine the correct code.

Figure 13-8 illustrates the Merge dialog that is presented to developers when they attempt to check

in a file that has been modified by another developer. The top half of the dialog shows the two

versions of the file that are in conflict. Each pane indicates where that file differs from the original

file that the developer checked out. The left pane shows what is now in the source repository, while

the right pane shows the changes the developer has made. In this case, both versions had a message

box inserted, and it is up to the developer to determine which of the messages is correct.

Unlike the Compare Versions dialog, the Merge dialog has been designed to facilitate developer

interaction. From the top panes, changes made in either version can be accepted or rejected by

simply clicking the change. The highlighting changes to indicate that a change has been accepted,

and that piece of code is inserted into the appropriate place in the code presented in the lower pane.

The lower pane also allows the developer to enter code, although it does not support IntelliSense or

error detection.

fiGure 13-8

source Control .

253

Once the conflicts have been resolved, clicking the OK button saves the changes to your local file.

The merged version can then be checked into the repository.

History

Any time a file is checked in and out of the SourceSafe repository, a history is recorded of each

version of the file. Use the View History option on the right-click shortcut menu from the Solution

Explorer to review this history. Figure 13-9 shows a brief history of a file that had four revisions

checked in. This dialog enables developers to view previous versions, look at details (such as

the comments), get the particular version (overwriting the current file), and check out the file.

Additional functionality is provided to compare different versions of the file, pin a particular

version, roll the file back to a previous version (which will erase newer versions), and report on the

version history. When you select View History, you can also constrain the list by a date range and/or

by user.

fiGure 13-9

Pinning

The History window (refer to Figure 13-9) can be used to pin a version of the file. Pinning a version

of a file makes that version the current version. When a developer gets the current source code from

the repository, the pinned version is returned. Pinning a version of a file also prevents anyone

from checking out that file. This can be useful if changes that have been checked are incomplete

or are causing errors in the application. A previous version of the file can be pinned to ensure that

other developers can continue to work while the problem is resolved.

offline support for source control

Visual Studio 2010 provides built-in offline support for Visual SourceSafe when the source code

repository is not available. A transient outage could occur for many reasons — the server may be

down, a network outage may have occurred, or you could be using your laptop at home.

254 .

chaPter 13 code conSiSTency ToolS

If you open a solution in Visual Studio that

has been checked into Visual SourceSafe,

and the source code repository is not

available, you are first prompted to continue

or select a different repository. You may

also be asked if you want to try to connect

using HTTP. Assuming you select No for

both of these prompts, you are presented

with four options on how to proceed, as

shown in Figure 13-10.

If the issue is transient, you should select the

first option: Temporarily Work Offline in

Disconnected Mode. This allows you to check out files and continue editing source code.

fiGure 13-10

The first time you attempt to check out a file while working in disconnected

mode, you are presented with a very large dialog box that displays a small essay.

The basic gist of this message is that Visual Studio will actually be simulating a

checkout on your behalf, and you may need to manually merge changes when

you go to check code back in.

The next time you open the solution and the source code repository is available, Visual Studio

automatically checks out any “simulated” checkouts that occurred while working in disconnected mode.

Many of the source control operations are not available while working in disconnected mode.

These are operations that typically depend on direct access to the server, such as Check In, Merge

Changes, View History, and Compare Versions.

codinG standards

As software development projects and teams grow, there is a tendency for code to rapidly become

a mixed-bag of styles, standards, and approaches. This can lead to a maintenance nightmare, often

resulting in new features being parked due to an abundance of bugs and issues that need to be

addressed. Luckily, some great tools are both built into Visual Studio 2010 and available as Addins

that can enforce things like naming conventions, ordering of methods, and ensure appropriate

comments are written. In this section you learn about some tools that can be used to improve the

consistency of the code you and your team write.

code analysis with fxcop

Over several iterations of the .NET Framework and Visual Studio, Microsoft has put together a

set of coding standards that development teams can choose to adhere to. These are well documented

under the topic of Code Analysis for Managed Code Warnings on MSDN (http://msdn.microsoft

.com) and can be enforced using a tool called FxCop, which you can download from the

Microsoft download site.

Coding standards .

255

Visual Studio 2010 Premium edition and above include the Managed Code

Analysis tool, which is essentially a version of FxCop that is integrated into the

IDE. This is discussed in Chapter 55.

Once you have downloaded and installed FxCop you need to run it as a standalone tool from the

Start menu. If you want to run FxCop as part of your build process you can run it from the command

line using the FxCopCmd.exe

found in the install folder. When FxCop launches, it automatically

creates and opens a new project. Start by saving the project into the folder alongside the solution fi le

for your application. Then from the Project menu, select Add Targets and select the assemblies (dlls

and exes) that make up your application. Click the Analyze button to run the code analysis over

your application; the result should look similar to Figure 13 - 11.

fiGure 13-11

As you can see from Figure 13-11, there are three errors (including one marked as critical) and one

warning. Although you can ignore the warnings, they quite often indicate an area of concern, either

to do with the architecture or security of your code, so it is wise to try to minimize or eliminate

where possible the number of warnings and errors. In this example, the first error is easy to resolve;

you can just code sign the application and the error will go away. However, it may not be possible to

mark your assembly with the CLSCompliant attribute, which is what the second error is requiring.

So that this error doesn’t appear each time in the active errors list, you can right-click the error and

select Exclude. You’ll be prompted to add a comment so that you can justify the exclusion of that

error. Once you click OK, the excluded error will appear in the Excluded In Project tab, as shown in