Team development with Visual Studio.net and Visual SourceSafe
Team development using Visual Studio.net and Visual SourceSafe
Buildit: Automatic Generation Tool for Visual Studio .NET
Michael Monteiro
Sapient Corporation
February 2003
Summary: Buildit is a Microsoft_ .NET console application that automatically performs the generation process overview in the "Team Development with Visual Studio .Net and Visual SourceSafe" in MSDN_ Library. Buildit is designed, developed and tested by Sapient Corporation, and reviews Microsoft (including team members of Microsoft Patterns & Practices and Visual Studio_.net development systems). (28 page prints)
Use buildit:
• Eliminate the time required to create, test, and maintain custom build scripts. • Make more reproducibility and consistency of the group's generation process.
Buildit is designed to start development .NET distributed application. The downloadable program provides a complete source code and a comprehensive document for Microsoft Visual C # _ development tools and Microsoft Visual Basic_ .NET development systems.
Note Buildit currently supports buildings with some installation projects, which are developed with Visual Basic .NET, Visual C # and Visual Studio .NET. It has not been tested for items written in other .NET language or other installation items (for example, Wise or InstallShield installation items).
Although Buildit has passed the test and review and is considered a reliable code set, the code and documents are available as "original", you can use and expand them.
This article includes the following sections:
• Download and Install Buildit • Test installation • User Guide • Deployment and Run • Known Issues • Design and Implementation • Class reference • FAQ • Small knot
Download and install Buildit
Click here to download Buildit.
The installation process will create a Microsoft Application Blocks for .NET submenu in your Programs menu. On the Microsoft Application Blocks for .NET submenu, there is a Sapient Buildit submenu, which includes options for launching the Buildit Visual Studio .NET solution.
Test installation
The following steps can be used to create two sample solutions in Program Files / Buildit / Code / BuilditTest, which help to confirm whether Buildit is running normally.
Add a project to source management
• In the Visual SourceSafe_ (VSS) version control system, create a new project called BuilditTest. • Set the $ / buildittest's work folder to Program Files / Buildit / Code / Buildittest. • Add assembly versions to VSS:
• Add Program Files / Buildit / Code / BuilditTest / askILYVERSIONFO.CS to $ / Buildittest. • Repeat the above operations for AssemblyVersionInfo.vb. • Create a virtual directory for the web project (Project2):
• Browse to Program Files / Buildit / Code / Buildittest / Solution2 / Project 2. • Right-click Project 2 and click Properties. • Click the Web Sharing tab, and then click Share this Folder. • Accept the default alias and click OK to close the Edit Alias dialog. • Click OK to close the Properties dialog. • Add solutions to VSS: =
• Open program files / buildit / code / buildittest / soln. • Right-click Solution1 in "Solution Explorer", then click Add Solution To Source Control. • Browse to $ / BuilditTest, and then click OK (click Yes "to create a VSS project). • If the system prompts to "Item 1" specified location, browse to $ / BuilditTest / Solution1, and then click OK. • For SOLUTION2, repeat steps A to D. • share the assembly version file in VSS:
• Share $ / buildittest / askEMBLYVERSIONFO.CS to $ / BuilditTest / Solution1 / "Item 1". • Share $ / buildittest / askEMBLYVERSIONFO.VB to $ / BuilditTest / Solution2 / Project 2. • Add assembly versions to your project
• Add asSemblyversionInfo.cs to Project1 in Solution1:
• Open program files / buildit / code / buildittest / soln. • In the Solution Explorer, right-click Project 1, point to Add, and then click Add Existing Item. • Browse to Program Files / Buildit / Code / BuilditTest / Solution1 / Project1 / askEMBLERSIONINFO.CS, then click Open. • In the Check Out for Edit dialog box, click Check Out to check out Project1.csproj. • Open AssemblyVersionInfo.cs and note the version number (1.0.0. *). • Press CTRL SHIFT B to generate a solution. • Right-click Project 1 in "Solution Explorer", then click Check IN NOW (Recursive). • To add AssemblyVersionInfo.vb to Project2 in Solution 2, repeat steps A to G. • Update Configuration Settings:
• Open program files / buildit / code / buildittest / buildit.exe.config. • Update SourceControl settings. • Deploy Buildit:
• Open program files / buildit / code / buildit.sln. • Press CTRL SHIFT B to generate a solution (make sure to generate a Release version). • Copy the .exe file and all .dll files from Program Files / Buildit / Code / Buildit / Bin / Release / Buildit / Code / Buildittest. • Execute Buildit and verify: • Open Program files / buildit / code / buildittest / buildNumber.xml and pay attention to the next internal version number is 1. • Open Program Files / Buildit / Code / BuilditTest / Buildit.bat to check the buildit command line. • Run Buildit.bat to generate a solution. • Open Program Files / Buildit / Code / BuilditTest / Buildit.log to see if there is an error. • Open Program Files / Buildit / Code / BuilditTest / BuildReport.log to check the result of the generated. • Open BuildNumber.xml and note that the next internal version number has been incremented to 2. • Open AssemblyVersionInfo.cs and assemblyVersioninfo.vb, and pay attention to the version number has been 1.0.0. * Updated to 1.0.1. *. • Browse to Program Files / Buildit / Code / BuilditTest / Archive / 1 to see if the generated assembly has been archived to folders named in the internal version number. • Browse to Program Files / Buildit / Code / BuilditTest / Latest to see if the generated assembly has been copied to the Latest folder. • Display a history of $ / buildittest to see if the VSS project has been tagged with the internal version number.
User Guide
The following topics provide more information about using Buildit:
• Maintain internal version number • Generate Solution • Check Generate Report • Regeneration Solution • Archive to Generate • Send Generate Sage with Email • Configure the version of the configuration assembly
Maintain internal version number
Buildit uses internal version numbers to mark solutions (managed to manage the solution in VSS) and update the assembly version number (if the corresponding generated option is enabled). At the end of each successful generation, Buildit generates a new internal version number by increasing the existing internal version number (if the generation fails, the internal version number does not increase). The new internal version number is then saved in an XML file, the name and location of the file are defined by the buildNumberFilePath property included in the buildit.exe.config file.
The following example shows the contents of the internal version number XML file called buildNumber.xml.
Note Before running Buildit, you must create an internal version number XML file and initialize it with the starting internal version number. Also note that the internal version number must be a positive integer.
Solution
Buildit can be configured to generate a single solution or multiple solutions. For multi-solution systems that include cross-solution files, the solution must be listed in the correct order. For example, if Solution2 depends on Solution1, column Solution1 is listed in front of Solution 2, which ensures that Solution1 is first.
The following example comes from buildit.exe.config, which shows how to configure this generated tool to generate multi-solution systems: BuildNumberfilePath = "c: /system/buildnumber.xml"> Check generation report At each generation, Buildit generates a generated report called BuildReport.log in the work folder. Generating a report can be viewed with any text editor. Generating reports contains a list of summary information and successful and failure solutions. If any solution is unable to generate, you can use the Visual Studio .NET to generate these solutions to identify the exact cause of its failure. ================================================================================= Build Report Generated by Buildit ================================================================================= Build Number: 8016 Build Start: 9/12/2002 6:50:09 PM Build end: 9/12/2002 6:50:43 PM Build Duration: 1 minute (s) Archive Folder: C: C: / System / Archive / 8016 / Latest Folder: C: C: / System / Latest / Build Results: 1 succeeded, 0 failed ================================================================================= Succeeded ================================================================================= C: /system/solution1/solution1.sln ================================================================================= Failed ================================================================================= Regeneration solution If an interrupt occurs during the generation, Rebuild is required. The following steps must be completed until the solution is regenerated. Regenerated after generating interrupts • 1. If you need to change the code at the time of repair, you can manually check the required files from the VSS to the generated computer. • Note that the VSS credentials specified in the configuration file of the generated tool are used when checking the file. This helps to identify files modified in order to fix interrupts. • 2. Perform code changes, use Visual Studio .NET to recompile, and then test the reconscribed file. • 3. After the problem is resolved, check into the modified file. • 4. The label generated during the previous generation process manually updates the label of each check-in file, as shown below: • a. Right click on the file name, and then click Show History. • b. In the History Options dialog box, click OK. • c. Click the version of the file you want to update the label, and then click Details. • d. Update the Label field with the label used during the generation process (eg, "Build 100"). • 5. Manually run Buildit with / Rebuild option. Archive According to the instructions in the "Consider Maintaining Previous Builds" section under MSDN Library, you can configure buildit to archive the previous generation results to the specified location. When the ArchiveBuild generation option is enabled, the generated tool copies the generated assembly to a folder named in the current internal version number, which is located under the archive root folder specified by the ArchiveRootFolderFullName property in the configuration file. By default, Buildit is only archived for outputs generated from Visual C # and Visual Basic .NET projects. To archive the output result generated from other items (for example, Visual Studio .NET installation items, add the Folder element to the AdditionAlFoldersToarchive element. The following example comes from buildit.exe.config, which shows how to enable this option. Destfoldername = "debug / setup1" /> DestFoldername = "release / setup1" /> Send generation results via email In the "Emailing Build Results" section under "Team Development with Visual Studio .Net and Visual SourceSafe", you can configure Buildit to send generated results to the specified email address by email. When the SendBuildReport generation option is enabled, the generated tool will generate an email message that contains the generation report named BuildReport.log, sent to the email address specified by the toadDress property. The following example comes from buildit.exe.config, which shows how to enable this option: Toaddress = "You@yourcompany.com" /> Configure the version of the assembly BUILDIT is configured as a version stored in the current internal version number update assembly stored in the XML file stored by the BuildNumberFilePath property: The version of the assembly is usually specified in the AssemblyVersion property (this property is defined in AssemblyInfo.cs or AssemblyInfo.vb files). However, when the generating tool is configured to update the assembly, the AssemblyVersion property should be defined in a separate file (for example, asmblyversioninfo.cs or assemblyversioninfo.vb), this file is in VSS spanning all .NET Sharing between projects. This allows Buildit to update a file and pass the changes to all items in the solution. For more information, see the "Consider Centralizing Assembly Version Numbers section" Team Development with Visual Studio .Net and Visual SourceSafe "section. Note that two sample files called AssemblyVersionInfo.cs and AssemblyVersionInfo.vb are copied to the buildittest directory when installing Buildit. The version number is represented by the physical form as a four-segment number separated by a sentence, as shown in the following code example. The following example comes from buildit.exe.config, which shows how to enable this option. CSASSEMBLYVERSIONVSSPATH = "$ / system / askEVERSIONFO.CS" VBassemblyVersionVssPath = "$ / system / assemblyversioninfo.vb" /> Deployment and operation This part includes the following management topics: • Deploy Buildit • Configuring Buildit • Protecting Buildit • Troubleshoot Buildit Deploy buildit The identifiable depends is important when deploying any application. Buildit (as a single-way set name called Buildit.exe) has the following dependencies: • Buildit.exe.config (configure setting) • BuildNumber.xml (for maintenance of the next internal version number) • Note the name and location of the internal version number XML file is defined by the buildNumberFilePath property in the buildit.exe.config file. . Also note that before running Buildit, you must create and initialize the internal version number XML file with the start-up internal version number. For more information, see the "Maintaining the Internal Version Number" section. • Microsoft.ApplicationBlocks.ExceptionManagent.dll and Microsoft.ApplicationBlock.ExceptionManagent.Interfaces.dll (for exception management) • Interop.SourceSafeTypeLib.dll (for the VSS API (SSAPI.dll) interoperability) • Visual SourceSafe 6.0c Client Program (for accessing remote VSS database) • Visual Studio .NET (for generating .NET solution) This information can be used to select the deployment method according to the needs of the deployment team. For Buildit, you can consider two deployment methods: XCOPY deployment or Windows installer deployment. These options are described in more detail below. Deployment with XCOPY Deploying Buildit is the most convenient way; however, it requires more knowledge that the tools are required to deploy the tool. To deploy this method, use Xcopy to copy the necessary assemblies and application profiles (Buildit.exe.config) to the directory on the target computer. The EXCEPTIONMANAGERINSTALLER class is then called using the Installutil.exe System utility to create the default exception publisse to write the event source required to write this class to the Windows event log. For example, using the following command line: Installutil.exe Microsoft.ApplicationBlocks.ExceptionManagement.dll For more information on the Exception Management Application Block, see "Microsoft Application Blocks for .Net" in MSDN Library. Deploy with Windows installer Deploying Buildit with a Windows installer requires a pre-executed job than to deploy a xcopy, but for those who deploy the tool, the knowledge is less. To deploy using the Visual Studio.net installation project and deployment items, add your build, Exception Management, and Exception Management Interfaces items to the application folder and buildit.exe.config files. Then, add an exception management item output in a custom operation, which ensures that the ExceptionManagerInstaller class is instantiated when installing. Configure buildit The behavior of the generating tool is controlled using an application profile. The application profile is an XML-based document that is stored in the root directory of the application folder hierarchy. The name of the application configuration file is used. Application extension .config form. For the generated tool, the name of the application configuration file is buildit.exe.config. This part includes the following topics about configuring Buildit: • Settings Generate Options • Configuring Tracking • Configuring Exceptions • Run multiple versions of Visual Studio .NET Note that changes made after modifying the configuration file, will take effect after building Buildit. Set the generation option You can enable or disable any generation options by setting the MODE property of the generation option to ON / OFF, as shown in the following code example: Toaddress = "You@company.com" /> Note that if the mode properties are ignored or its value is not ON / OFF, it will cause an exception. Also pay attention to the value of the mode attribute is not case sensitive. Configuration tracking Buildit uses the Trace class in the System.Diagnostics namespace to generate the tracking output to a file named Buildit.log in the console and working directory. Below is an example of tracking output. Validating Command-Line Arguments Reading Buildit Settings from Configuration File Starting Build 100 AT 11/1/2002 1:57:53 PM Updating assembly version file $ / system / askEMBLYVERSIONICO.CS Labelling Source Getting Source from label Backing Up Latest Folder Building Debug Version of Solution C: /system/sln1/solution1.sln Building Release Version of Solution C: /system/sln1/solution1.sln Building Debug Version of Solution C: /system/sln2/solution2.sln Building Release Version of Solution C: /system/sln2/solution2.sln 2 Solution (s) succeeded, 0 failed Deleting Latest Backup FolderChiving Additional Folders Generating build report Not sending build report because the Option WAS NOT ENABED Ending build at 11/1/2002 1:58:40 PM - 0 minute (s) to completion You can use TraceLevel's TraceSwitch to enable and disable tracking using traceLevel in the buildit.exe.config file. Tracking can be enabled by setting the TraceSwitch to 0 to disable tracking. Set the TraceSwitch to 4 to enable more detailed tracking output (detailed mode). The following code example shows how to enable tracking. In addition, Buildit can be configured to append the tracking output to the trace file (if there is a tracking file), or can be configured to overwrite the tracking file. The suggested setting is to overwrite the trace file to prevent it too much. The following code example shows how this setting is made. Note If the appendtraceoutput item is ignored, Buildit will override the tracking file by default. Configuring exception management Buildit uses Microsoft's Exception Management Application Block, you can configure the application block using XML settings in the configuration file. If these settings are ignored, Exception Management Application Block will publish exceptions to the application log by default. However, you can specify another release program. When writing this article, the configuration file does not contain the Exception Management setting. Therefore, all exceptions are published in the application log that can be viewed using the Event Viewer. For more information, see "Exception Management Application Block overview" Exception Management Application Block overview in MSDN Library. Use Visual Studio .NET running multiple versions By default, Buildit uses the latest installed Visual Studio .NET version to generate a solution. However, if multiple versions are installed on the same computer, the developers may wish Buildit to use a particular version. To force Buildit to use a specific version of Visual Studio .NET, include the VisualStudioProgid item in the appSettings section of the configuration file. The following code example shows how to do this. Note If the VisualStudioProgid item is ignored, Buildit will use the latest Visual Studio .NET version by default. Protect buildit As with all applications, you must ensure that all sensitive data and resources are not subject to unauthorized access. For buildit, mainly consider the following two aspects: • Prevent the application profile from authoring access • Access required for Buildit Prevent unauthorized access to the configuration file Because the configuration file of the generating tool contains sensitive data (eg, VSS usernames and passwords), it should be ensured that only authorized users can view or change these settings. Profiles can be protected by using Windows NTFS file permissions. Access required by Buildit Buildit uses Microsoft's Exception Management Application Block to publish exceptions to the event log. In addition, Buildit also reads / write file systems. Therefore, it is necessary to ensure that the security principles used by Buildit have appropriate permissions to perform these operations. Troubleshoot Buildit Two mechanisms can be used to help developers troubleshoot the generating tool: tracking and exception management. When tracing is enabled, Buildit generates a trace file called Buildit.log in the work folder, which can be used to determine the steps that the generated tool has executed. This is very useful when trying to determine why this generating tool is not running as expected. When an exception occurs, Buildit uses Microsoft's Exception Management Application Block (Exception Management Application Block) to publish exceptions to the application log. Developers can then use the Event Viewer to see more details about exceptions. Combined with these two mechanisms can provide information to troubleshoot the generating tool. Question Buildit is very effective in most cases, but in a few cases, it has some known issues. Table 1 lists the known issues of Buildit. Table 1: Knowledge of Buildit Problem Description Solution Buildit will cause errors when generating two or more items. An error occurs when Buildit attempts to copy the project output (if the output already exists) to the Latest folder. If Buildit encounters two identified items, even if they reside in different solutions, the above errors will occur. If Buildit encounters the same solution again during the single operation of the tool, the above problem will also occur. Make sure the names of all items remain unique throughout the system and make sure the app.config file does not contain duplicate solution items. The Set Project Location dialog will appear during the generation process. The SET Project Location dialog box appears during the generation, prompting the user to set the location for the Work Copy of the web project. This dialog box appears when trying to load a Web project that is not mapped to the corresponding virtual directory. To prevent this dialog in the process of running Buildit, ensure that all Web projects are mapped to the virtual directory before running Buildit. A convenient check method is manually opened each solution in Visual Studio .NET before running Buildit. If the dialog box occurs when running Buildit, simply responds to the dialog box by setting the location of the WEB project. Visual Studio .NET will then create a virtual directory. Design and implementation This part includes the following design and implementation topics: • Problem Description • Design Goals • Solutions • Enhancements Question description Buildit is designed to resolve the following questions: • Developers spend valuable development time on creating, testing, and maintaining custom build scripts, but these scripts usually cannot reuse in different projects. • The developer's time is usually tight, which makes them rarely test and record their build scripts. Design goals Buildit's design goals are: • The solution must follow the steps outlined in the "Team Development WITH VISUAL Studio .Net and Visual Sourcesafe" in MSDN Library. • The solution must be recorded and easy to use. • The solution must be flexible; it should be able to reconfigure without re-encoding and recompiling. • The solution must be reliable; it must handle any exceptions that occur during the generation process. Solution description Buildit is a console application consisting of many classes that work together to automatically perform the generated process. E.g: • Verify the command line option, retrieve the build tool settings via the BuilditsectionHandler and start the generation process through the BuildManager. • Retrieve settings from the configuration file of the tool. These settings are used to modify runtime behavior. • Combined generation process. • Open the VSS operation (for example, check in and check out) during the generation process. • Provide type security access to the error message stored in the resource file. • Encapsulate the command line parameters supported by Buildit. Logic flows as follows: • Start Buildit with the appropriate command line parameters. • MAIN1 class calls the "Start" method of the BuildInitializer class. • The BuildInitializer class verifies the command line parameters and then retrieves settings from the tool profile from the tool using the BuilditsectionHandler class. BuilditsectionHandler returns settings through the type of security named BuilditSettings. • BuildInitializer Creates an instance of buildManager and passes the buildsettings structure to the constructor. • BuildInitializer then calls Build for buildManager to initiate the generation or regeneration process indicated by the command line parameter. Profile settings The buildit configuration file called Buildit.exe.config is included in the runtime. This allows the behavior of the tool to be modified without re-compiling the solution. The settings in the file pointed out: • The generated solution. • Connect to the information you need to specify the VSS database. • Do you use an internal version number to update an assembly version. • Whether to archive the previously generated assembly to the specified location. • Whether to send the generation results to the specified email address via email. Note If any settings are missing or incorrectly, Buildit will trigger an exception unless there is another declaration in this article. The following code example displays the format of the configuration file settings. TYPE = "Sapient.framework.tools.buildit.builditsectionhandler, Buildit "/> InIfilePath = "C: / Program Files / Microsoft Visual Studio / VSS / Srcsafe.ini" Srcvssrootfolder = "$ / system" srcfileroTfolder = "C: / system" /> BuildNumberfilePath = "c: /system/buildnumber.xml"> Toaddress = "You@yourcompany.com" /> ArchiveroTfolderfullname = "C: / System / Archive"> Destfoldername = "debug / setup1" /> DestFoldername = "release / setup1" /> VBassemblyVersionVssPath = "$ / system / askMBLYVESIONFO.VB" CSASSEMBLYVERSIONVSSPATH = "$ / system / askMBLYVERSIONFO.CS" /> Configsections elements The ConfigSections element is used to connect a segment of the configuration file to a configuration section processing program class. The section element in the above code is used to connect the buildit section to the BuilditsectionHandler class in the Sapient.framework.Tools.Buildit namespace. Appsettings element Appsettings elements include applications specific settings that can be represented as item-value. Currently, Buildit defines three specific settings: • AppendTraceOutput. When this setting is ON, Buildit adds the tracking output to a trace file named Builtit.log. Note If this item is ignored, or if this value is not set to ON, Buildit will override the tracking file. • EnableCustomMessageFilter. When this setting is ON, Buildit will enable a custom message filter to process the COM message to be sent when the response waiting for synchronization calls. After implementing this filter, you can retry the call to Visual Studio .NET Automation when the object is busy. If Visual Studio .NET automation is very busy, and this filter is not enabled, it will lead to exceptions. Note If this item is ignored, or if this value is not set to ON, Buildit does not enable message filters. • VisualstudioProgid. If the value of this item is set to ProgID, it will force Builtit to use a specific version of Visual Studio .NET when generating a solution. Note If this item is ignored, Buildit will use the latest installed Visual Studio .NET version. SourceControl element The SourceControl element includes information about the VSS database used during the generation. This element has the following properties: • Username. The name of the VSS user used to log in to the database. • Password. VSS user's password. • InIfilePath. The VSS .ini file path used to find the database (for example, C: / Program Files / Microsoft Visual Studio / VSS / Srcsafe.ini). • Srcvssrootfolder. A VSS root folder (for example, $ / system) that is being generated source code. Buildit performs GET recursive operations from this VSS project • SrcfileroTfolder. A file system root folder (for example, C: / System) in which source code is generated. Buildit will copy the file obtained by the GET recursive operation to this directory. Solutions elements Solutions elements include information about the generated solution. This element has the following properties: • LateStrootfolderFullName. The name of the root folder (for example, C: / System) containing the latest generated assembly after the generation is generated. For more information, see "Copying Output to the Latest Folder" in the "Team Development With Visual Studio .Net and Visual Sourcesafe" in MSDN Library. "Team Development with Visual Studio .NET and Visual SourceSafe" a text of the statement note that the MSDN Library "single solution or partitioned-single solution systems do not require a Latest folder because you use project references rather than file references to refer to assemblies" (single Solutions or partition Single Solutions The system does not require a Latest folder, which is due to project references when referenced, without using file references). However, because the single solution system can become multi-solution system, Buildit always copies the generated output to the Latest folder. This allows developers to use file references when referenced from another program set generated from another solution. • BuildNumberFilePath. The XML file used to generate the next internal version number (for example, c: /system/buildnumber.xml). For more information, see "Generating Building Numbers" in the "Team Development with Visual Studio .Net and Visual Sourcesafe" in MSDN Library. Note "Team Development with Visual Studio .Net and Visual Sourcesafe" does not point out the way the internal version number is generated. At the end of each successful generation, buildit generates an internal version number by adding an internal version number stored in the specified XML file. Successful generation refers to the generation that does not contain any generated errors. Solution element Solution elements include information about specific solutions. This element has an attribute: • path. The generated solution file (eg, C: /System/Solution1/Solution1.sln). Options element The Options element contains sub-elements corresponding to each generated option. Each generation option is represented by a different element. Sendbuildreport elements SendBuildReport elements control Whether to send the generated report to the specified email address when generating the completion. For more information, see the "Email Build Results" section under "Team Development with Visual Studio .Net and Visual SourceSafe" in MSDN Library. This element contains the following properties: • Mode. If this property is set to "ON", Buildit will send the generated report to the specified email address. • SMTPSERVER. The IP address of the SMTP server used to forward an email. • Toaddress. The email address used to receive the generated report. ArchiveBuild Elements Control Whether to archive the generated assembly to folders named in the internal version number. For more information, see "Consider Maintaining Previous Builds" in "Team Development with Visual Studio .Net and Visual SourceSafe" in MSDN Library. This element contains the following properties: • Mode. If this property is set to "on", Buildit will copy the generated assembly to a folder named in the internal version number. • ArchiveRootfolderFullName. Contains the name of the generated root folder previously archived (for example, C: / System / Archive). Other folders used to archive elements By default, buildit archives only the output of the Visual C # and the Visual Basic .NET project. To archive the output generated from other items (eg, Visual Studio .NET installation items), add the folder element to the AdditionAlFoldersToarchive element. The Folder element contains the following properties: • Fullname. The full name of the source folder to be archived (for example, C: / System / Solution1 / Setup1 / Debug). • Destfoldername. The name of the target folder to be archived (for example, Debug / Setup1). Note If the ArchiveBuild option is enabled, Buildit archives files in each specified folder to the specified destination folder under the archive root folder. UpdateassemblyVersion element UpdateassemblyVersion element controls whether the internal version number is used to control the version of the generated assembly. For more information, see "TEAM Development with Visual Studio .Net and Visual SourceSafe" section below MSDN Library. This element contains the following properties: • Mode. If this property is set to "On", Buildit will use the internal version number to control the version of the generated assembly. • VBASSEMBLYVERSIONVSSPATH. The VSS path (for example, $ / system / askEMBLYVERSIONFO.VB), which contains venetical versions files shared between all generated Visual Basic .NET projects. If the solution does not contain any Visual Basic project, leave this property value blank. For more information, see the "Consider Sourcesa" section under the "Team Development with Visual Studio .Net and Visual SourceSafe" in MSDN Library. • CSASSEMBLYVERSIONVSSPATH. The VSS path (for example, $ / system / askEMBLYVERSIONFO.CS), which contains versions versions of the program that are shared between all Visual C # items generated. If the solution does not contain any Visual C # item, leave this property value blank. For more information, see the "Consider Sourcesa" section under the "Team Development with Visual Studio .Net and Visual SourceSafe" in MSDN Library. Enhancement This section contains a range of builds in the first edition of Buildit, but because the time limit is ultimately included in it. Sharing These features are the basic idea involved in the development process of Buildit, which proposes the fields that extend Buildit extensions, as well as inviting you to become a community member to express their ideas and code using the feedback part of the end of this article. Possible enhancements include: • Define an interface to allow Buildit to collaborate with the source code management provider (for example, ISourceControlProvider) instead of collaborating with Visual SourceSafe. This is to enable developers to configure Buildit to use another source code management provider (for example, Rational ClearCase). • Simplify the configuration of Buildit by implementing the default behavior at the lack of specific settings. Currently, if a specific build settings are missing in the application configuration file, Buildit will trigger an error. A more relaxed Buildit version will simply implement a certain default behavior when a setting is ignored. • Further simplify the configuration of Buildit by using a relative path (rather than using a fully qualified path). Currently, all file paths must be a fully qualified path. The fully qualified path is flexible than the relative path, but it is troublesome than it. Instead, simply configuring simply by using certain paths with some of the source root folders (eg, solution files, internal version number XML files, etc.). • Allow developers to specify an unlimited multiple assembly versions of the UpdateassemblyVersion option. Currently, Buildit allows developers to specify a Visual C # and a Visual Basic .NET program version file. This restriction is based on the following assumptions: Developers share this Visual C # program version file with all Visual C # items in VSS and share this Visual Basic .NET program version file with all Visual Basic .NET projects. However, developers may like to update individual assembly versions, rather than relying on VSS file sharing. • Define "Generate" events available for the developer extension generation process. Currently, it is only possible to extend the generation process by modifying the Buildit source code. A more flexible design will be an event that enables an event that caused at the end. Developers can then pass event handlers to this event, thereby performing custom logic. With this policy, you can also allow developers to customize other parts of the generation process (for example, after pre-generating, generating, generated). Allow the developer to specify the name of the buildit configuration file. Currently, Buildit finds configuration settings in the standard application configuration file called Buildit.exe.config. Therefore, developers cannot generate two different solutions using Buildit simultaneously. Instead, developers must copy the buildt assembly to another directory. The more friendly solution will allow developers to specify the name of the configuration file as the command line parameter, not the standard application configuration file. • Make Buildit to create a virtual directory for any web project that is not yet mapped to the virtual directory. Currently, the Visual Studio .NET prompts the user to set the location for the work copy of the web project (if such a location does not exist). Buildit automatically creates a virtual directory instead of prompting users to accept the default location. Class reference • BuildInitializer • BuilditsectionHandler • BuildManager • SourceSafeHelper • BuilditResourceManager • BuilditCommandLineArgs BuildInitializer The BuildInitializer Class Verify command line option, retrieves the settings of the build tool via the BuilditSectionHandler and starts the generation process through the BuildManager. Note The BuildInitializer class implements a public method called Start, which is called from the Static / SharedMain method of the console application. The "Start" method first verifies all command line parameters by calling a private way called AreCommandLineargsvalid. If these parameters are valid, BuildInitializer will use the BuilditSectionHandler class to generate the settings. The final step is to initiate the generation process by calling Build's build. Constructor BuildInitializer Public approach Start Private method ArecommandLineargsvalid determines if a given multiple command line parameters are valid. IsCommandLineargvalid determines if a given individual command line parameters are valid. USAGE writes usage information to the console. Call when all command line parameters are invalid. BuilditsectionHandler The BuilditSectionHandler class populates and returns the builditsettings structure with the settings read from the generated tool profile. Note The BuilditsectionHandler class (this class can implement the IconfigurationSectionHandler interface) Analysis The configuration settings in the buildit element in the tool configuration file. It loads the information in the buildit element into the structure called BuilditSettings. The BuilditSetting structure defines several properties that provide type security access to the configuration settings defined in the configuration file. For example, the BuilditSettings structure defines three properties that return different generation options: OptionsendBuildReport, OptionArchiveBuild, and OptionUpdateassemblyversion. The BuilditSetting structure also defines an attribute called Solutions and an attribute called SourceControlInfo, which corresponds to a particular element in the configuration file. Constructor BuilditsectionHandler initializes a new instance of the BuilditSectionHandler class. Public approach CREATE populates and returns the builditsettings structure with the settings read from the generated tool profile. Private method CreateBuildOption creates and populates the buildoption structure with settings read from the build tool profile. BuildManager BuildManager class combination generation process. Note BuildInitializer uses the BuildManager class to coordinate the generation process. BuildManager implements a constructor using two parameters: The type of a parameter is BuilditSettings, and the type of another parameter is BuilditResourceManager. When you create an instance of the BuildManager class, this class is initialized by the parameter passed to its constructor. This allows BuildManager to use setup and error messages during the generation. BuildManager also discloses a public method called Build, this method uses the buildType enumeration to determine whether to start Build or start the rebuild. BuildType enumeration is defined as follows. [C #] Public enum buildtype {build, rebuild}; Rebuild is defined as a system generated after parsing generation interrupts. The difference between REBUILD and Build is that some steps are ignored when Rebuild is executed. For example, when you execute build, BuildManager creates a new tag in the VSS, but does not do this when executing Rebuild. After determining BuildType, BuildManager calls several private methods to perform the various parts of the generation process. Constructor BuildManager initializes a new instance of the BuildManager class. Public approach Build combination generation process. Private method ArchiveAdditionalFolders copies the contents of the folders specified in the AdditionArFolderstoArchive segment (in the Generate Tool Configuration File) to the archive root folder. BackuplateStFolder backs up the Latest folder with the latest generated assembly. The location of the LATEST folder is specified in the generated tool profile. BuildassemblyVersionRegex generates a regular expression that replaces the internal version number component of the AssemblyVersion property. This expression depends on the assemblyversion property or the Visual Basic property or the Visual C # property. BuildSolutionAndcopyOutput generates a solution and copies the generated output to a given target directory. BuildsolutionConfig uses the specified generated configuration (for example, Release, Debug, etc.) to generate a given solution. Buildsolutions generates a given solution (one or more). CopyFiles (String, String) Copy all files in a given source folder to a given destination folder, which is the overload of the method when setting the ExcludedeBugFiles flag to false (fake). version. CopyFiles (String, String, Bool) copies all files in the source folder to a given target folder. If the ExcludedebugFiles flag is set to True (true), copy all files other than the debug file. CopyVSProjectOutput copies all Visual Basic and Visual C # items (Release or Debug) to a given target root folder. CopySolutionOutput copies the solution output (Release or Debug) to a given target root folder. DeleteArchiveFolder deletes an archive folder (if it exists). The location of the archive folder is specified in the generated tool profile. DeleteLateStBackupFolder deletes the Latest Backup folder (if present). The Latest Backup folder is in the same location in the Latest folder. DeleteLateStFolder deletes the Latest folder (if present). GenerateBuildReport generates a generated report called BuildReport.log and saves it to the work folder. GenerateLabel generates a label based on the internal version number. GetSourceFromLabel uses a given label to get the source root project from VSS. GetVsProjectLangType determines the language used to create a specified file (Visual Basic or Visual C #). Use the file extension to determine the language. IncrementBuildNumber Press 1 to increment the internal version number and write it to the internal version number XML file by calling WriteBuildNumber. Labelsource marks the source root project in VSS with a given tag. ReadBuildNumber reads the internal version number from the internal version number XML file. The name and location of this file are specified in the generated tool profile. RestoreLateStFolder restores the Latest folder from the Latest Backup folder (if the Latest folder exists). SendBuildreport sends a given generation report to the appropriate email recipient (if this option is enabled in the tool profile). UpdateassemblyVersionInfo Gets the VSS path of Visual Basic and Visual C # AssemblyVersion files (specified in the Generate Tool Profile) and calls overload versions of this method for each file (if this option is enabled in the tool configuration file). UpdateassemblyVersionInfo (String) Gets the specified AssemblyVersion file from VSS, updates the assemblyVersion property with the internal version number, and then re-check the file in VSS. WriteBuildNumber writes a given internal version number to the internal version number XML file. SourceSafeHelper SourceSafeHelper packages VSS automation objects to make itself more convenient to collaborate with VSS. Note During the generation, BuildManager uses the SourceSafeHelper class to interact with VSS. This class discloses several public methods (eg, Checkin and Checkout), which hides the implementation details when collaborating with VSS automation objects. Note The SourceSafeHelper class does not disclose all the methods of all VSS operations. It only opens the operation required to generate tools. Constructor SourceSafeHelper initializes a new instance of the SourceSafeHelper class. Public approach Checkin will repart it to the VSS given. Checkout will give a given item from the VSS. GetFromLabel gets a specific version of the given item from VSS. If the item is a project, the GET operation is recursive. Label tag a given VSS item with a specified tag. Undocheckout deletes the checkout status of a given VSS item. Private method GetItemSrecursively acquires from versioning Vssitem (items or files). The version can be a project or file. If VssItem is a file, this method is just to get the file. Otherwise, it acquires all items in the project in a recursive manner. GetVssItem gets references to VssItem (ie, projects or files). BuilditResourceManager The BuilditResourceManager class provides security access to the error message stored in the resource file. Note The BuilditResourceManager class is derived from the ResourceManager class in the System.Resources namespace, which is used to retrieve error messages from the resource file included in the generated tool set in the build.exe. It discloses several public methods (for example, getBuildSolutionFailedString) to provide type security access to resource values. This helps eliminate errors that may occur when calling a resourceManager.getstring (String Name) method with invalid resource name. Constructor BuilditResourceManager initializes a new instance of the BuilditResourceManager class. Public approach GetBuildSolutionFailedString Gets BuildsolutionFailed error message from the build tool resource file. The rest of the GET method performs a similar function; they provide type security access to the error information stored in the generated tool resource file. Private method no BuilditCommandLineargs The BuilditCommandLineargs class package is set by the command line argument supported by the generated tool. Note The BuilditCommandLineArgs class is derived from the StringCollection class in the system.collections.specialized namespace, which represents the command line parameter set supported by Buildit. BuildInitializer uses this class to determine if the command line parameter is valid. Constructor BuilditCommandLineargs initializes a new instance of the BuilditCommandLineArgs class. Public approach Tostring rewrites the System.Object :: toString () method by providing a string representation of a valid command line argument. common problem Can I modify the Buildit source code? Yes, you can modify and extend the buildit source code. For example, you can change the Visual Source Safe specific call and generate a Helper class that works with your own source code management product. Please tell us what you do! If you want to share your experience with us, see the Feedback section below. Do I need to install Visual Studio to buildit's running location? Yes, you need to install Visual Studio to a server or workstation generated by Buildit - not enough .NET Framework is not enough. summary This article has described how to keep in mind Buildit with simple and scalable features so that you can fully fit your specific generated process. Please use the email address provided under Feedback to tell us about the idea of buildit. About the Author Michael Monteiro is a technical consultant for Sapient Corporation, as well as an .NET Microsoft certification expert with more than eight years of experience. He is currently working in a group responsible for providing structural guidance for technology communities for Sapient. His contact email is mmonte@sapient.com. About Sapient Sapient is a leading business and technology consulting firm that helps Global 2000 customers achieve important business results by quickly applying and supporting advanced technology at a fixed price. Sapient was founded in 1991, its employees exceeded 1,500 people, and offices throughout Atlanta, Cambridge (Massachusetts), Chicago, Dallas, Dusseldorf, London, Los Angeles, Milan, Munich, New Delhi, New York, San Francisco, Toronto and Washington. For more information on Sapore, you can find it in http://www.sapient.com/. Partner Thank you very much following contributors and reviewers: Bernard Chen (Sapient Corporation), Brett Keown, Craig Skibo, David Lewis, Deyan Lazarov, Dimitris Georgakopoulos (Sapient Corporation), Edward Jezierski, Filiberto Selvas Pati o, Jeff Pflum, Joe Hom (? Avanade), Ken Hardy, Kenny Jones, Korby Parnell, Martin Born, Mick Das, Mike Pietraszak, Niel Sutton, Oded Ye Shekel, Rajiv Sodhi (Sapient Corporation), Ray Escamilla, Rich Knox, Russell Christopher and Sumit Sharma (Sapient Corporation) . Feedback Do you have any questions, comments and suggestions? To provide feedback to Buildit, send emails to buildit@sapient.com.
