So what we’ll do is actually build a package by using the command msbuild /t:PackageBeta

Below is the output that I have shorted so that you can see major targets that create the package as a zip file in the location: CodeToDeploy\Releases\Sample-Beta-0.1.0.0.zip

• Version
• Clean
• Publish
• Zip

C:\src\deployment>msbuild /t:PackageBeta
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3053]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 1/15/2010 4:53:21 PM.
Project "C:\src\deployment\build.proj" on node 0 (PackageBeta target(s)).
Project "C:\src\deployment\build.proj" (1) is building "C:\src\deployment\build
.proj" (1:2) on node 0 (Package target(s)).
  Version: 0.1.0.0
  Updating File "C:\src\deployment\src\Infrastructure\Properties\AssemblyInfo.c
  s".
    Replaced matches with "[assembly: AssemblyVersion("0.1.0.0")]".
  Updating File "C:\src\deployment\src\Test\Properties\AssemblyInfo.cs".
    Replaced matches with "[assembly: AssemblyVersion("0.1.0.0")]".
  Updating File "C:\src\deployment\src\UI\Properties\AssemblyInfo.cs".
    Replaced matches with "[assembly: AssemblyVersion("0.1.0.0")]".

  ...

Clean:
  Removing directory "C:\src\deployment\CodeToDeploy\Publish".
Publish:
  Creating directory "C:\src\deployment\CodeToDeploy\Publish\site".
  Creating directory "C:\src\deployment\CodeToDeploy\Publish\site\bin".
  Copying file from "C:\src\deployment\Src\UI\bin\UI.dll" to "C:\src\deployment
  \CodeToDeploy\Publish\site\bin\UI.dll".

  ...

Zip:
  Creating ZipFile: C:\src\deployment\CodeToDeploy\Publish\..\Releases\Sample-B
  eta-0.1.0.0.zip
Done Building Project "C:\src\deployment\build.proj" (Package target(s)).

Done Building Project "C:\src\deployment\build.proj" (PackageBeta target(s)).


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.70

Sorry, where was that release package?

The current scripts output the release file into a folder called CodeToDeploy (yes, this conventions was grabbed from CodeCampServer for asp.net mvc). In this folder, we build the raw output files to Publish (yes, this is a microsoft convention) and the packages to Release. The release file also then has the version number in the file. Here’s what it looks like below:

  CodeToDeploy/
    Publish/
      ... [all the files here]
    Releases/
      Sample-Beta-0.1.0.0.zip

Unzip and explore

Now, we can unzip the archive as below (of course, it is the same of the publish folder!)

    lib/
        extensionpack
        migratordotnet
    scripts/
        db/
            create.sql
            domainuser-for-db.sql
            drop.sql
            user-for-db.sql
        db-setup.tasks
    site/
      ... [all the application site stuff here]
    0.1.0.0
    Deploy.bat
    deploy.proj
    deploy.rsp
    directorybrowsing.xml
    Migrate.bat
    _Beta_ENVIRONMENT

Let’s work through this:

lib

This contains any libraries that are required for deployment process (rather than actually running the site). In this case we will be migrating a database and deploying to IIS.

scripts

These are all the deployment scripts needed. This includes scripts for first-time install and as well subsequent deployments (reinstalls/upgrades). Here you will se that all the creation scripts for the sql database are included.

site

This is the actual code that gets deployed to IIS

0.1.0.0

This is an empty file that simply has the version number as the name for quick identification.

Deploy.bat, .proj, .rsp

These are the workhorse files for each installation. The bat file is the GUI runner to invoke msbuild so that double click installs can be performed. The proj file has the targets (in this case there are no child tasks). The rsp file is there because it can be used to set specific environment variables that we want picked up regards of commandline or gui base bootstrapping

directorybrowsing.xml

Sorry, this is an odd fellow. It is copied to certain IIS environments to allow for directory browsing. At this stage, this approach is a path of least resistance.

Migrate.bat

This file is GUI runner just like deploy.bat except it is focussed exlusively on migrations. If you look at its contents you can see that it is msbuild.exe /t:MigrateUp /v:d /fl which is targetting Migrate up and outputting a verbose log to the default log file msbuild.log

_Beta_ENVIRONMENT

This file tells us that it was build specifically for the Beta environment. I use this technique if I have create builds specific to an environment. I avoid this approach as discussed earlier.

Understand the versioning

A last comment in this packaging process. Versioning of libraries and packages is always done. There are two main files that control the versioning:

 VERSION.xml
 scripts/
    version.tasks

VERSION.xml

This has already been mentioned before and can be found . It is the major.minor.build number. You’ll update this infrequently

  <PropertyGroup>
    <Major>0</Major>
    <Minor>1</Minor>
    <Build>0</Build>
  </PropertyGroup>

version.tasks

It does two things. It gets the revision number from the source control – the sample uses SVN but it can be TFS, git, Peforce. It creates a version of the format: major.minor.build.revision. It updates all the AssemblyInfo.cs files based on the version. Now that I have told you that, let’s see what Help tells us!

    >msbuild /t:HelpVersion
    
    Microsoft (R) Build Engine Version 3.5.30729.1
    [Microsoft .NET Framework, Version 2.0.50727.3053]
    Copyright (C) Microsoft Corporation 2007. All rights reserved.

    Build started 1/15/2010 5:45:27 PM.
    Project "C:\src\deployment\build.proj" on node 0 (HelpVersion target(s)).


          Updates all the AssemblyInfo.cs files with VERSION (major, minor, build)
          and revision looked up from svn

          msbuild /t:Version

          Targets:
           - Version
           - SvnVersion

          Dependencies: svn commandline client (svnversion.exe - installed to 
                                            C:\Program Files\Subversion\bin)

Points to watch out for:

• revision with 0 means that it was probably a local build without access to source control
• AssemblyInfo.cs files get updated but you don’t want to check this in and you don’t want these to come up as changed so I suggest that you check them into source and then put an ignore or lock on them.
• Build server should really be the only place that creates this version number
• release packages have version numbers in the filename for ease and archiving