Build and Deployment

Greedy Application Mentality with TFS

Colin Bowern — Fri, 09 Jun 2006 01:07:00 GMT

I set off intending to experiment with Team Foundation Server recently to potentially replace our Subversion deployment. As I built up my virtual machine for the TFS application tier I went to install the data tier on our beefy 64-bit SQL Server machine and was stopped by a problem:

SQL Server 2005 Reporting Services service is installed on the data-tier computer. The service should instead be on the application-tier computer. Uninstall SQL Server 2005 Reporting Services from the data-tier computer and run setup again.

Upon further investigation I found out that TFS seems to want to be isolated in it's data tier. Sure we could everything onto a single box but I've got a perfectly good SQL Server which has three instances of SQL Server to support both production and development needs for the office. Why would I want to install yet another copy of SQL Server which I need to manage, monitor, and patch? I am amazed to see a mentality of application development that “applications require their own dedicated server“. Sometimes I wonder if the folks in Redmond realize that not all of us have billions of dollars in the bank to buy servers? I want to maximize the investment in my hardware which means stacking several applications onto a single server. Wasn't that the message the Windows Server 2003 marketing folks wanted to convey -- “Do more with less“? Applications should only need a dedicated server when their resource usage profile causes resource contention - not because a developer decided to assume that the server would contain nothing else.

Reviewing the TFS installation guide again I noticed a related comment which made me chuckle:

Team Foundation Server cannot be installed on a domain controller and does not support installing other servers such as Exchange Server or Host Integration Server on the same computer.

I would really be interested in knowing why they wrote this. What's so bad about a machine running as a domain controller or Exchange Server? They don't mutate the system into a horribly unusable state last I checked.

Installing with Native Images and Debug Symbols

Colin Bowern — Fri, 24 Mar 2006 01:37:00 GMT

For some of our projects we're looking to not only deploy assemblies to the GAC, but generate native images and copy the debug symbols to the GAC (which buys us line numbers in exceptions -- it's much easier to debug when you know the line number!). I've been experimenting with the VS2005 Setup Project to try and automate the process. During this experimentation realized a number of short comings:

Cannot have an assembly be used as a Custom Action and deployed into the GAC at the same time.

Solution: Move Installer class to a separate assembly.

There's no fancy “Generate Native Image“ flag.

Solution: Write a Custom Action to generate a native image.

The Global Assembly Cache folder is reserved for signed outputs only.

Solution: Write a Custom Action to copy the unsigned outputs as part of the install.

It seems as usual the Setup Project that ships with VS2005 is weak in a number of areas (e.g. deployment of multiple instance applications). If the product groups were all forced to use the Setup Project to deploy all Microsoft apps I bet it would change drastically (hint hint MSFT). At this point I don't want to pay a billion dollars for InstallShield (which in past experience tends to crash numerous times), nor do I want to have to script out something for a seamingly common set of functions that I'm sure a lot of us developers have needs for.

For anyone who is trying to NGen or copy the Debug Symbols (aka Program Database, PDB) to the GAC during installation below is a snippet of my Installer class. A few notes:

This class has been tested with the RTM version of the .NET Framework 2.0.
None of the paths are hard-coded. I wanted to future-proof it so that it doesn't break under future builds and so it would work in scenarios where people moved the GAC.
Since the installer remains separate from the rest of the classes in my solution I did hard code the assembly names. I know it's not the greatest idea but it works for me partly because they all share the same version number and public key token. If you needed to handle other assemblies you could probably go with a manifest xml file or something like that as the source and then read the version numbers and tokens from the GAC.
Debug Symbols need to reside in the same folder as the installer class. Once again, you can feel free to modify the code to be more picky. The Context propery supports parameters which can be passed in through the CustomActionData propery of the Custom Action.
I couldn't copy debug symbols during the Install phase as the destination folders in the GAC didn't exist. As such it ended up as part of the Commit phase.

And now on to the code:

    1 private string AssemblyCachePath, FrameworkPath;
    2 private string[] AssemblyNames = new string[] 
    3     { "MyAssembly", "MySecondAssembly" };
    4 
    5 public Installer()
    6 {
    7     FrameworkPath = RuntimeEnvironment.GetRuntimeDirectory();
    8 
    9     int MaxPathLength = 1024;
   10     StringBuilder Buffer = new StringBuilder(MaxPathLength);
   11     GetCachePath(ASM_CACHE_FLAGS.ASM_CACHE_ROOT, Buffer, ref MaxPathLength);
   12     AssemblyCachePath = Buffer.ToString();
   13     //...
   14 }
   15 
   16 [DllImport("fusion.dll")]
   17 public extern static int GetCachePath(
   18     ASM_CACHE_FLAGS dwCacheFlags, 
   19     [MarshalAs(UnmanagedType.LPWStr)] StringBuilder pwzCachePath, 
   20     ref int pcchPath);
   21 
   22 [SecurityPermission(SecurityAction.Demand)]
   23 public override void Install(System.Collections.IDictionary stateSaver)
   24 {
   25     base.Install(stateSaver);
   26 
   27     Assembly ExecutingAssembly = Assembly.GetExecutingAssembly();
   28     AssemblyName ExecutingAssemblyName = ExecutingAssembly.GetName();
   29     string ExecutingAssemblyFullName = ExecutingAssemblyName.FullName;
   30 
   31     ProcessStartInfo NGenStartInfo = new ProcessStartInfo(
   32         Path.Combine( FrameworkPath, "ngen.exe" )
   33         );
   34 
   35     try
   36     {
   37         for (int index = AssemblyNames.GetUpperBound(0); 
   38                 index >= AssemblyNames.GetLowerBound(0); index--)
   39         {
   40             // Create Native Image
   41             NGenStartInfo.Arguments = String.Format("install \"{0}\"", 
   42                 ExecutingAssemblyFullName.Replace(
   43                     ExecutingAssemblyName.Name, 
   44                     AssemblyNames[index]));
   45 
   46             NGenStartInfo.RedirectStandardOutput = true;
   47             NGenStartInfo.UseShellExecute = false;
   48 
   49             using (Process NGenProcess = Process.Start(NGenStartInfo))
   50             {
   51                 NGenProcess.WaitForExit();
   52                 Context.LogMessage(NGenProcess.StandardOutput.ReadToEnd());
   53             }
   54         }
   55     }
   56     catch (Exception ex)
   57     {
   58         throw new InstallException(ex.Message, ex);
   59     }
   60 }
   61 
   62 public override void Commit(System.Collections.IDictionary savedState)
   63 {
   64     base.Commit(savedState);
   65 
   66     Assembly ExecutingAssembly = Assembly.GetExecutingAssembly();
   67     AssemblyName ExecutingAssemblyName = ExecutingAssembly.GetName();
   68     string ExecutingAssemblyFullName = ExecutingAssemblyName.FullName;
   69 
   70     string GacFolder = String.Format(
   71         "{0}\\GAC_{1}\\{2}\\{3}__{4}", 
   72         AssemblyCachePath, 
   73         ExecutingAssemblyName.ProcessorArchitecture, 
   74         ExecutingAssemblyName.Name, 
   75         ExecutingAssemblyName.Version, 
   76         ByteArrayToString(ExecutingAssemblyName.GetPublicKeyToken()));
   77 
   78     string DebugSymbolsPath = Path.GetDirectoryName(ExecutingAssembly.Location);
   79 
   80     try
   81     {
   82         for (int index = AssemblyNames.GetUpperBound(0); 
   83                 index >= AssemblyNames.GetLowerBound(0); index--)
   84         {
   85             // Copy Debug Symbols to GAC Folder
   86             string DebugSymbolsFile = AssemblyNames[index] + ".pdb";
   87             string DestinationFile = Path.Combine(
   88                 GacFolder.Replace(
   89                     ExecutingAssemblyName.Name, 
   90                     AssemblyNames[index]), 
   91                 DebugSymbolsFile);
   92 
   93             string SourceFile = Path.Combine(DebugSymbolsPath, DebugSymbolsFile);
   94             if (File.Exists(SourceFile))
   95             {
   96                 Context.LogMessage(String.Format(
   97                     "Copying {0} to {1}", 
   98                     SourceFile, 
   99                     DestinationFile));
  100 
  101                 File.Copy(SourceFile, DestinationFile, true);
  102             }
  103         }
  104     }
  105     catch (Exception ex)
  106     {
  107         throw new InstallException(ex.Message, ex);
  108     }
  109 }
  110 
  111 public override void Uninstall(System.Collections.IDictionary savedState)
  112 {
  113     base.Uninstall(savedState);
  114 
  115     Assembly ExecutingAssembly = Assembly.GetExecutingAssembly();
  116     AssemblyName ExecutingAssemblyName = ExecutingAssembly.GetName();
  117     string ExecutingAssemblyFullName = ExecutingAssemblyName.FullName;
  118 
  119     ProcessStartInfo NGenStartInfo = new ProcessStartInfo(
  120         Path.Combine( FrameworkPath, "ngen.exe" )
  121         );
  122 
  123     try
  124     {
  125         for (int index = AssemblyNames.GetLowerBound(0); 
  126                 index <= AssemblyNames.GetUpperBound(0); index++)
  127         {
  128             // Create Native Image
  129             NGenStartInfo.Arguments = String.Format("uninstall \"{0}\"", 
  130                 ExecutingAssemblyFullName.Replace(
  131                     ExecutingAssemblyName.Name, 
  132                     AssemblyNames[index]));
  133 
  134             NGenStartInfo.RedirectStandardOutput = true;
  135             NGenStartInfo.UseShellExecute = false;
  136 
  137             using (Process NGenProcess = Process.Start(NGenStartInfo))
  138             {
  139                 NGenProcess.WaitForExit();
  140                 Context.LogMessage(NGenProcess.StandardOutput.ReadToEnd());
  141             }
  142         }
  143     }
  144     catch (Exception ex)
  145     {
  146         throw new InstallException(ex.Message, ex);
  147     }
  148 }
  149 
  150 public override void Rollback(System.Collections.IDictionary savedState)
  151 {
  152     base.Rollback(savedState);
  153 
  154     Assembly ExecutingAssembly = Assembly.GetExecutingAssembly();
  155     AssemblyName ExecutingAssemblyName = ExecutingAssembly.GetName();
  156     string ExecutingAssemblyFullName = ExecutingAssemblyName.FullName;
  157 
  158     ProcessStartInfo NGenStartInfo = new ProcessStartInfo(
  159         Path.Combine( FrameworkPath, "ngen.exe" )
  160         );
  161 
  162     try
  163     {
  164         for (int index = AssemblyNames.GetUpperBound(0); 
  165                 index >= AssemblyNames.GetLowerBound(0); index--)
  166         {
  167             // Create Native Image
  168             NGenStartInfo.Arguments = String.Format("uninstall \"{0}\"", 
  169                 ExecutingAssemblyFullName.Replace(
  170                     ExecutingAssemblyName.Name, 
  171                     AssemblyNames[index]));
  172 
  173             NGenStartInfo.RedirectStandardOutput = true;
  174             NGenStartInfo.UseShellExecute = false;
  175 
  176             using (Process NGenProcess = Process.Start(NGenStartInfo))
  177             {
  178                 NGenProcess.WaitForExit();
  179                 Context.LogMessage(NGenProcess.StandardOutput.ReadToEnd());
  180             }
  181         }
  182     }
  183     catch (Exception ex)
  184     {
  185         throw new InstallException(ex.Message, ex);
  186     }
  187 }
  188 
  189 private string ByteArrayToString(byte[] byteArray)
  190 {
  191     if (byteArray == null)
  192         return null;
  193 
  194     StringBuilder buffer = new StringBuilder(byteArray.Length);
  195     for (int index = 0; index < byteArray.Length; index++)
  196     {
  197         buffer.AppendFormat("{0:x2}", byteArray[index]);
  198     }
  199 
  200     return buffer.ToString();
  201 }
  202 
  203 public enum ASM_CACHE_FLAGS
  204 {
  205     ASM_CACHE_ZAP = 0x01,
  206     ASM_CACHE_GAC = 0x02,
  207     ASM_CACHE_DOWNLOAD = 0x04,
  208     ASM_CACHE_ROOT = 0x08
  209 }

Filtering .NET 1.1 functionality when using MSBuild and MSBee

Colin Bowern — Sun, 12 Mar 2006 22:49:00 GMT

We try to be good developers and this includes ensuring our warnings are taken care of. A standard part of our debug builds includes treating warnings as errors. When we were faced with migrating a project to a split .NET 1.1/2.0 build using MSBee we found it lacked the introduction of a preprocessor directive that would allow us to make the critical decisions in the code.

One example where we needed this information had to do with the C# compiler (CSC) in .NET 1.1 lacking assembly signing options. As a result we had to add back in the AssemblyKeyFile attribute. When the Treat Warnings as Errors option is enabled this will cause an error in the .NET 2.0 C# Compiler. To deal with this a little hack of the MSBuildExtras.Fx1_1.CSharp.targets file helped us out. In the redefinition of the CSC task we modified:

DefineConstants="$(DefineConstants)"

to say:

DefineConstants="FX1_1;$(DefineConstants)"

Now we can define condition statements in our code:

#if FX1_1

// NOTE: Signed assemblies are not allowed in the ASP.NET application bin directory.
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("C:\\Keys\\MyKey.snk")]

#endif

Hopefully this will make it to the final MSBee release.

Suppressing References in Build Output

Colin Bowern — Sun, 12 Mar 2006 17:15:00 GMT

On our build server we don't have any of our dependent applications (e.g. Commerce Server, BizTalk Server) installed because it's cheaper on the licensing and the build server is actually a Virtual Server image running on my dev box where I don't feel like giving up excess resources to build processes. :) One of the things that has bugged me for a while is the fact that the build process copies referenced assemblies even when Copy Local set to false. We store all of our references on a network share so everyone is pulling the same version during build. After a little tinkering I figured out that it doesn't actually write that to the project file.

If you want to suppress the referenced assemblies from being copied to the bin folder during build you'll need to edit the project file by hand and add a Private=”false”. For example:

Name = "MyThirdPartyAssembly"
AssemblyName = "MyThirdPartyAssembly"
HintPath = "R:\ThirdParty\MyThirdPartyAssembly\2.0.2.0\MyThirdPartyAssembly.DLL"
Private = "False"
/>

Up next is trying this with VS2005 to see if we can achieve the same result. :)

UPDATE: Works with VS2005 as well!

      MyThirdPartyAssembly
      R:\ThirdParty\MyThirdPartyAssembly\1.0.0.0\MyThirdPartyAssembly.dll
      false

    ...

MSTest using a Test List via Command-Line

Colin Bowern — Sun, 12 Mar 2006 16:59:00 GMT

Converting from NUnit to MSTest I've seem to have hit a little snag. I can't run MSTest on the command line while focusing on a subset of the tests. MSTest introduces the concept of Test Lists which allows me to segregate the tests that will run on the build server versus the ones that require a development machine or test environment for smoke testing.

It seems when you run the command line with the specified test list:

mstest /testmetadata:tests.vsmdi /runconfig:localtestrun.testrunconfig /testlist:BuildVerificationTests

It finds the tests in the list but it cannot find the test to execute:

Microsoft (R) Test Execution Command Line Tool Version 8.0.50727.42
Copyright (C) Microsoft Corporation 2005. All rights reserved.

Loading tests.vsmdi...
Starting execution...
Test CheckExpectedTypeGoodParameters cannot be found.
No tests to execute.

If you're puzzled, so am I. Feel free to vote for the issue on the MSDN Product Feedback bug I've filed.

MSDN Product Feedback Bug: MSTest Command Line Error - Test 'x' cannot be found.

MSBuild support for .NET 1.1 targets

Colin Bowern — Thu, 16 Feb 2006 02:40:00 GMT

The MSBuild team just posted beta 1 of the “MSBee” toolkit which enables building .NET Framework 1.1 applications with MSBuild. For those of you moving towards MSBuild and still have a few 1.1 apps lingering this bring the build process under a single tool.

On a related note I've written a few custom tasks already to generate publisher policy assemblies, use FxCop 1.35b1, Nullsoft Installation System, and the Red-gate SQL Toolkit. I'm working to get them added to the MSBuild Tasks Community Project.

Source: MSBuild Team Blog - MSBuild Extras - Toolkit for .NET 1.1 (beta 1) is Out!

A More Complete Stack Trace when Debugging Assemblies in the GAC

Colin Bowern — Tue, 07 Feb 2006 00:17:00 GMT

Have you ever had the need to get line numbers from an exception stack trace for an assembly in the GAC? If you work with BizTalk Server the answer is likely yes. To debug Commerce Server pipeline components which I have traditionally put custom C# pipeline components in the GAC and then registered for COM interop. I've found having line numbers indespensible when apps are running in the production test environment. I went searching for the answer and came across it. I thought I'd write it down here so I remember it.

To get line numbers with your stack trace:

When compiling both debug and release builds make sure to generate a program database (aka symbols).
- For release builds you'll want to make sure you use the correct switch, /debug:pdbonly, since /debug:full disables optimization.
When you need line numbers place the .pdb file beside your assembly (in the same folder).
- For GAC assemblies you'll need to put it in the assembly folder (e.g. c:\windows\assembly\gac\\__)
- Be aware that the .NET Framework 2.0 is adding platform specific GAC folders (e.g. GAC, GAC_32, GAC_MSIL, etc...).

Then you should have line numbers in your stack traces. It's great for debugging and the program databases can be in place for explicit debugging needs and then removed if you don't feel comfortable with them there.

Delay Signing defeated! D'oh!

Colin Bowern — Sat, 21 Jan 2006 20:13:00 GMT

Development machines here use a delayed signing for building binaries. Only during the build process on the build server does a public/private key pair get used for signing assemblies. When using the unit testing features of Visual Studio 2005 we are prompted to provide a key for re-signing an assembly after instrumentation has been applied. If we provide the public key it will fail. If we provide the public/private key pair it will work.

Has anyone else managed to get this working? Here's what I'm trying to do:

1. Create a public/private key pair and extract the public key:
sn -k Private.snk
sn -p Private.snk Public.snk
2. Create a class library project and specify it should delay sign using Public.snk
3. Create a test project and enable Code Coverage.
4. Check the "instrument assemblies in place" option and provide a path to the Public.snk
5. Attempt a test run.

-or-

From the command prompt:

sn -R bin\Debug\MyAssembly.dll Public.snk

In turn you'll get the following when using IDE for code coverage:

Instrumentation warning: Cannot extract the public key from the key file 'C:\Projects\Common\Common\Public.snk': Bad Version of provider. (Exception from HRESULT: 0x80090007)
Check that the key file is not password protected. Password protected key files are not supported. (It's not password protected!)
Code coverage instrumentation warning while processing file Common.dll:
Warning VSP2001 : C:\Projects\MyAssembly\MyAssembly\bin\Debug\MyAssembly.dll is a strongly named assembly. It will need to be re-signed before it can be executed.
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.

When using command prompt:

Failed to extract public key from key pair -- Bad Version of provider.

Ah well. Filed as a bug and will hopefully be fixed. So much for the joys of delay signing.

MSDN Product Feedback Center: Bug Details