• Individual .NET-based applications that appeal to end-users , scripters, and developers

• A set of re-usable components that makes it easy to build such applications

• A vibrant community to help define these applications and extensions

Let's start by defining the Clean target, as shown in the following code:

<ItemGroup>

      <BuildArtifacts Include=".\buildartifacts\"/>

</ItemGroup>

<Target Name="Clean">

      <RemoveDir Directories="@(BuildArtifacts)"/>

</Target>

We use the RemoveDir/ task to remove the $\build\buildartifacts\ directory. Nothing surprising here.

Next we want to initialize our build environment, which means recreating the $\build\buildartifacts\ directory:

<Target Name="Init" DependsOnTargets="Clean">

      <MakeDir Directories="@(BuildArtifacts)"/>

</Target>

Note that the Init target depends on the Clean target so the $\build\buildartifacts\ directory will be removed and recreated if it already exists. This ensures a clean build.

Moving onto the Compile task itself, I don't want to re-specify the project references, C# files, and configuration options that are already present in the project file. (Some developers do like to have this level of control with their builds and use the project files solely for organizing files within Visual Studio.) I will simply use the MSBuild/ task to compile the solution (which will compile the associated project files) defined by ScrewTurnWiki.sln. I override OutDir to place the build output in $\build\buildartifacts\ rather than in various <Project>\bin\Debug directories. I pass through the build configuration (Debug or Release) and set it to Debug if it is left unspecified, as shown in Figure 7. You can override additional options, such as CPU architecture, in a similar manner:

Compile Using MSBuild

<PropertyGroup>

      <Configuration Condition=" '$(Configuration)' == " ">Debug</Configuration>

</PropertyGroup>

<ItemGroup>

      <BuildArtifacts Include=".\buildartifacts\"/>

      <SolutionFile Include="..\ScrewTurnWiki.sln"/>

</ItemGroup>

<Target Name="Compile" DependsOnTargets="Init">

      <MSBuild Projects="@(SolutionFile)"Properties=

      "OutDir=%(BuildArtifacts.FullPath);Configuration=$(Configuration)"/>

</Target>

Full Build Script

      
<?xml version="1.0" encoding="utf-8"?/>

      <Project ToolsVersion="3.5" DefaultTargets="Compile"

             xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

            <PropertyGroup>

                  <Configuration Condition=" '$(Configuration)' == " ">Debug</Configuration>

            </PropertyGroup>

            <ItemGroup>

                  <SolutionRoot Include=".."/>

                  <BuildArtifacts Include=".\buildartifacts\"/>

                  <SolutionFile Include="..\ScrewTurnWiki.sln"/>

            </ItemGroup>

            <Target Name="Clean">

                 <RemoveDir Directories="@(BuildArtifacts)"/>

            </Target>

            <Target Name="Init" DependsOnTargets="Clean">

                 <MakeDir Directories="@(BuildArtifacts)"/>

            </Target>

            <Target Name="Compile" DependsOnTargets="Init">

                 <MSBuild Projects="@(SolutionFile)" 

                 Properties="OutDir=%(BuildArtifacts.FullPath);Configuration=$(Configuration)"/>

            </Target>

      </Project>

Notice the Project DefaultTargets="Compile"/, which specifies that the Compile target should be run if none is specified. You can have msbuild run a specific target using the /t switch. For example, to only run the Clean target:

msbuild build/ScrewTurnWiki.build /t:Clean

For more information on creating MSBuild scripts, I encourage you to read Sayed Ibrahim Hashimi's Best Practices For Creating Reliable Builds Part 1 and Part 2. I would also like to extend my thanks to Sayed for his assistance in troubleshooting a MSBuild issue that I encountered while writing this article.

Conclusion

This article is just the beginning of our journey as we set out to improve ScrewTurn Wiki. It is never too late to implement good development practices on an existing codebase, such as version control, issue tracking, automated self-contained build scripts, and automated testing. These practices provide your team with a safety net that allows you to more confidently make changes to improve an existing codebase. The next article will focus on automated testing, including acceptance testing with WatiN, a Web testing framework, and unit/integration testing with NUnit.

Other videos from this article

· Overview

· Source control

· Inspecting a project file

· Building from the command line

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd758790.aspx

In creating a build script, we want to automate common tasks for building the project source code as much as possible. Whether you know it or not, you are already using build scripts. When you create a new project, Visual Studio creates a build script for that project in the form of a .csproj or .vbproj file. (MSBuild was introduced with .NET Framework 2.0, so project files created by Visual Studio 2005 and above use the new MSBuild format under the covers.) If you open a project file in a text editor such as Notepad rather than Visual Studio, you will see something like this clip.

To run a build from the command line, simply launch a Visual Studio 2008 Command Prompt, navigate to the solution root, and execute:

msbuild ScrewTurnWiki.sln

Running the Visual Studio 2008 Command Prompt instead of the standard command prompt ensures that the Visual Studio and the .NET Framework directories are added to the PATH environment variable, enabling you to execute commands like msbuild.exe without specifying the full path to the executable. In addition to compiling the entire solution, you can compile individual projects.

msbuild src\app\Core\Core.csproj

Rather than editing the project files directly, I will create a separate build file for building the solution from the command line. If you are creating a custom build file, the two most commonly used build engines on the .NET platform are MSBuild and NAnt. (Other options include rake, Bake, and psake, among others.) I will use MSBuild since it is installed by default with .NET Framework 2.0 and above.

Other videos from this article

·         Overview

·         Source control

·         Inspecting a project file

·         Building from the command line

Read the full article at  http://msdn.microsoft.com/en-us/magazine/dd758790.aspx

All software development projects should use a version control system (VCS) for tracking and coordinating changes to code files and other project artifacts. The size of the project team doesn't matter as even a single developer benefits from using version control. If you are still using ZIP files to track changes to your source, you should reconsider.

A VCS helps a team coordinate changes to source code and other artifacts during development. If a developer tries to commit changes without updating to the latest version in the repository, the VCS will require the developer to update before committing. This will give the developer a chance to resolve any conflicts that may be present. The VCS also prevents one developer from accidentally overwriting the changes made by another developer.

A VCS also acts as a safety net for developers. If a developer makes a change that breaks the application, the change can easily be reverted by rolling back to a build with the latest known good state in the repository. Even if the change has been committed to the repository, it is possible to revert the change. Modern version control systems support branching, merging, and diffing. (For definitions of these and other terms, please take a look at our Glossary.) They can answer questions such as who last changed this code, what changes were made, and which other files were modified at the same time. They prevent developers from accidentally overwriting other changes either via edit/merge or a pessimistic locking (also known as checkout) mechanism. Although it sounds dangerous at first glance, edit/merge causes less friction on a development team and works better in practice than pessimistic locking. In most cases, merges happen automatically because developers are working on different parts of a code file. If developers happen to be working on the same part of the codebase, they should probably be coordinating their efforts somewhere other than the VCS.

There are many modern version control systems available today. For open source projects, the most popular—and free—choice is Subversion (SVN) and it is supported by most open source project host sites, such as SourceForge, Google Code, and CodePlex. (CodePlex actually uses Microsoft Team Foundation Server for source control, but hosts SvnBridge, which allows Subversion clients to talk to Team Foundation Server.) In corporate environments, teams often install these same version control systems, such as Subversion (SVN) or Team Foundation Server , behind the firewall.

The ScrewTurn Wiki project manages its source code using Subversion. If you want to get started with Subversion, I would recommend downloading TortoiseSVN (http://tortoisesvn.net), which is a Windows Explorer Shell Extension and provides context menus for source control operations. TortoiseSVN will also optionally install the command line tools, which allow you to use Subversion from cmd.exe or PowerShell. Let's take a quick tour of Subversion and TortoiseSVN ( see Figures 2 and 3):

Figure 2 TortoiseSVN File Manager View Showing Overlay Icons

You will notice the icon overlays in Figure 2, which is TortoiseSVN indicating the current status of a file/directory. (Green check = no pending changes; red exclamation = pending changes; question mark = not versioned; grey dash = ignored file) If you right click on a file/directory, as shown in Figure 3, you can see the TortoiseSVN context menu appear.

Figure 3 Context Menus for Source Control Operations

Glossary

branch: A temporary development line in a VCS repository. Often used while creating a patch, stabilizing a release (while development on the trunk continues), or experimenting with a new (and disruptive) feature.

changeset: Combined set of changes that should be atomically committed to a repository.

commit: Send a changeset to the VCS repository.

diff: Changes made to a file.

merge: Integrating multiple changes into a working copy. The changes can be from a different developer working on the trunk or from another branch.

patch: Changeset expressed as a single file that can be electronically sent to another developer.

tag: An important milestone in a VCS repository, such as a publicly released version (alpha, beta, full release, or patch). Similar in concept to labels in VSS.

trunk: The main development line in a VCS repository.

update: Retrieve any changes made to the trunk (or branch) since last update.

working copy: Local copy of a project checked out from a VCS repository.

Other videos from this article

·         Overview

·         Source control

·         Inspecting a project file

·         Building from the command line

Read the full article at  http://msdn.microsoft.com/en-us/magazine/dd758790.aspx

In this nine-part article series, I will take you on a journey to improve an existing "classic" ASP.NET Web application. By classic, I mean a Web application written in ASP.NET 1.X or 2.0, but before the widespread use of AJAX techniques or ASP.NET MVC. In other words, a Web application that you wouldn't be surprised to find running in your corporate data center or somewhere on the internet, or a workhorse of an application that gets the job done, but doesn't necessarily do it in a manner that is maintainable or that improves the productivity of its users.

In choosing a suitable Web application, I had a few requirements:

·         Typical ASP.NET 2.0 codebase

·         Good quality codebase

·         Familiar business domain concepts

·         Real Web application with publicly available source

Based on these requirements, I chose ScrewTurn Wiki, which is available from http://www.screwturn.eu/.

Let me explain why I chose ScrewTurn Wiki.

Typical ASP.NET 2.0 Codebase

I wanted the code to feel familiar so that techniques discussed can be easily transferred to your own codebases. The ScrewTurn Wiki codebase should be familiar to anyone who has ever written an ASP.NET 2.0 Web application—ASPX pages, ASCX controls, master pages, dynamic content stored in a database (or files).

Good Quality Codebase

I wanted the code to look like code that any of us could have written last year, last month, or last week. I want to show ways to improve the codebase, not ridicule its inadequacies. The reason for selecting ScrewTurn Wiki is not because it is desperately in need of improvement. On the contrary, ScrewTurn Wiki is an overall good codebase and could use improvement the way any quality codebase would benefit from improvement.

Familiar Business Domain Concepts

I wanted to choose a business domain that was easily recognizable and understandable to nearly everyone. Shopping carts and eCommerce sites have been used as examples far too frequently. A stock trading application is not a good choice in the current economy. Many other business domains, such as shipping, accounting, and others, simply require too much explanation of core concepts.

With the success of wikis such as Wikipedia.org, every developer should have at least a passing familiarity with the business domain concepts in a wiki—pages, edits, history, diffs, and similar. I hope that this familiarity makes the code easily approachable for a wide developer audience.

Real Web Application with Publicly Available Source

I wanted to improve a real Web application, not some contrived example. Additionally, I wanted to find an application with the source code available so that you could follow along as I refactored the codebase (a code download is available from the MSDN Code Gallery). ScrewTurn Wiki has a public Subversion repository and you can get the latest version of the source code from here:

svn://svn.screwturn.eu/STW/Trunk

You'll need a Subversion client such as TortoiseSVN, available from http://tortoisesvn.net, to download the latest source.

Note that I will be starting from the ScrewTurn Wiki 3.0 Beta codebase, "The Trunk" (noted above). Most ScrewTurn Wiki sites are currently running ScrewTurn Wiki 2.0. I felt that it would be more valuable and relevant to work with the latest source code rather than a previous version.

Other Advantages

Choosing ScrewTurn Wiki for this series has a number of other advantages:

·         It is the software behind many wikis on the internet

·         It was recently included in Microsoft Web Platform Installer v2

As such, many of you have probably heard of ScrewTurn Wiki even if you haven't looked at the source code.

Another big advantage is that when I contacted ScrewTurn Wiki's author/maintainer, Dario Solera, about using it as the Web application for this article series, he was excited and supportive. When finished with the article series, I will donate all source created back to the ScrewTurn Wiki project.

The Series

So what will I be doing to ScrewTurn Wiki in this nine-part series? I will apply a combination of good software engineering practices and integrate new technologies into the existing ScrewTurn Wiki 3.0 codebase. Each article will cover a different type of improvement and can be read alone or as part of the larger series. Topics will include everything from build automation/scripting, testing, and refactoring to HTTP handlers/modules, AJAX, jQuery, and ASP.NET MVC. This article will focus on “Brownfield Basics” or how to get started with improving an existing application.

What is a Brownfield Application?

Most developers have probably heard the term "greenfield development," meaning a brand new project without any existing source code. The project is a clean slate on which you can make your mark as an architect, developer, or designer. It is your own personal playground.

So what is brownfield? Wikipedia defines brownfield as:

...land previously used for industrial purposes, or certain commercial uses, and that may be contaminated by low concentrations of hazardous waste or pollution and has the potential to be reused once it is cleaned up.

 In software development terms, a brownfield application is an existing application which is developmentally hindered by poorly implemented practices, but has the potential for improvement. Poor practices might sound overly harsh, but almost every project can improve its software development practices in one way or another. When starting (or continuing) work on an existing application, we should consider the current practices implemented on the project and how they can be improved. I will examine ScrewTurn Wiki in light of some brownfield basics. (For a deeper look at brownfield development, I recommend Brownfield Application Development in .NET by Kyle Baley and Donald Belcham.)

Brownfield Basics

There are some fundamental software engineering principles that every project should adopt, regardless of the particular methodology to which you might subscribe. They are:

1.       Version control

2.       Issue tracking

3.       Automated, self-contained builds

4.       Automated testing

In the rest of this article, we will discuss the first three. Automated testing will be the topic of the next article.

Other videos from this article

·         Overview

·         Source control

·         Inspecting a project file

·         Building from the command line

Read the full article at  http://msdn.microsoft.com/en-us/magazine/dd758790.aspx

    http://dotnetblogengine.net