Chapter 4: Planning Phase: Setting Up the Development and Test Environments
After finalizing the project plans and project schedules as part of the Planning Phase, you need to focus on setting up the development, test, and staging environments. The setup and management of a dedicated development, test, and staging environment is required in the Planning Phase to ensure smooth migration in the later phases. This is done after defining the solution design and architecture as discussed in Chapter 3 of this volume. The development and test environments allow proper development and testing of the solution so that it will have no negative impact on production systems. They must be properly set up before moving into the Developing Phase in order to maximize development team productivity and to mitigate risks. To avoid delay, the development and testing environments should be set up even as plans are being finalized and reviewed. The Microsoft® Solutions Framework (MSF) Release Management Role is typically responsible for performing these tasks for the project team. Setting up the development and test environments in the Planning Phase helps you to identify the infrastructure requirements and tools required for the development and testing activities. It also gives you instructions about the configuration of the integrated development environment (IDE) for development activities.
On This Page
Setting Up the Development Environment
Setting Up the Test Environment
Setting Up the Staging Environment
Interim Milestone: Development and Test Environment Setup
Key Milestone: Project Plans Approved
Setting Up the Development Environment
The development environment consists of the hardware, software, and tools that enable development activities in the migration project. The development environment includes the compilers, libraries, tools for debugging, source code management, and the IDE. This section provides an overview of the Microsoft Windows® operating system development environment. In addition, this section discusses the development environments for Windows Services for UNIX 3.5, Win32®/Win64, and .NET.
The Windows operating system development environment includes the following:
SDKs such as Interix SDK for Windows Services for UNIX, Platform SDK for Win32/Win64, and .NET Framework SDK for .NET (which include compilers, editors, and debuggers) provide the basis for creating, building, and debugging the application.
IDEs, such as Visual Studio .NET 2003, provide uniform and coherent access to tools.
Software management tools such as software for source code management and problem tracking are not critical, but they add significant value to larger migration projects.
Analysis tools, such as performance analysis and testing tools, can be used to improve the performance of the application.
Cross-platform tools and libraries, including third-party packages such as Rogue Wave SourcePro, can be integrated with the application.
The facilities provided in the development environment, such as compilers, source control system, IDEs, and tools, are used by both the developers and the testers of the system. The decisions made while developing the migration strategy will help define the development environment. This environment is either native Microsoft Win32/Win64 application programming interface (API), Interix, or Microsoft .NET.
The solutions recommended in this chapter use the Microsoft Visual Studio® .NET 2003 integrated development environment (IDE) for Win32/Win64 source editing, builds, and makefile-based batch builds. Interix solutions use the Microsoft Visual Studio for source editing and the included Interix SDK (software development kit) tools for compiling, linking, and debugging (gcc and gdb). .NET solutions use Visual Studio .NET 2003 IDE for source editing, compiling, linking, and debugging. Win32/Win64 solutions and .NET solutions are integrated with Microsoft Visual SourceSafe® as version control software for source code control. Interix solutions use out-of-the box Revision Control System (RCS) for source code control.
This section describes how to set up a development environment for migrating applications and the major tasks involved in setting up the development environment. These tasks include:
Identifying the tools and IDEs.
Migrating source under source control.
Configuring the development environment.
Populating the development environment.
Migrating the build environment.
The following sections describe each of these topics in detail.
Identifying the Tools and IDEs
The following sections identify the tools and IDEs required for developing the applications using the following Windows technologies:
Windows Services for UNIX 3.5
Each section describes the necessary tools required for the development environment and is organized as follows.
Software development kit (SDK). The SDK provides extensible options for developing the application using its code files, import libraries, and the application programming interfaces.
Compiling tools. A compiler is a specialized computer program that converts source code written in one programming language into another intermediate language or computer language so that it can be understood by computer processors.
Debugging tools. Debugging is the technique of determining the cause of the symptoms of malfunctions in the source code. The debugging tools allow you to trace the source code by adding break points and viewing the data at that point during runtime.
Application build tools. Application build tools help you in developing and designing the application by reducing the development time and improving the reusability.
Third-party extension tools. Third-party tools work as add-ins to the existing IDE or as stand-alone applications to obtain the additional functionality.
Source code management tools. Source code management tools help you manage multiple versions of source files in a space-efficient manner by storing only the differences between the versions and configuration management.
Note Some of the topics described previously are not applicable for Windows Services for UNIX 3.5.
Windows Services for UNIX 3.5
The following tools and IDEs are useful for developing applications using Windows Services for UNIX 3.5.
The Interix SDK for Windows Services for UNIX 3.5 contains documentation, tools, API libraries, and headers that the language compilers require to port UNIX applications to Windows. With the Interix SDK, you can host your own tools and applications alongside Windows Services for UNIX tools and applications.
The Interix SDK includes a UNIX development environment, with tools such as the GNU gcc, g++, and g77 compilers, and the gdb debugger. The Interix SDK also provides UNIX-style command-line interfaces through the cc and c89 compiler drivers for Visual Studio .NET 2003. You can compile C programs to use the benefits of the native compiler for Windows. The cc and c89 tools work only with the Visual C++® compiler. These tools do not work with the gcc compiler. You cannot compile C++ code with the cc and c89 interfaces. You must use g++ for a C++ code.
The Interix SDK documentation includes developer guides and references for all POSIX.1 system interfaces and headers, Interix extensions to POSIX.1 and POSIX.2 interfaces, and the International Organization for Standardization/American National Standards Institute (ISO/ANSI) C libraries. The Interix SDK documentation also provides information on designing and building UNIX daemons as services, curses, and X Windows-based applications and porting UNIX code along with various categories of APIs and services.
Interix provides a rich set of command-line and stand-alone tools for building, debugging, and testing applications. The following tool categories are also delivered with the SDK:
Compiling (cc, c89, gcc, g++, and g77)
Performance monitoring tools
Integrated Development Environments
For creating applications using Windows Services for UNIX 3.5, you can use Visual Studio or Visual Studio .NET 2003 as integrated development environments.
For more information on this, refer to ".NET" section later in this chapter.
The Interix SDK provides compilers to run C, C++, and Fortran programs using the Interix SDK API. It includes compliers like cc, c89, gcc, g++, and g77. You can compile your programs from the command line using the makefiles. You can also specify appropriate complier options for debugging, preprocessing, and optimizing the programs. The compilers cc and c89 work as an interface to the system C compiler. If Microsoft Visual C++ is installed, Windows Services for UNIX setup configures cc and c89 complier interfaces to a Visual C++ compiler. Both cc and c89 invoke the Microsoft Visual C++ tools Cl.exe for compiling and Link.exe for linking.
For more information on compiler options, refer to help documentation for Services for UNIX 3.5.
The Interix SDK contains the GNU debugger (gdb). The debugger attaches to the virtual file system. It provides information only for object files compiled with gcc and g++, not for files compiled with cc or c89 compilers. The Interix implementation of the gdb debugger works with shared libraries.
For more information, refer to refer to help documentation for Services for UNIX 3.5 or the gdb help function.
Source Code Management Tools
Table 4.1 describes the source code management tools that can be used by Windows Services for UINX 3.5 to manage source code.
Table 4.1. Source Code Management Tools for Windows Services for UNIX 3.5
The Revision Control System (RCS) manages multiple revisions of software files. RCS can store, retrieve, log, identify, and merge file revision data.
The RCS tools provided by the Interix SDK are based on the RCS 5.6 tools.
The Concurrent Versions System (CVS) is the dominant open-source, network-transparent version control system. This tool does not include the Interix SDK by default. You can download it at
This section discusses the tools and IDEs that are useful for developing applications using Win32/Win64.
Windows Platform SDK
A Windows Platform SDK provides tools to help build, debug, test, and deliver applications. It also provides all the definitions (include files) and libraries that are needed to compile programs. In general, SDK tools are run from the command line, just as applications are run from a shell prompt in UNIX. Output from SDK tools can be files created on the disk, text output to the console (like stdout in UNIX), or graphical output to one or more dialog boxes.
The Windows Platform SDK is a set of tools and API definitions that help create applications for the Windows platform. The SDK includes files and documentation for all subsystems and APIs in Windows. It also contains definitions and documentation for the Microsoft .NET Enterprise servers, including Microsoft BizTalk® Server, Microsoft Commerce Server, and Microsoft SQL Server™. Installation of the .NET server components is optional.
ThePlatform SDK is available on CD and as a free download on the Web. It is also available with Visual Studio .NET 2003 or with an MSDN Professional or Universal subscription. You can order or download the SDK at
Integrated Development Environments
For creating Win32/Win64 applications, you can use Visual Studio 6.0 or Visual Studio .NET 2003 as integrated development environments. This guide recommends using Visual Studio .NET 2003 as the IDE for developing Win32/Win64 applications.
Visual Studio 6.0
The Visual Studio 6.0 integrated development environment can be used as the IDE for developing applications in Win32/Win64 with the Windows Platform SDK.
Visual Studio .NET 2003
The Visual Studio .NET 2003 IDE can also be used for developing applications using Win32/Win64. For more information, refer to ".NET" section later in this chapter.
The Platform SDK provides compilers to run C or C++ programs using the Windows API, targeting 32-bit and 64-bit platforms. The IDE can be used to compile applications using the compiler with the Platform SDK by making the appropriate settings for 64-bit applications. For more information on this, refer to Chapter 2, “Developing Phase: Process Milestones and Technology Considerations” of Volume 3, Migrate Using Win32/Win64 of this guide.
You can also compile your programs from the command line instead of using the IDE. You can also specify several appropriate options for debugging, preprocessing, and optimizing the programs, both from the IDE and the command line.
Note More information on C++ compiler options is available at
The Visual Studio 6.0 or Visual Studio .NET 2003 built-in debugger can be used for debugging Win32/Win64 applications. The debuggers can set breakpoints, execute the program or step through it one line at a time, and examine memory and registers. The debuggers understand the debugging information in the application and can display the source with the executing program. The symbolic debuggers and the associated tools are:
Microsoft Windows NT® Symbolic Debugger (NTSD) debugs user mode programs.
Debug Monitor (DbMon) runs in its own console window and displays messages sent by the application.
MAPSYM converts the contents of your application's symbol map (.map) file into a symbol.
WinDBG is used for debugging Windows-based programs, services, and kernel-mode drivers, which provides source-level debugging through a graphical user interface (GUI).
WinDbg uses the Microsoft Visual Studio® debug symbol formats for source-level debugging. It can access any public function names and variables that are exposed by the modules compiled with Codeview (.pdb) symbol files. WinDbg can view source code, set breakpoints, and view variables (including C++ objects), stack traces, and memory. It includes a command window for issuing a wide variety of commands not available through the drop-down menus. WinDbg also allows remote debugging of user-mode code.
Note More information on debugging tools for Windows 32-bit is available at
More information on debugging tools for Windows 64-bit is available at
Application Build Tools
Most migration projects rely heavily on the text files tools. WinDiff, for example, is a graphical tool for comparing files and directories, recursively, if required. Files with differences are highlighted with colors for your convenience. Another useful tool is Where, which finds a file by name or pattern in a directory or subdirectories.
In addition, Visual Studio 6.0 also provides tools that help in the design and development of the software. Some of the Visual Studio tools are:
Visual Modeler assists object-oriented programming to create applications quickly and easily and contains components that can be reused in other applications. Visual Modeler enhances the capability to develop scalable applications supporting reverse engineering and round-trip engineering.
Application Performance Explorer monitors the performance of applications.
Remote Automation Connection Manager sets or revokes the permissions on the COM components.
Third-Party Extension Tools
You can use third-party tools that integrate with Visual Studio in the development environment for Win 32/Win64. Add-ins can also be used. For more information on this, refer to “Third-Party Extension Tools” in the next section.
Source Code Management Tools
Source code management tools can be integrated into the Visual Studio .NET 2003 IDE to perform an automatic checkout when a developer modifies a file. For more information on this, refer to “Source Code Management Tools” in the next section.
The following tools and IDEs are useful for developing applications using .NET.
.NET Framework SDK
In addition to .NET Framework, the Microsoft .NET Framework SDK includes everything you need to write, build, test, and deploy .NET Framework applications like command-line tools and compilers. The SDK also contains excellent documentation and Quick Start tutorials that help you learn .NET technologies with ease. It is available free of cost and you can download the entire Framework SDK from the MSDN Web site at
Note that when you install Visual Studio .NET 2003, the .NET Framework is automatically installed on your computer.
To run applications developed using .NET Framework, the computer must have certain run-time files installed. These files are collectively called .NET redistributable. The .NET redistributable provides one redistributable installer that contains the common language runtime (CLR) and .NET Framework components that are necessary to run .NET Framework applications. The redistributable is available as a stand-alone executable and can be installed manually or as a part of your application setup.
For more information on CLR, refer to the .NET build volume (Volume 4) of this guide.
You can download .NET redistributable from
Technical information on .NET redistributable is available at
Note If you have installed the .NET Framework SDK, you do not need to install .NET redistributable separately. Note that there is a difference between the .NET Framework SDK and .NET redistributable in terms of purpose, tools, and documentation supplied. The .NET Framework SDK is intended to "develop and execute" applications, whereas .NET redistributable is intended to "run" .NET applications.
Integrated Development Environments
Unlike the SDK command-line tools, IDEs offer users an integrated set of tools such as editors, compilers, and debuggers. Visual Studio .NET 2003, the IDE discussed here, comes with a choice of .NET languages (such as C#, VB.NET, and Managed C++), compilers and debuggers, and a large set of integrated tools that do everything from creating resources to packaging applications for installation.
The Visual Studio .NET 2003 IDE is an integrated visual development environment that allows you to program on .NET Framework on various languages. Visual Studio .NET 2003 is available in the following editions.
You can select the edition that is appropriate for the kind of development you are doing:
The Visual Studio .NET 2003 Professional edition offers a development tool for creating the various types of applications mentioned previously.
The Visual Studio .NET 2003 Enterprise Developer (VSED) edition provides all features of the Professional edition, along with additional capabilities for enterprise development. These additional features include such functionality as collaborative team development, third-party tool integration for building XML Web services, and built-in project templates with architectural guidelines, spanning a comprehensive project life cycle.
The Visual Studio .NET 2003 Enterprise Architect (VSEA) edition provides all features of the Enterprise Developer edition, along with capabilities for designing, specifying, and communicating application architecture and functionality. These additional features include Visual Designer for XML Web services, Unified Modeling Language (UML) support, and enterprise templates for development guidelines and policies. A complete comparison of these editions is available at
In addition to these editions, special language-specific editions are available with Visual Studio .NET 2003. A complete comparison of the standard editions listed here with the professional edition of Visual Studio .NET 2003 is available at
This guide considers Visual Studio .NET 2003 as the integrated development environment (IDE) for developing .NET applications. Although newer technologies exist, the guide is based on best practices developed by partners and customers. As new practices establish, they will be incorporated into future releases of the guide. These latest technologies and their features are briefly described in “Roadmap for Future Migrations” of Volume 5: Chapter 2, “Operations” of this guide.
Visual Studio .NET 2003 provides compilers for the common .NET-supported languages like Visual C#.NET, VB.NET, Managed C++.NET, Visual J#.NET, and JScript.NET. These compilers are used to produce a highly optimized Intermediate Language (IL) code. Later, when the code is executed for the first time, a JIT (Just In Time) compiler translates this IL code to the computer code.
You can also compile your programs from the command line. For example, the following command compiles a C# program named Test.cs:
You can also specify several appropriate options for each of the language compilers, both from the IDE and the command line.
More information on compiler options is available at C++ Compiler options at
More information on compiler options is available at C# Compiler options at
The process of debugging applications essentially goes in the reverse direction from the process of compiling the code. As you execute the code, the debugger first maps the native code back to MSIL, and then maps the MSIL code back to the source code using programmer database (PDB) files. Therefore, to enable debugging, it is necessary to generate the required mapping information at each stage in the compilation process.
To debug .NET Framework applications, Microsoft provides a debugger integrated with Visual Studio .NET 2003. When you run your code in debug mode, you can watch how it executes each line of code. To run your project in the debug mode, click Start on the Debug menu. Alternatively, press F5 on your keyboard.
Apart from the debugger in Visual Studio .NET 2003, you can use the Microsoft CLR debugger (DbgClr.exe) and the Runtime Debugger (Cordbg.exe), which are included with the .NET Framework SDK, to debug your applications. Table 4.2 explains the usage of these tools.
Table 4.2. Debugging Tools
Visual Studio .NET Debugger
Provides debugging for various sets of applications to inspect and modify the state of the programs.
Allows debugging of managed code, Win32 native code, COM, ActiveX controls, script, Web applications, and SQL stored procedures and Just-In-Time debugging.
Microsoft CLR Debugger (DbgClr.exe)
Provides debugging services with a graphical interface to help application developers find and fix bugs in programs that target the runtime.
Allows debugging of applications written in Visual Basic .NET or C# or managed C++ and compiled only for common language runtime. Does not support debugging of Win32 native code, unmanaged C++ code, and remote debugging.
Runtime Debugger (Cordbg.exe)
Provides command-line debugging services using the CLR Debug API. Used to find and fix bugs in programs that target the runtime.
Allows command-line debugging with the compiled managed code. Does not support compiling the code and debugging unmanaged code.
Application Build Tools
In addition to well-known tools such as Visual Studio .NET 2003, there are a multitude of small but effective tools that are available free of cost from the .NET community. These tools make the process of building .NET applications faster and easier. Some of these tools are:
NUnit to write unit tests.
NDoc to create code documentation.
NAnt to build your solutions.
CodeSmith to generate code.
FxCop to police your code.
Snippet compiler to compile small bits of code.
Two different switcher tools: the ASP.NET Version Switcher and the Visual Studio .NET Project Converter.
Regulator to build regular expressions.
.NET Reflector to examine assemblies.
More information on these tools is available at
Third-Party Extension Tools
Third-party tools that integrate with Visual Studio .NET 2003 to enable detection of run-time errors include:
BoundsChecker from Compuware.
PurifyPlus from IBM.
BoundsChecker, a run-time error detection tool, was originally a single product. It is now part of the DevPartner Studio suite, which contains performance as well as debugging tools. BoundsChecker can diagnose programming problems unique to C++, such as stack and heap memory errors, and leaks of memory and resources. BoundsChecker also eliminates common Windows mismatched argument problems by checking API calls for Win32, ODBC, and Internet, among others.
PurifyPlus contains the Purify error and memory problem detection tool as well as performance tools to analyze bottlenecks and to detect untested code. PurifyPlus also checks for errors in API calls, including Win32, ActiveX® controls, COM objects, and DLLs. PurifyPlus detects C++ memory problems such as heap and stack errors, pointer errors, memory usage errors, and handle errors. PurifyPlus also works outside the Visual Studio IDE for stand-alone debugging.
MKS software offers an extension to Visual Studio .NET 2003 to support the UNIX lex and yacc tools. The lex scanning tool analyzes input text files for the occurrence of predefined text patterns. The yacc (another compiler tool) is a parser that takes a setup input token and applies a set of grammar rules to the token. A combination of lex and yacc provides developers with a powerful method to generate compilers, front-end processors for compilers, text processors, and language translators. The lex tool creates tokens based on regular expressions, and yacc performs grammar rules on the tokens. The MKS lex and yacc tools work as add-ins to Visual Studio .NET 2003 that allow developers to create scanners and parsers within the Visual Studio .NET 2003 IDE.
Source Code Management Tools
Source code management tools can be integrated into the Visual Studio .NET 2003 IDE to perform an automatic checkout when a developer modifies a file. Source code management tools that integrate with Visual Studio .NET 2003 have point-and-click interfaces, which may be new to UNIX developers.
Visual SourceSafe is the source code management tool for Win32/Win64 and .NET applications. It creates projects in a tree view structure and provides complete source control for checking files in and out and tracking differences between files. Visual SourceSafe uses COM automation for customization.
The automation model can help automate the migration of source code from UNIX to Windows by automating repetitive tasks. For example, in a batch build process, you can use the automation features of Visual SourceSafe to retrieve the source code automatically before it is compiled.
Like other source code control systems, Visual SourceSafe maintains a library of projects from which users check out files for exclusive or nonexclusive access. Users check in the files after they are modified and tested. If nonexclusive checkout is allowed, the files are interactively merged at check-in time, if necessary. You can recall each incremental checked-in version if functionality is inadvertently deleted. Visual SourceSafe can also create releases by labeling the files. Visual SourceSafe handles text as well as binary files.
The .NET Framework SDK also includes several tools for examining assemblies and working with the system assembly cache. Table 4.3 lists the packaging and deploying tools.
Table 4.3. .NET Tools
Assembly Binding Log Viewer (Fuslogvw.exe)
Windows-based tool for examining assembly and resource bind requests.
Assembly Linker (Al.exe)
Assembly linker for creating assembly manifests, satellite assemblies, and working with the GAC.
Global Assembly Cache Tool (Gacutil.exe)
Console tool that manages the GAC and download caches.
MSIL Disassembler (Ildasm.exe)
Windows-based tool for examining the manifest (containing metadata) and MSIL code inside assemblies.
Strong Name Tool (Sn.exe)
Console tool to help generate strongly named assemblies.
File Signing Tool (SignCode.exe)
Wizard that helps to sign a portable executable (PE) file (.dll, .exe, .ocx, or .cab file) with an Authenticode digital signature.
More information on these packaging and deploying tools is available at
Note For information on tools related to testing and on tuning of applications, refer to Chapter 9, "Stabilizing Phase" of the build volumes (Volume 2, Volume 3, and Volume 4) of this guide.
Migrating Source Under Source Control
Source control systems impose additional requirements on moving the code. First, if the source control system allows both UNIX and Windows clients, then creating the project environment is the main step. In this case, after the Windows project environment is created, the source is moved by just checking out the source to the appropriate project area.
However, if the source control system does not allow both UNIX and Windows clients, perform the following steps:
Check out the project source from the source control system on UNIX.
Package the source on UNIX.
Copy the source to Windows.
Unpack the source on Windows.
Check the source into source control on Windows.
The remainder of this section describes these steps by using tools that are available on both UNIX and Windows.
First, the user checks out the source from the UNIX source control system into a local working directory on UNIX. Most code management tools provide facilities for exporting an entire code hierarchy and creating a tar file directly. If this is not the case, the hierarchy must be checked out and then packaged. The steps for packaging, copying, and unpacking the source take place in much the same way as already described in this section.
After it is moved and unpacked, the source needs to be checked into source control in the Windows environment. From the command line, the administrator can create a project, add the files to the project, and check the files into Visual SourceSafe by using the following commands:
ss Create $/MySystem ss Add <working directory path>\MySource.C
ss Checkin MySource.C
The following command recursively retrieves all files associated with the MySystem project in Visual SourceSafe:
ss Get $/MySystem –R
Configuring the Development Environment
Configuring the development environment involves setting up the environment variables, logon scripts, computer configuration, application configuration, and security attributes. The following sections describe the instructions for configuring the development environment for Windows Services for UNIX 3.5, Win32/Win64, and .NET applications.
Configuration for Windows Services for UNIX 3.5
The Interix environment must be configured directly after its installation. As part of its configuration, administrators can add directories to the PATH variable in startup files. For example, the administrator may want PATH to point to programs and shell scripts in a directory named bin under the home directory. For examples of how to modify PATH, under /etc, see the files profile, profile.lcl, and profile.usr.
To manage the logon environment, create logon scripts in the home directory. The Korn shell uses the logon script .profile to manage the user's profile. Interix provides the /etc/profile.usr file as a template for creating .profile.
To use the Interix template
Copy /etc/profile.usr to the home directory and rename it .profile.
Edit .profile to set the initial environment to the desired requirements.
To customize the environment in the C shell
- Create the files $HOME/.cshrc, $HOME/.history, $HOME/.login, and $HOME/.cshdirs. When a user logs on, the C shell runs all of these files.
Interix maps the root directory (/) to the Windows Services for UNIX installation directory, which is C:\SFU by default. Under the Interix root directory, there are subdirectories that usually exist in UNIX, such as /usr and /etc. There are also virtual directories, such as /net for network resources and /dev for devices. In addition to entries for the usual devices, the /dev directory includes entries that correspond to Windows drive letters. For example, /dev/fs/A and /dev/fs/C correspond to drives A and C respectively.
Note If you change this default installation path, you should avoid spaces in the path name to minimize the confusion for UNIX programs and tools.
By default, Interix stores system binaries in one of the following three directories:
Interix stores the X11 binaries in /usr/X11R6/bin and the Win32 binaries in /usr/contrib/win32/bin. Some symbolic links are added, for example, so that /usr/bin maps to /bin. Because of this, the file system tree’s configuration supports most UNIX application and script ports to the Interix environment.
The creation and management of a development project in Interix proceeds just as in any UNIX environment. First, identify the location and format of the application to be prototyped (ported), and then determine its format (such as compressed tar file). Decide the location to which you want to load the source tree (and verify that there is enough disk space). Be sure that the development platform has the tools required for this application and for any other applications that will be ported to or developed in the Interix environment.
Configuration for Win32/Win64
Visual Studio .NET 2003 or Visual Studio 6.0 are configured to work with Win32 applications at the time of installation. You can configure to work with 64-bit applications using the /useenv option.
To load the 64-bit tool chain, execute the following statements:
call "C:\Program Files\SDK\SetEnv.Bat" /AMD64 /RETAIL
start devenv /useenv
To resume working with the 32-bit tool chain, quit VS6 and then use the following statements to relaunch the IDE:
call "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\Bin\VCVARS32.BAT"
start devenv /useenv
Note For more information on this, refer to “Using the Development Environment” section in the Win32/Win64 build volume (Volume 3).
Configuration for .NET
The .NET Framework provides to developers and administrators control and flexibility over the way applications run. An administrator can control which protected resources an application can access, which versions of assemblies an application will use, and where remote applications and objects will be located. Developers can add settings in the configuration files, eliminating the need to recompile an application every time a setting changes. Configuration files are XML files that can be changed as needed. Developers can use configuration files to change settings without recompiling applications. Administrators can use configuration files to set policies that affect how applications run on their computers.
There are three types of configuration files:
Computer configuration files (Machine.config), which contain settings that apply to the entire computer.
Application configuration files, which contain settings specific to an application.
Security configuration files (Security.config), which contain settings specific to the computer security.
More information on configuring applications in .NET is available at
To make all the individual files or components into an application, a project needs to be created from those files. A project consists of separate components that are stored as individual files in a solution. A simple project might consist of a form or HTML document, a database, source code files, and a project file. All projects are contained within an application, and every project contains a unique project file. The project file is a list of the project's files and objects and is used to store information about the project-specific environment options. The following sections describe the instructions for creating the projects for Interix, Win32/Win64, and .NET applications.
Creating a Project for Windows Services for UNIX 3.5
To use Visual Studio .NET 2003 to compile your Windows Services for UNIX application
On the File menu, point to New, and then click Project.
In the Project Types list on the New Project dialog box, click Visual C++ Projects.
Click Win32, and select Win32 Console Project as the Template.
Before adding a new project to this solution, set the name of the project and the path where this project will reside on the hard drive of your computer.
In the Location text box, enter the path where you want this project to reside. Visual Studio .NET creates the necessary path and will create a folder name with the same name as the project. For example, if you fill in the name CreateThread and set the path to D:\MySamples, the solution will be created in D:\MySamples\ CreateThread \ CreateThread.sln.
To compile your application
Add the C source file to the Source Files folder shown on the right side of the Solution Explorer.
On the Project menu, click Settings, select Configuration Properties folder and then Build Events folder, and then select Configuration Type as Utility.
Go to Pre-Build Event in the Build Events tab, and enter the following as Command Line:
POSIX.EXE /c %SFUDIR%\bin\ksh -c "/usr/bin/cross_build
Note that you need to have a script file cross_build.sh in the %SFUDIR%\bin directory. Copy the following as the contents of this file:
echo "Starting gcc build in directory: " $1 . /etc/profile cd `winpath2unix ‘$1’` make $2
You should keep your makefile in the project folder, which is D:\MySamples\ CreateThread in this case.
Now you can build your solution and the executable is put in the folder specified in the makefile.
To run the application, the usual UNIX method is used, for example:
Creating a Project for Win32/Win64 and .NET
To use Visual Studio .NET 2003 to compile your Win32/Win64 or .NET application
In Visual Studio .NET 2003, on the File menu, point to New, and then click Project. The dialog box shown in Figure 4.1 appears.
Figure 4.1. The New Project dialog box allows you to create a new solution of a particular project type.
When putting together an application in Visual Studio .NET 2003, you may have multiple projects. The set of projects together make up a solution.
The New Project dialog box allows you to create a new solution of a particular project type.
In the Project Types list in this dialog box, you can choose the type of project that you want to create. Depending on the options you select when you installed your Visual Studio environment, you can choose from a C#, C++, or Visual Basic .NET project; or possibly, a project of other programming languages. Not all of these languages for Visual Studio come from Microsoft. There are other organizations that develop applications that use .NET Framework.
In the Templates list on this screen, you can choose a default template for the type of project you want to create. There are many different templates to choose from. The project type for creating a Win32/Win64 console application is shown in the figure. Other options to create MFC or ATL applications are also available.
Before adding a new project to this solution, set the name of the project and the path where this project will reside on the hard drive of your computer. In the Location text box, enter the path where you want this project to reside. Visual Studio .NET 2003 creates the necessary path and will create a folder name with the same name as the project. The default path for Visual Studio .NET 2003 is My Documents\Visual Studio Projects. For example, if you fill in the name LoginTest and set the path to D:\MySamples, this solution will be created in D:\MySamples\LoginTest\LoginTest.sln.
Visual Studio .NET 2003 supports a variety of project template types that you can choose from based on the application requirements.
More information on Visual Studio .NET 2003 project template types is available at C# and Visual Basic .NET project template types at
More information on Visual Studio .NET 2003 project template types is available at Visual C++ project template types at
Populating the Development Environment
One problem you need to solve early in the Planning Phase is how to transfer files from one system to another. A UNIX-to-Windows migration first requires a plan for moving UNIX code to a Windows-based computer. Then you must develop a plan that identifies the portions of the code you will be interoperating and the portions of code you will be redeveloping.
This section discusses the first part— standard considerations for moving code between systems in general—and then provides guidance on populating the Visual Studio .NET 2003 environment with the source.
After obtaining the original source from the source system— as a code hierarchy, as an export from a source control system, or as an archive— the build process must also be created and configured. Some testing of the build process is possible, but testing whether the code compiles and links is part of the port or the rewrite itself.
Standard Considerations for Moving Code Between Systems
When moving source code from one platform to another, you need to first look at the general structure and location of the various files that need to be moved.
UNIX applications typically go in the /usr directory. Many UNIX administrators further segregate system programs from added user programs. Commonly, user programs are added to /usr/local, and system programs go in the /usr root.
Developers of nonsystem programs ordinarily find source code files in /usr/local on the UNIX platform. Within this directory, common directories include:
/usr/local/bin for executable files.
/usr/local/include for header files.
/usr/local/lib for library files.
Source code for user projects is usually added in a hierarchy from a directory based in /usr/local. For example, the source files for the myapp program, which is part of the mysystem application, are in /usr/local/mysystem/myapp.
On UNIX, a developer’s working source files may be in a structure similar to that described for myapp, but in the developer’s home directory instead. If the developer accesses these files from net shares by using network file system (NFS), the files may be found in a structure such as /export/home/<user name>/src/mysystem/myapp.
Windows uses different directory structures for project files. First, applications install their shared and read-only components to <drive letter>\Program Files. Windows uses a drive letter instead of the single-rooted UNIX file structure. The actual drive letter used varies according to the system configuration. A directory for the primary development tools and several directories for additional systems are usually found under C:\Program Files.
For example, if the developer needs to use development resources from the base system and an add-on service called mysystem, the developer can expect to find the base development files in C:\Program Files\mysystem and specific source files in C:\Program Files\mysystem\myapp. Under each top-level directory, the developer can expect to find a directory for binaries, header files, and libraries, such as:
C:\Program Files\mysystem\bin for binaries.
C:\Program Files\mysystem\include for header files.
C:\Program Files\mysystem\lib for libraries.
For the released (permanent) version of the source for myapp, look in C:\My Programs\mysystem\myapp. The name of the top-level directory can vary because most installation programs allow the user to customize the name of the top-level directory. However, the directory structure under the top-level installation directory may be the same.
Finally, the developer needs a space for the working myapp source files. Unlike UNIX, in Windows these files do not go under the same directory tree as the rest of the program files. In .NET, the project files belong in the area allocated for the developer's documents, for example, My Documents\Visual Studio Projects. By default, this area is C:\Documents and Settings\<user name>\My Documents\Visual Studio Projects. Therefore, look for the myapp sources under C:\Documents and Settings\<user name>\My Documents\Visual Studio Projects\mysystem\myapp.
Note When migrating files, remember that the UNIX text file format is different from the Windows text file format. In UNIX, the line-feed character (hex 0A) is used to indicate a new line. In Windows, the combination is a carriage return (hex 0D) and line feed. To determine whether this conversion is needed, open a source file in Notepad. If the source lacks the proper line feeds, a conversion is needed. A number of tools can be used for this. One of them, flip, is delivered with Interix. Depending on the target environment, Windows files may need to be converted to UNIX, or vice versa. Interix provides the flip tool for these conversions. Also if you “flip” the files, some tools may break.
For example, the following command changes a UNIX text file to a Windows text file:
% flip –m MySource.C
The following command converts startup files created using Windows Notepad to the UNIX format:
% flip -u filename
The flip tool also allows the use of wildcards.
Exporting Files from the UNIX Environment
After placing the source files in a working directory, they can be packaged together using the tar (Tape Archive) UNIX tool. The tool was named in the period when it was used for packing files together on tape libraries. Now, this tool can create a single file that represents a number of files from a common source, which makes tar useful for packing together the files of a project. Use the –c option with tar to create the archive and the -r option to add files to the archive.
A file that represents the output of tar is sometimes called a “tar ball.” After the tar ball is created, the developer can compress it using gz (GNU Zip).
Now the project is ready to copy to Windows. To do this, use one of the following methods:
Use file transfer protocol (FTP) from an FTP server.
For an FTP file transfer, be sure the session is in binary (image) transfer mode before getting the compressed archive file.
Use file copy from a file server such as Web, NFS, or server message block (SMB).
Copy from a CD-ROM drive.
A copy can start from the UNIX side or the Windows side. To copy files from one system to another, the administrator needs to allow access to both the source and target systems from the computer issuing the copy commands. When using NFS or CIFS, the remote share needs to be mounted.
Note The .gz file type is not recognized on a standard Windows installation. UNIX versions of the ZIP compression algorithm are widely available, and the .zip file type is natively recognized by Windows XP and Windows Server 2003.
Populating an Interix Environment
Importing an application’s configuration settings, build, and source files into the Interix development environment is similar to moving the application between two UNIX systems. Applications are typically compressed or uncompressed tar archive files. tar is most commonly used in tandem with an external compression tool such as gzip or bzip2.
Interix provides a program group that can start either a ksh or a csh shell because Interix integrates with the Windows environment.
To start a ksh or csh shell
Click Start, point to Programs, point to Windows Services for UNIX, and click Korn Shell.
Alternatively, point to Windows Services for UNIX, and click C Shell.
To import the application configuration settings and build and source files
Change the working directory to /usr/examples with the cd command, and then copy the compressed archive by typing the following:
** % cd /usr/examples**
** % cp /dev/fs/<Drive Letter>/** filename.tar.gz.
(The period at the end of the last line indicates the current directory.)
If the archive currently exists on a network share and the network share has been mounted to a drive letter, move the archive into the environment by typing:
% cp /dev/fs/<drive letter>/<source directory>/filename.tar.gz.
Uncompress and extract the files from the archive by typing the following:
% gunzip < filename**.tar.gz | tar xf –**
After the files are extracted from the archive, populating the Interix environment is complete.
Populating for Win32/Win64 and .NET
Using the Platform SDK or Visual Studio .NET 2003, the procedure for populating the Windows environment is almost the same as that described earlier in "Populating an Interix Environment" in this chapter. However, the intended location of the source files is similar to C:\My Programs\mysystem\myapp, depending on the name of the system and application subsystem that you are importing.
After the tar file or compressed tar file is in the Windows environment, it must be unpacked into the local Windows project area using the Windows-based version of tar. Systems that include tar include Interix, MKS NutCracker, and Cygwin. A gz archive can be opened on Windows using the WinZip archive tool.
After unpacking the source files, the text for the source file may need a minor conversion. (For more information on flip, refer to the "Standard Considerations for Moving Code Between Systems" section earlier in this chapter.)
Note In a case where large amounts of data need to be communicated over time from a UNIX environment or version control system to Windows, it will often be helpful to install Windows Services for UNIX 3.5 because it includes most of the necessary tools and is capable of storing files in the NTFS file system for subsequent use by any Windows program.
Migrating the Build Environment
This section discusses the build environments in Windows and how build environments can be migrated from UNIX to Windows. As part of setting up the development environment, the build environment is also migrated from UNIX to Windows to build the migrated applications.
Planning for migration of the build environment in the Planning Phase helps to assess and understand the existing UNIX environment. This assists in identifying the requirements and appropriate tools for building the project on the target Windows environment.
Migrating a Build Environment to Windows SDK
The Platform SDK can be used to compile and link C and C++ programs that do not include Visual Studio .NET projects. The nmake tool can be used to build make-based applications in Visual Studio. This tool is very similar to the UNIX make tool in behaviors and capabilities, with minor variations in the command-line options.
More information on the nmake tool is available at
Also refer to Chapter 3, “Planning Your Build Migration” in the Solution Guide for Migrating UNIX Build Environment.
Migrating a Build Environment to Visual Studio .NET 2003
To maintain UNIX-style code on the Windows platform, you must take into account the nature of UNIX applications and the build procedures. In UNIX, programs are compiled into object modules. The object modules can be linked into executable files or they can be used to create libraries. Libraries can either be static archives (created with ar) used to add code to executable files, or they can be shared objects. Often, the UNIX C and C++ compilers invoke the linking tools implicitly.
Windows programs are compiled with the compiler. They are linked as executable files, static libraries, or DLLs. UNIX and Windows compilation and linking are almost the same except in certain cases. The compiling and linking by cl.exe in the Windows environment and by gcc in the UNIX environment is performed in the same sequence, that is, precompilation with optimization, object generation, and creation of executables or libraries. Table 4.4 compares the UNIX and Windows methods for creating executable files, static libraries, and shared libraries.
Table 4.4. UNIX and Windows File Creation Comparison
Tool to Create
UNIX executable file
The -o option can be used to specify the output file name from the input object files. Refer to man pages of the corresponding UNIX vendor for the command options.
UNIX static library
The -r option is used to create an archive library from the given input object files. Refer to man pages of the corresponding UNIX vendor for the command options.
UNIX shared library
Windows executable file or Windows dynamic library
Link.exe can be used with the command-line option –OUT:filename, where filename is the name of the output executable. This overrides the default name of output file.
More information on Link.exe command-line options is available at
Windows static library
Lib.exe can be used with the command-line option –OUT:filename, where filename is the name of the output library. This overrides the default name of the output file.
More information on Lib.exe command-line options is available at
In .NET Framework, the source code is compiled and run using a two-step process. In the first step, the source code is compiled to Microsoft intermediate language (MSIL) code using a .NET Framework-compatible compiler, such as Visual C# .NET or Visual C++.NET. In the second step, the MSIL code is compiled to native code.
To migrate the build environment, use one of the following methods:
Manually recreate the build structure. (Refer to the "Recreating the Build Structure" section later in this chapter.)
Use batch builds in conjunction with Visual Studio .NET 2003. (Refer to the "Using Batch Builds with Visual Studio .NET 2003" later in this chapter.)
Create a custom tool to manage projects and builds. (Refer to the "Creating a Custom Tool" section later in this chapter.)
Migrating the build environment essentially includes migrating the makefile from the UNIX environment to the Windows environment. Project makefiles consist of a set of commands to build the project executable or library from the input source file with the given compiler options and the dependent libraries. Each method starts with the UNIX makefile, so the first step is to look at the project makefiles to see what information needs to be migrated. You can use the make with -n switch to run the makefile without actually executing the commands in the makefile. This helps in finding the issues with actual files and sequences of events and tools involved in the makefile commands.
Look at the setting and configurations first. To do so, use a makefile to create dependencies and rules that generate the makefile target, usually the linked binary, such as an executable file. In addition to rules and dependencies, macros can be created to represent variables and options for each function and the corresponding directory locations. Table 4.5 lists common examples of macros in a makefile.
Table 4.5. Makefile Macro Examples
An alias for the C and C++ compiler.
The C compiler option setting.
The C++ compiler settings.
Linker option flags.
The directory path for header files.
Libraries to include at link time.
The UNIX variables, environment variables, or the variables defined in the makefiles CFLAGS, LDFLAGS, LIB, and INCLUDE yield the main information required to create a Visual Studio project on Windows or to create an nmake file on Windows for a batch build. Makefiles can be viewed by using a UNIX text editor, such as vi. Options can also be extracted by using UNIX text tools, such as grep or awk. In the following example**,** grep finds the text pattern CFLAGS in the file mymake:
% grep CFLAGS mymake
Dependency rules can also be expressed in the makefile. Table 4.6 lists these dependency rules.
Table 4.6. Makefile Dependency Rules
Target is out of date, depending on the source.
Target is repeated as sources are examined.
Target is accumulated.
A special type of dependency can be expressed by inference rules. Using these rules, target dependencies can be grouped together by common attributes. For example, a .SUFFIXES rule allows files with a common file extension to have the same dependencies.
Recreating the Build Structure
Often, for small to medium-sized applications, the easiest way to migrate the project is to create the Visual Studio project manually. Because of their smaller size, this technique is useful for prototype applications. It is especially suited to applications that have dependencies on only a single file tree, with all the sources under a single starting directory.
Larger projects may require another scheme because they have a greater number of source files and the UNIX build procedure is more complex. A long-term migration goal may be to standardize on the Visual Studio .NET tools. When all applications, including the largest ones, are considered, manually creating and maintaining the Visual Studio projects is the best solution.
Converting an Application Build from a Makefile-based to a Visual Studio-based Project
Rogue Wave SourcePro, a third-party product that provides cross-platform C++ development components, uses a makefile-based build model on all platforms. Therefore, it provides a good example of manually migrating a makefile-based project to a Visual Studio project.
To convert an application from a makefile-based build to a Visual Studio-based project, you must ensure that the flags passed to the compiler are the same, the necessary #defines are the same, and the required header file and library file paths are properly set in the Visual Studio .NET 2003 environment. Because the UNIX makefiles use shell scripting, all the shell commands need translation to the nmake syntax.
Note Additional information on NMAKE references is available at
One way to obtain this information is to run make from a command line on the original UNIX environment and redirect the output to a file, for example, the following command from the command line:
$ make –f project.mak > exampleBuild.txt
The preceding make command places the output of the compile and links it to the exampleBuild.txt file; then you need to move the makefile to the Windows environment and start making the necessary changes in that makefile.
After you have addressed these issues, you can continue development in the Visual Studio environment. The following is a general step-by-step guide to the process.
To convert a UNIX-based application to Microsoft Visual Studio .NET 2003 project
Copy the source and header files from UNIX to the Windows folder.
Create the Win32 empty console project with the same application name as on the UNIX folder specified previously.
Add the source code files to the project.
Add all the include directories from the INCLUDE environment variable or the makefile variable or –I option in the UNIX makefile to the Project include directories. To add the new directory to the Visual Studio .NET 2003 environment, on the Tools menu, click Options, select Projects folder, then click VC++ Directories, select the Platform and Show Directories for as Include files. Then click in the last row in the following list box, and edit or browse the new directory of include files. The dialog box shown in Figure 4.2 appears.
Figure 4.2. The Options dialog box allows you to set the Include files path.
Add all the Library directories from LD_LIBRARY_PATH environment or LIB or LIBRARY variables on UNIX makefiles to the project library directories To do this, on the Tools menu, click Options, select Projects folder, then click VC++ Directories, select the Platform and Show Directories for as Library files. Then click in the last row in the following list box, and edit or browse the new directory of Library files.
Add the preprocessor definitions added to the UNIX makefile to Visual Studio project. To do this, on the Project menu, click Settings, select Configuration Properties folder and then C++ folder, select the Configuration as All Configurations, and add to Preprocessor definitions.
If any other compilation options are specified in the makefile, add them to the project. To do this, on the Project menu, click Settings, select Configuration Properties folder and then C++ folder, select the Configuration as All Configurations, and add the appropriate compiler options to the additional option in the Command line tab.
To add additional libraries, identify the library names from the UNIX makefile and add them to Visual Studio .NET 2003 environment. To do this, on the Project menu, click Settings, select Configuration Properties folder and then Linker folder, and then click Input and add the library names to Additional Dependencies. You can also update the Output file in General tab.
To add any pre-build and post-build script execution, on the Project menu, click Settings, select Configuration Properties folder and then Build Events folder. Select the Configuration as All Configurations, and add the corresponding commands to execute in select Pre-build step, Pre-link step, or Post-build step of Build Events folder. This is generally used to copy the include files, library files, or output files to the specified folder after the build.
To specify the command-line arguments for your program, on the Project menu, click Settings, select Configuration Properties folder, and select the Configuration as All Configurations, select the Debugging folder, and add command-line arguments to Command Arguments.
Compile the project. If you receive error messages about conflicting compiler options, it means that the options cited in the error message were not found in the application. Remove any options that are not found and compile again.
The following steps describe an example application for converting to Microsoft Visual Studio project.
To convert a console-based UNIX example application to a Microsoft Visual Studio .NET 2003 project
Start Visual Studio .NET 2003. On the File menu, point to New, and then click Project.
On the Project Types list in the New Project dialog box, click Visual C++ Projects. Click Win32, and select Win32 Console Project as the Template.
Copy all of the source code files from the example application folder to the project folder.
Under FileView (on the left side of the screen), right-click Source Files, click Add files to folder, and select all of the .cpp files copied to the project folder.
Repeat step 4 for Header Files and add all the header files in the project folder.
On the Project menu, click Properties, select Configuration Properties folder, and select the Configuration as All Configurations, and then click the C++ folder. At the bottom of the dialog box, you will find a text field for Project Options. Find and copy the compile options that were used in the application example. The following steps will guide you through the process:
Convert -I<anything> to /I "<anything>". If a relative path is used in the application, you need to convert it to an absolute path.
Convert -D<anything> to /D "<anything>".
Convert -GX to /GX.
For other compiler options, identify the equivalent compiler options in Visual Studio .NET 2003 IDE. On the Project menu, click Settings, select Configuration Properties folder and then C/C++ folder and select the equivalent options.
Note More information on C/C++ compiler options in Visual Studio .NET 2003 IDE is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_asug_specifying_project_configuration_settings.asp.
On the Project menu, click Properties, select Configuration Properties folder and then Linker folder, and then click Input and add the library names. Use the following guidelines:
Find an -L<anything> from the example application, and copy it to Additional library path by entering <anything>.
Find the list of all libraries used in the example application, and copy the library names under Additional Dependencies. Remove any preexisting library names.
Compile the project. If you receive error messages about conflicting compiler options, it means that the options cited in the error message were not found in the example application. Remove any options that are not found.
Using Batch Builds with Visual Studio .NET 2003
Creating a Windows nmake file is similar to creating a Visual Studio project. However, creating a Windows makefile is different. When the Visual Studio .NET 2003 IDE creates a project, it automatically generates contents required to build an application at runtime by reading the project file. Although a batch build system can manage both the build process and the dependencies for a source code base with hundreds or thousands of files, in such a system it is often difficult to debug a single suspected problem file.
Managing Cross-Platform Builds
During a migration, some applications may still need to be maintained and built on UNIX. These cases require a cross-platform development and build strategy.
When building an application on multiple platforms, follow these guidelines:
Choose one platform as the main development platform.
Identify and segregate platform-specific code that cannot be easily maintained with compiler directives (#ifdef). It is easier to maintain such code separately for each platform if it is separated into callable modules.
Keep platform-specific code local to its target platform.
Look for libraries that already offer cross-platform support, such as most C run-time libraries and OpenGL cross-platform libraries.
Migrate source to multiple platforms with each release instead of synchronizing source across multiple platforms, that is, migrate the entire code to multiple platforms with each release, instead of synchronizing the changes in the source code from one platform to another platform.
Use batch builds on each platform. An automated process can usually be used to move a batch build from one platform to another.
Consider using a cross-platform build tool, such as GNU make.
Ultimately, the effort exerted to create and maintain a cross-platform build environment depends on how often the changes to an application in one platform need to be migrated to another. A quicker migration process may take less effort than a cross-platform build process.
Setting Up the Test Environment
Testing is the process of determining the differences between the expected results and the observed results of the migrated application. The output of the parent application and the output of the migrated application should be compared to ensure the success of the migrated application. A working test environment allows the solution to be properly tested so that it will have no negative impact on production systems.
Note It is generally a good idea to set up separate test servers that the testers can use. The entire team should be informed that anything on such servers could become unstable and require reinstallation.
When you set up the test environment, you replicate the live environment of the application on the test system. The actual setting up the test environment depends upon the application type. Setting up the test environment involves the following steps:
Gathering testing requirements. This stage is essentially part of planning the migration project. In this stage, the user gathers the testing requirement with the following considerations:
Scope of testing.
Entry and exit criteria.
Key stakeholders in testing phase.
Test requirements from requirements specifications and design documents.
Planned number of test cycles.
Planned test coverage.
Testing tools and automation strategy.
Test case planning and execution. This stage defines the types of test cases for different types of testing, such as unit testing, integration testing, functionality testing, system testing, and user acceptance testing. This step also involves logging defects and usage of defect tracking tools.
Infrastructure. This stage defines a strategy for infrastructure planning like network configuration, installation of the necessary software, setting up hardware requirements, and installation of the application-specific test data.
User environment. This stage defines a strategy to understand the user-specific application configuration settings and migration of the settings to the test environment. This involves language support and browser setting in the case of Web applications.
Interoperability. This stage defines the minimal changes required to use the application-specific data files and the configuration file across the UNIX and Windows platforms. It ensures interoperability and decreases the complication of files and data conversion across the platform.
Functionality. This stage defines a strategy for the functional testing of the migrated applications, executing the test cases in the test environment, and evaluating the test results.
Security. This stage defines a strategy to allow authorized users to use the applicable features of the application. This includes defining the user-specific security settings, application-specific security settings, computer-specific security settings, and network and other common resource-level security settings.
Performance. This stage defines benchmarks for performance of the migrated applications using the existing benchmarks on the UNIX environment.
Setting Up the Staging Environment
The staging environment is where the team tests content and code being changed or deployed to ensure that they function as expected. The content and code are moved from the test environment to the staging environment before they are published to the production environment. Solution components successfully tested in the development/test environment may not necessarily work after all elements are in place and have been integrated. The staging environment provides a place to test code with all solution elements to make sure it works before it is put into production.
Hardware and software installed in the staging environment should mimic the production environment as closely as possible. Depending upon the availability of hardware resources, an individual server can perform several different server roles in the staging environment. However, it should be recognized that all deviations from the production environment detract from the representative value of testing and should therefore be clearly known, understood, and agreed upon and tracked. Ideally, the staging servers are built according to the documented server build procedures that have been developed. This ensures that testing accurately portrays what will be seen in production.
The staging environment attempts to simulate the target environment. The simulation may be achieved through the use of synthetic load generation or other custom or commercial tools. When the staging environment is different from the target environment to a significant degree (typically, in terms of size or capacity), or when project constraints do not support the construction of a staging environment, some testing must occur in the deployment environment. Such testing must be closely coordinated with the operations staff for that environment.
The instructions for setting up the staging environment is similar to the instruction provided for setting the up the test environment in the earlier section.
Interim Milestone: Development and Test Environment Setup
At this point, the team has the necessary settings in place to enable the work of building and stabilizing the solution. With the environment setup completed, the teams can now begin shifting their focus entirely to development work involved in migrating.
Key Milestone: Project Plans Approved
At the Project Plans Approved Milestone, the project team and key project stakeholders agree that interim milestones have been met, that due dates are realistic, that project roles and responsibilities are well defined, and that mechanisms are in place for addressing areas of project risk. The functional specifications, master project plan, and master project schedule provide the basis for making future trade-off decisions.
After the team approves the specifications, plans, and schedules, the documents become the project baseline. The baseline takes into account the various decisions that are reached by consensus by applying the three project planning variables: resources, schedule, and features. After the baseline is completed and approved, the team moves to the Developing Phase.
After the team defines a baseline, it is placed under change control. This does not mean that all decisions reached in the Planning Phase are final. But it does mean that as work progresses in the Developing Phase, the team should review and approve any suggested changes to the baseline.
After the closure of the Planning Phase, the team shifts its focus to the build solution components, following instructions to migrate the UNIX code to the Windows environment. The details of the development activities are described in the next build volumes (Volume 2, Volume 3, and Volume 4) of this guide.