Tag: Team Build

  • TFS TeamBuild doesn’t copy references (Assemblies)

    As a TFS administrator, I often have to solve the same issue again and again: new developers complain that referenced assemblies are not dropped by TeamBuild although locally, Visual Studio copies those references into the bin folder… The trick is to set the property “Copy Local” = “False” on the references to be copied, Save the project, reset the property “Copy Local” = “True” and Save again the project.

    Click to Read More

    We have experienced this issue at least with VS 2010 – TFS 2010 and VS 2013 – TFS 2013. I have to say I don’t remember about VS 2008 – TFS 2008  and VS 2005 – TFS 2005.

    Project’s “Copy Local” property is the one that indicates if a file reference must be copied or not in the output folder. The value of that property is stored in a tag <Private> in the project file (.csproj, .vbproj, …). Ex.: <Private>true</Private>

    The problem is that VS does not add this tag for references whose ‘Copy Local’ property is ‘true’, ‘true’ being the default value for file references added on assemblies not in the GAC. It only adds this tag if one changes the property value to ‘false’. Later, if one sets the value back to ‘true’, the tag is kept but its value is changed.

    This is a problem because MSBuild, run by TeamBuild to compile the projects, assume that the value of a “Copy Local” property is ‘False’ if the tag <Private> is not found in the project file.

    So, the trick is to force VS to add the tag for all references added with ‘Copy Local’=’true’. This can be done as explained above:  set “Copy Local” = “False” on the required references, Save the project, reset “Copy Local” = “True” and Save again the project.

    Loading

    ,
  • Assembly Version, File Version and Product Version: The Butterfly Effect

    Assembly Version, File Version and Product Version are “related” if you don’t specify them explicitly… and you could be surprised by one of the side effect: loosing you application data or user settings when incrementing the Assembly File Version.

    Click to Read More

    How are those versions specified:

    By default, any new Visual Studio Project includes an AssemblyInfo file defining default values (major, minor, build and revision) for the Assembly Version and Assembly File Version:

    [csharp][assembly: AssemblyVersion("1.0.0.0")]
    [assembly: AssemblyFileVersion("1.0.0.0")][/csharp]
    • A difference in the build number represents a recompilation of the same source. This is usually appropriate because of processor, platform, or compiler changes.
    • Assemblies with the same name, major, and minor version numbers but different revision numbers are intended to be fully interchangeable. This is usually appropriate for security fix, etc …
    • “[assembly: AssemblyVersion(“65534.65534.65534.65534“)]” is maximum.

    MSBuild can auto-increment the build and revision numbers at each build if we provide a (*) in place of those figures. Ex.

    [csharp][assembly: AssemblyVersion("1.0.*")][/csharp]

    or

    [csharp][assembly: AssemblyVersion("1.0.0.*")][/csharp]

    In such cases, the build number is generated based on the current day and the revision number is generated based on the number of seconds since midnight. Replacing the revision number only with a (*) would be irrelevant. Indeed, consecutive builds would most probably have lower revisions.

    There is no default value set for the Product Version when creating a new Visual Studio Project. But a value can be set manually in the AssemblyInfo file using:

    [csharp][assembly: AssemblyInformationalVersion("1.0.0.0")][/csharp]

    Usually, the Product Version is a value like major.minor.build, but it can actually be any string, like “1.0 RC”, etc… Don’t use (*) in this string as it wouldn’t be replaced by an auto-incremented figure. Instead, it would crash your application in some cases (See further for the explanation). Notice also that before VS 2010, using anything else that major.minor.build.rev was resulting in  false warning during compilation.

    What do those versions mean:

    Assembly Version : This is the version number used by framework during build and at runtime to locate, link and load the assemblies. When you add reference to any assembly in your project, it is this version number which gets embedded. At runtime, CLR looks for assembly with this version number to load. But remember this version is used along with name, public key token and culture information only if the assemblies are strong-named signed. If assemblies are not strong-named signed, only file names are used for loading.
     
    Assembly File Version : This is the version number given to file as in file system. It is displayed by Windows Explorer. Its never used by .NET framework or runtime for referencing. But it can be used by OS tools.

    Product Version (a.k.a Assembly Informational Version): Defines an additional version information for an assembly manifest. This is the version you would use when talking to customers or for display on your website..

    What if a version is not specified:

    • If the Assembly version is not explicitly specified, it takes the value of 0.0.0.0.
    • If the Assembly File version is not explicitly specified, it takes the value of the Assembly version.
    • If the Product version is not explicitly specified, it takes the value of the Assembly File version.
    How could issues occurred due to this relation:

    By your fault 🙂

    At work, we recently decided to manage the major and minor numbers of the Assembly Versions at build time, within our TFS Build Process Template. Assembly Versions’ build and release numbers are kept equal to 0 while major and minor are enforced with values provided through Build Definitions’ parameters. At the same time,  we auto-increment the build and release numbers of the Assembly File Versions while keeping their major and minor numbers aligned with those of the Assembly Versions. We don’t touch the Product Version. This was designed as recommended in KB 556041.

    As mentioned, major and minor numbers are specified through custom parameters of our Build Definitions. The build number is computed to reflect directly the current day using a format like “YMMdd” with Y = year modulo x to be <= 6 (None of our product has a longer life). The release number is set with the auto-incremented value provided out-of-the box by Team Build.

    Previously, most of the binaries were compiled locally, on development workstations, and there was no version management at all (There was simply no need for any such versioning): Assembly Version and Assembly File Version were always kept unchanged.

    The change introduced with our Build Process Template had an unexpected consequence: As there never was any Product Version specified explicitly in the AssemblyInfo, binaries’ Product Versions were always equal to the Assembly File Version… kept therefore unchanged through all builds. However, since we started to auto-increment the Assembly File Version, the Product Version started to increment too…

    And ? And some users started to complain that their custom settings were lost after the installation of each new version…

    We quickly noticed that, as usually recommended, developers were making use the two following properties to store  respectively application’s data and users’ data:

    [csharp]Application.CommonAppDataPath[/csharp]
    [csharp]Application.LocalUserAppDataPath[/csharp]

    And after some investigations on MSDN, it appeared that the path returned by those properties depend among other on the Product Version 🙁

    Depending on the OS, CommonAppDataPath is usually like:

    • %SystemDrive%\Documents and Settings\All Users\Application Data\<CompanyName>\<ProductName>\<ProductVersion> or
    • %SystemDrive%\ProgramData\<CompanyName>\<ProductName>\<ProductVersion>

    And LocalUserAppDataPath is like:

    • “%SystemDrive%\Documents and Settings\<UserId>\Local Settings\Application Data\<CompanyName>\<ProductName>\<ProductVersion>” or
    • “%SystemDrive%\Users\<UserId>\AppData\Local\<CompanyName>\<ProductName>\<ProductVersion>“.

    So, indeed, each new release of our product having now a new Product Version, application’s data and users’ data of the previous versions are not used anymore…

    Any (*) used in the Product Version (e.g.: 1.0.*) wouldn’t be replaced by auto-incremented build/release numbers (as mentioned previously), the “AppDataPath”  above would contain an illegal character; reason why the application would crash when accessing this path.

    This also impacted applications accessing settings in the registry with methods like:

    [csharp]Application.UserAppDataRegistry.SetValue()[/csharp]
    [csharp]Application.CommonAppDataRegistry.SetValue()[/csharp]

    Those methods access respectively data under 

    • HKCU\Software\<CompanyName>\<ProductName>\<ProductVersion>\
    • HKLM\Software\<CompanyName>\<ProductName>\<ProductVersion>\
    Read also this paper on User Settings Management.
    See also one of my sources here about this topic.

    Loading

    ,
  • Drop Builds’ primary output in a “Latest” folder

    As briefly mentioned in another post, we have a specific “Reference Assemblies” folder on the Build Machines containing the latest version of each assembly issued from a successful Build. Assemblies in that folder, know as the “Latest” folder, can be used for “Continuous Integration” Builds.  This post is about the pragmatic solution implemented to drop only the primary output of the Builds in that folder.

    Click to Read More

    The output of a Build contains not only the assemblies and satellite assemblies issued from the compilation of the Visual Studio Projects (I.e.: assemblies part of the “primary output” as named in the Microsoft Setup Projects). It contains also a copy of all the referenced assemblies (file references) with the property “CopyLocal”=”True”.

    It’s important for our purpose to only drop the primary output into the “Latest” folder, otherwise we could override the latest version of some referenced assemblies with a  copy of the specific version found for the Build (e.g.: when targeting the Integration Environment, we use the promoted version on, the assemblies which are possibly not the latest).

    We may not set “CopyLocal”=”False” on all the “file references” because MSTest needs a copy of those in the bin folder to be able to run the unit Tests (That would not be the case if we could find for MSTest an equivalent of the “ReferencePath” parameter of MSBuild).

    We don’t have access to methods (or well described “algorithms”) to retrieve the exact list of assemblies part of the “primary output”. Such methods are only implemented in the Microsoft Setup Projects (Projects not supported, by the way, by MSBuild).

    We don’t want all our developers to add MSBuild Scripts in their Visual Studio Projects to drop the “Targets” in the “Latest” folder.

    Ex. copy “$(TargetDir)$(TargetName).???” “C:\RefAssemblies\Latest”

    This is not only too error prone (like everything you request to a human developer), but it’s also not robust enough. It’s in our opinion impossible to maintain this with enough guarantee taking into account that developers can for example add support for new languages at any time. For each Project, in addition to the assembly $(TargetDir)$(TargetName).dll, we also have to drop the satellite assemblies (e.g.: <culture>\<assemblyname>.resources.dll”), etc…

    The most generic solution we found to identify the assemblies part of the primary output, although quick and dirty, consists in parsing the FileListAbsolute.txt file generated by MSBuild itself and available in the “obj” folder. We “rely” so on direct output of Microsoft (the content of that file) and avoid to implement (and maintain) our own generic (and most probably complex) algorithm (“complex” because I have no idea how to detect satellite assemblies in a Visual Studio Project).

    Notice: We may only drop the primary output of Builds in the “Latest” folder for “Continuous Integration” Builds or Builds targeting the Integration Environment (both using the latest version of the sources). Builds targeting Qualification, Pre-Production or Production use always a specific version of the sources instead of the latest version. Their purpose is indeed to fix a bug in the assemblies deployed in the targeted environment and build with older sources.

    Click to Read More

    [csharp] using System;
    using System.IO;
    using System.Linq;
    using System.Activities;
    using System.Reflection;
    using System.Diagnostics;
    using System.ComponentModel;
    using System.Collections.Generic;
    using Microsoft.TeamFoundation.Build.Client;
    using Microsoft.Build.Evaluation;

    namespace AG.SCRM.TeamBuild.Activity
    {
    /// &lt;summary&gt;
    /// Collect Build’s Primary Output Items
    /// &lt;/summary&gt;
    [BuildActivity(HostEnvironmentOption.All)] public sealed class GetPrimayOutput : CodeActivity
    {
    /// &lt;summary&gt;
    /// List of Build’s Primary Output Items
    /// &lt;/summary&gt;
    [RequiredArgument] public InOutArgument&lt;List&lt;FileInfo&gt;&gt; PrimaryOutputItems { get; set; }

    /// &lt;summary&gt;
    /// Build’s Configuration Parameter
    /// &lt;/summary&gt;
    [RequiredArgument] public InArgument&lt;string&gt; Configuration { get; set; }

    /// &lt;summary&gt;
    /// Build’s Platform Parameter
    /// &lt;/summary&gt;
    [RequiredArgument] public InArgument&lt;string&gt; Platform { get; set; }

    /// &lt;summary&gt;
    /// Local path of Build’s project file
    /// &lt;/summary&gt;
    [RequiredArgument] public InArgument&lt;string&gt; LocalProject { get; set; }

    [RequiredArgument] public InArgument&lt;string&gt; OutDir { get; set; }

    /// &lt;summary&gt;
    /// Collect Build’s Primary Output Items
    /// &lt;/summary&gt;
    /// &lt;param name=&quot;context&quot;&gt;&lt;/param&gt;
    protected override void Execute(CodeActivityContext context)
    {
    var fileListAbsolute = PrimaryOutputItems.Get(context);
    var localProject = LocalProject.Get(context);
    var configuration = Configuration.Get(context);
    var platform = Platform.Get(context);

    // Default Configuration is &quot;Debug&quot;
    if (string.IsNullOrEmpty(configuration)) configuration = &quot;Debug&quot;;

    // Initialize the list of Build’s Primary Output Items if required.
    // Otherwise, add Build’s Primary Output Items to the provided list
    // to possibly support a loop on all Visual Studio Solution files in
    // Build’s
    if (fileListAbsolute == null) fileListAbsolute = new List&lt;FileInfo&gt;();

    if (Path.GetExtension(localProject).Equals(&quot;.sln&quot;, StringComparison.InvariantCultureIgnoreCase))
    {
    // Parse the Visual Studio Solution file
    SolutionParser sln = new SolutionParser(localProject);
    string root = Path.GetDirectoryName(localProject);
    foreach (SolutionProject project in sln.MSBuildProjects)
    {
    localProject = Path.Combine(root, project.RelativePath);
    CollectOutputItems(context, fileListAbsolute, configuration, platform, localProject);
    }
    }
    else
    {
    // Validate that the file is a Visual Studio Project
    var projectCollection = new ProjectCollection();
    try
    {
    Project project = projectCollection.LoadProject(localProject);
    string projectDirectoryPath = Path.GetDirectoryName(localProject);
    CollectOutputItems(context, fileListAbsolute, configuration, platform, localProject);
    }
    catch (Exception ex)
    {
    throw new Exception(string.Format(&quot;Project file ‘{0}’ is not a valid Visual Studio project.&quot;, localProject), ex);
    }
    projectCollection.UnloadAllProjects();

    }

    context.SetValue(PrimaryOutputItems, fileListAbsolute);
    }

    private static void CollectOutputItems(CodeActivityContext context, List&lt;FileInfo&gt; items, string configuration, string platform, string project)
    {
    string projectFileName = Path.GetFileName(project);
    string projectName = Path.GetFileNameWithoutExtension(project);
    string projectPath = Path.GetDirectoryName(project);
    string fileListAbsolute = GetFileListAbsolute(configuration, platform, projectFileName, projectPath);

    if (!string.IsNullOrEmpty(fileListAbsolute))
    {
    System.IO.StreamReader file = null;
    string line;

    string parent = Path.GetDirectoryName(fileListAbsolute);

    // Read the file and parse it line by line.
    using (file = new System.IO.StreamReader(fileListAbsolute))
    {
    while ((line = file.ReadLine()) != null)
    {
    // Ignore obj folder’s local items.
    if (!line.StartsWith(parent, StringComparison.OrdinalIgnoreCase))
    {
    FileInfo item = new FileInfo(line);
    if (item.Exists)
    {
    // We are actually only interested in .dll and .exe + their .pdb, .xml and .config
    if (item.Extension.Equals(&quot;.dll&quot;, StringComparison.OrdinalIgnoreCase) || item.Extension.Equals(&quot;.exe&quot;, StringComparison.OrdinalIgnoreCase))
    {
    //MessageHelper.DisplayInformation(context, string.Format(&quot;Build output of {0} contains: {1}.&quot;, projectName, item.Name));
    items.Add(item);

    var config = new FileInfo(Path.Combine(item.DirectoryName, item.Name + &quot;.config&quot;));
    if (config.Exists)
    {
    //MessageHelper.DisplayInformation(context, string.Format(&quot;Build output of {0} contains: {1}.&quot;, projectName, config.Name));
    items.Add(item);
    }

    var pdb = new FileInfo(Path.Combine(item.DirectoryName, Path.GetFileNameWithoutExtension(item.FullName) + &quot;.pdb&quot;));
    if (pdb.Exists)
    {
    items.Add(item);
    }

    var xml = new FileInfo(Path.Combine(item.DirectoryName, Path.GetFileNameWithoutExtension(item.FullName) + &quot;.xml&quot;));
    if (xml.Exists)
    {
    items.Add(item);
    }
    }
    }
    else
    {
    //MessageHelper.DisplayWarning(context, string.Format(&quot;Primary Output items not found for project {0}: {1}.&quot;, projectName, line));
    }
    }
    }
    }
    }
    else
    {
    //MessageHelper.DisplayWarning(context, string.Format(&quot;SCRM: No FileListAbsolute found for project ‘{0}’&quot;, projectName));
    }
    }

    /// &lt;summary&gt;
    ///
    /// &lt;/summary&gt;
    /// &lt;param name=&quot;configuration&quot;&gt;Build’s Configuration: Debug or Release&lt;/param&gt;
    /// &lt;param name=&quot;platform&quot;&gt;Build’s Target Platform: Any CPU or x86&lt;/param&gt;
    /// &lt;param name=&quot;projectFileName&quot;&gt;Visual Studio Project filename&lt;/param&gt;
    /// &lt;param name=&quot;projectPath&quot;&gt;Visual StudioProject path&lt;/param&gt;
    /// &lt;returns&gt;The path of the FileListAbsolute.txt file.&lt;/returns&gt;
    /// &lt;remarks&gt;This file should be located under /obj/{platform}/{configuration/}.
    /// But we also check the parent folders if the file is not found where expected.
    /// We did indeed experienced problem to locate this file for Builds with &quot;Mixed Plateform&quot; Target.&lt;/remarks&gt;
    private static string GetFileListAbsolute(string configuration, string platform, string projectFileName, string projectPath)
    {
    var fileListAbsoluteName = projectFileName + &quot;.FileListAbsolute.txt&quot;;
    var fileListAbsolutePath = Path.Combine(projectPath, &quot;obj&quot;, platform, configuration, fileListAbsoluteName);
    if (!File.Exists(fileListAbsolutePath))
    {
    fileListAbsolutePath = Path.Combine(projectPath, &quot;obj&quot;, configuration, fileListAbsoluteName);
    if (!File.Exists(fileListAbsolutePath))
    {
    fileListAbsolutePath = Path.Combine(projectPath, &quot;obj&quot;, fileListAbsoluteName);
    if (!File.Exists(fileListAbsolutePath))
    {
    fileListAbsolutePath = null;
    }
    }
    }

    return fileListAbsolutePath;
    }
    }

    /// &lt;summary&gt;
    /// This Visual Studio Solution file Parser can be used to retrieve lists of projects in a Solution.
    /// The first list contains all projects that can be built with MSBuild.
    /// The second list contains all the other projects.
    /// &lt;/summary&gt;
    /// &lt;remarks&gt;
    /// Based on http://stackoverflow.com/questions/707107/library-for-parsing-visual-studio-solution-files.
    /// It’s a wrapper on Microsoft Build’s internal class &quot;SolutionParser&quot;
    /// &lt;/remarks&gt;
    public class SolutionParser
    {
    static readonly Type s_SolutionParser;
    static readonly PropertyInfo s_SolutionParser_solutionReader;
    static readonly MethodInfo s_SolutionParser_parseSolution;
    static readonly PropertyInfo s_SolutionParser_projects;

    public List&lt;SolutionProject&gt; MSBuildProjects { get; private set; }
    public List&lt;SolutionProject&gt; OtherProjects { get; private set; }

    static SolutionParser()
    {
    s_SolutionParser = Type.GetType(&quot;Microsoft.Build.Construction.SolutionParser, Microsoft.Build, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&quot;, false, false);
    if (s_SolutionParser != null)
    {
    s_SolutionParser_solutionReader = s_SolutionParser.GetProperty(&quot;SolutionReader&quot;, BindingFlags.NonPublic | BindingFlags.Instance);
    s_SolutionParser_projects = s_SolutionParser.GetProperty(&quot;Projects&quot;, BindingFlags.NonPublic | BindingFlags.Instance);
    s_SolutionParser_parseSolution = s_SolutionParser.GetMethod(&quot;ParseSolution&quot;, BindingFlags.NonPublic | BindingFlags.Instance);
    }
    }

    public SolutionParser(string solutionFileName)
    {
    if (s_SolutionParser == null)
    {
    throw new InvalidOperationException(&quot;Cannot find type ‘Microsoft.Build.Construction.SolutionParser’ are you missing a assembly reference to ‘Microsoft.Build.dll’?&quot;);
    }
    var solutionParser = s_SolutionParser.GetConstructors(BindingFlags.Instance | BindingFlags.NonPublic).First().Invoke(null);
    using (var streamReader = new StreamReader(solutionFileName))
    {
    s_SolutionParser_solutionReader.SetValue(solutionParser, streamReader, null);
    s_SolutionParser_parseSolution.Invoke(solutionParser, null);
    }
    MSBuildProjects = new List&lt;SolutionProject&gt;();
    OtherProjects = new List&lt;SolutionProject&gt;();
    var array = (Array)s_SolutionParser_projects.GetValue(solutionParser, null);
    for (int i = 0; i &lt; array.Length; i++)
    {
    SolutionProject project = new SolutionProject(array.GetValue(i));

    if (project.ProjectType == &quot;KnownToBeMSBuildFormat&quot;)
    MSBuildProjects.Add(project);
    else
    OtherProjects.Add(project);
    }
    }
    }

    /// &lt;summary&gt;
    /// This class represent a Visual Studio Project member of a Solution.
    /// &lt;/summary&gt;
    /// &lt;remarks&gt;
    /// It’s a wrapper on Microsoft Build’s internal class &quot;ProjectInSolution&quot;
    /// &lt;/remarks&gt;
    [DebuggerDisplay(&quot;{ProjectName}, {RelativePath}, {ProjectGuid}, {ProjectType}&quot;)] public class SolutionProject
    {
    static readonly Type s_ProjectInSolution;
    static readonly PropertyInfo s_ProjectInSolution_ProjectName;
    static readonly PropertyInfo s_ProjectInSolution_RelativePath;
    static readonly PropertyInfo s_ProjectInSolution_ProjectGuid;
    static readonly PropertyInfo s_ProjectInSolution_ProjectType;

    static SolutionProject()
    {
    s_ProjectInSolution = Type.GetType(&quot;Microsoft.Build.Construction.ProjectInSolution, Microsoft.Build, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a&quot;, false, false);
    if (s_ProjectInSolution != null)
    {
    s_ProjectInSolution_ProjectName = s_ProjectInSolution.GetProperty(&quot;ProjectName&quot;, BindingFlags.NonPublic | BindingFlags.Instance);
    s_ProjectInSolution_RelativePath = s_ProjectInSolution.GetProperty(&quot;RelativePath&quot;, BindingFlags.NonPublic | BindingFlags.Instance);
    s_ProjectInSolution_ProjectGuid = s_ProjectInSolution.GetProperty(&quot;ProjectGuid&quot;, BindingFlags.NonPublic | BindingFlags.Instance);
    s_ProjectInSolution_ProjectType = s_ProjectInSolution.GetProperty(&quot;ProjectType&quot;, BindingFlags.NonPublic | BindingFlags.Instance);
    }
    }

    public string ProjectName { get; private set; }
    public string RelativePath { get; private set; }
    public string ProjectGuid { get; private set; }
    public string ProjectType { get; private set; }

    public SolutionProject(object solutionProject)
    {
    this.ProjectName = s_ProjectInSolution_ProjectName.GetValue(solutionProject, null) as string;
    this.RelativePath = s_ProjectInSolution_RelativePath.GetValue(solutionProject, null) as string;
    this.ProjectGuid = s_ProjectInSolution_ProjectGuid.GetValue(solutionProject, null) as string;
    this.ProjectType = s_ProjectInSolution_ProjectType.GetValue(solutionProject, null).ToString();
    }
    }

    /// &lt;summary&gt;
    /// List of known project type Guids from http://www.mztools.com/articles/2008/mz2008017.aspx
    /// + BizTalk: http://winterdom.com/2008/12/biztalkserver2009msbuildtasks
    /// + Workflow 4.0
    /// &lt;/summary&gt;
    public enum ProjectType
    {
    [Description(&quot;{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}&quot;)] Windows_CSharp,
    [Description(&quot;{F184B08F-C81C-45F6-A57F-5ABD9991F28F}&quot;)] Windows_VBNET,
    [Description(&quot;{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}&quot;)] Windows_VisualCpp,
    [Description(&quot;{349C5851-65DF-11DA-9384-00065B846F21}&quot;)] Web_Application,
    [Description(&quot;{E24C65DC-7377-472B-9ABA-BC803B73C61A}&quot;)] Web_Site,
    [Description(&quot;{F135691A-BF7E-435D-8960-F99683D2D49C}&quot;)] Distributed_System,
    [Description(&quot;{3D9AD99F-2412-4246-B90B-4EAA41C64699}&quot;)] Windows_Communication_Foundation_WCF,
    [Description(&quot;{60DC8134-EBA5-43B8-BCC9-BB4BC16C2548}&quot;)] Windows_Presentation_Foundation_WPF,
    [Description(&quot;{C252FEB5-A946-4202-B1D4-9916A0590387}&quot;)] Visual_Database_Tools,
    [Description(&quot;{A9ACE9BB-CECE-4E62-9AA4-C7E7C5BD2124}&quot;)] Database,
    [Description(&quot;{4F174C21-8C12-11D0-8340-0000F80270F8}&quot;)] Database_other_project_types,
    [Description(&quot;{3AC096D0-A1C2-E12C-1390-A8335801FDAB}&quot;)] Test,
    [Description(&quot;{20D4826A-C6FA-45DB-90F4-C717570B9F32}&quot;)] Legacy_2003_Smart_Device_CSharp,
    [Description(&quot;{CB4CE8C6-1BDB-4DC7-A4D3-65A1999772F8}&quot;)] Legacy_2003_Smart_Device_VBNET,
    [Description(&quot;{4D628B5B-2FBC-4AA6-8C16-197242AEB884}&quot;)] Smart_Device_CSharp,
    [Description(&quot;{68B1623D-7FB9-47D8-8664-7ECEA3297D4F}&quot;)] Smart_Device_VBNET,
    [Description(&quot;{14822709-B5A1-4724-98CA-57A101D1B079}&quot;)] Workflow_30_CSharp,
    [Description(&quot;{D59BE175-2ED0-4C54-BE3D-CDAA9F3214C8}&quot;)] Workflow_30_VBNET,
    [Description(&quot;{06A35CCD-C46D-44D5-987B-CF40FF872267}&quot;)] Deployment_Merge_Module,
    [Description(&quot;{3EA9E505-35AC-4774-B492-AD1749C4943A}&quot;)] Deployment_Cab,
    [Description(&quot;{978C614F-708E-4E1A-B201-565925725DBA}&quot;)] Deployment_Setup,
    [Description(&quot;{AB322303-2255-48EF-A496-5904EB18DA55}&quot;)] Deployment_Smart_Device_Cab,
    [Description(&quot;{A860303F-1F3F-4691-B57E-529FC101A107}&quot;)] Visual_Studio_Tools_for_Applications_VSTA,
    [Description(&quot;{BAA0C2D2-18E2-41B9-852F-F413020CAA33}&quot;)] Visual_Studio_Tools_for_Office_VSTO,
    [Description(&quot;{F8810EC1-6754-47FC-A15F-DFABD2E3FA90}&quot;)] SharePoint_Workflow,
    [Description(&quot;{6D335F3A-9D43-41b4-9D22-F6F17C4BE596}&quot;)] XNA_Windows,
    [Description(&quot;{2DF5C3F4-5A5F-47a9-8E94-23B4456F55E2}&quot;)] XNA_XBox,
    [Description(&quot;{D399B71A-8929-442a-A9AC-8BEC78BB2433}&quot;)] XNA_Zune,
    [Description(&quot;{EC05E597-79D4-47f3-ADA0-324C4F7C7484}&quot;)] SharePoint_VBNET,
    [Description(&quot;{593B0543-81F6-4436-BA1E-4747859CAAE2}&quot;)] SharePoint_CSharp,
    [Description(&quot;{A1591282-1198-4647-A2B1-27E5FF5F6F3B}&quot;)] Silverlight,
    [Description(&quot;EF7E3281-CD33-11D4-8326-00C04FA0CE8D&quot;)] BizTalk,
    [Description(&quot;32f31d43-81cc-4c15-9de6-3fc5453562b6&quot;)] Workflow_40
    };

    /// &lt;summary&gt;
    /// Helper Class to manage Visual Studio Project’s types
    /// &lt;/summary&gt;
    public static class ProjectTypeExtensions
    {
    public static Guid ToGuid(this ProjectType val)
    {
    DescriptionAttribute[] attributes = (DescriptionAttribute[])val.GetType().GetField(val.ToString()).GetCustomAttributes(typeof(DescriptionAttribute), false);
    return attributes.Length &gt; 0 ? Guid.Parse(attributes[0].Description) : Guid.Empty;
    }

    public static ProjectType Parse(string val)
    {
    return Parse(Guid.Parse(val));
    }

    public static ProjectType Parse(Guid val)
    {
    ProjectType? type = null;
    FieldInfo[] fis = typeof(ProjectType).GetFields();
    foreach (FieldInfo fi in fis)
    {
    DescriptionAttribute[] attributes = (DescriptionAttribute[])fi.GetCustomAttributes(typeof(DescriptionAttribute), false);
    if (attributes.Length &gt; 0)
    {
    if (Guid.Parse(attributes[0].Description) == val)
    {
    if (Enum.IsDefined(typeof(ProjectType), fi.Name))
    type = (ProjectType)Enum.Parse(typeof(ProjectType), fi.Name);
    break;
    }
    }
    }
    if (type.HasValue)
    return type.Value;
    else
    throw new FormatException(string.Format(&quot;'{0}’ is not a valid Project Type’s Guid&quot;, val.ToString()));
    }

    public static List&lt;ProjectType&gt; GetMSBuildProjectTypes(string localProject)
    {
    var projectCollection = new ProjectCollection();
    Project project;
    try
    {
    project = projectCollection.LoadProject(localProject);
    }
    catch (Exception ex)
    {
    throw new Exception(string.Format(&quot;Project Type cannot be determined as ‘{0}’ is not a valid VS project.&quot;, localProject), ex);
    }

    var projectTypes = GetMSBuildProjectTypes(project);

    projectCollection.UnloadAllProjects();

    return projectTypes;
    }

    public static List&lt;ProjectType&gt; GetMSBuildProjectTypes(Project project)
    {
    try
    {
    var projectTypeGuids = (from property in project.Properties
    where property.Name == &quot;ProjectTypeGuids&quot;
    select property.EvaluatedValue).FirstOrDefault();

    List&lt;ProjectType&gt; projectTypes;
    if (string.IsNullOrEmpty(projectTypeGuids))
    projectTypes = new List&lt;ProjectType&gt;();
    else
    projectTypes = (from guid in projectTypeGuids.Split(‘;’) select Parse(guid)).ToList();

    return projectTypes;
    }
    catch (Exception ex)
    {
    throw new Exception(string.Format(&quot;Unable to determine the project type of ‘{0}’ due to: {1}&quot;, Path.GetFileNameWithoutExtension(project.FullPath), ex.Message));
    }
    }
    }
    }
    [/csharp]

    Loading

    ,
  • Target multiple environments with only one TFS Build Server

    I had customize our Build Process Template to support multiple target environments on a single Build Machine. I.e.: to resolve the “file references” at Build time depending on the environment targeted for the deployment.

    Click to Read More

    At work, we have mainly four distinct environments: Integration, Qualification, Pre-Production and Production. Each application (and its referenced assemblies) are promoted from one environment to the next one via tasks (Release Distribution jobs) scheduled according to a predefined monthly Release Plan…

    TFS Build Machines not only compile the applications to be deployed via the standard Release Distribution, but also the urgent fixes to be deployed directly in Pre-Production without passing through Integration and Qualification environments. It also happens, although really quite seldom, that a Build skips the Integration and goes directly to Qualification.

    It’s also to be noticed that none of our applications (assemblies) are strong named and deployed in the GAC, neither on development workstations nor on servers. Instead, all referenced assemblies are always copied within the application’s bin folders, also on the servers.

    Therefore, basically, we would need Build Machines dedicated for each target environment with the adequate assemblies made available on them, for reference resolution purpose. That would be a pity to have such Build Machines (and the related setup, maintenance, backup costs, …) for at most one build per month (Fix in Production and Qualification are fortunately not common).

    To avoid that,  I did customize our Build Process Template to take a Reference Path as input and to pass it to MSBuild. Actually, when editing a Build Definition, the Builder can select the target Environment, and the Build will simply receive a path to the location containing the related assemblies.

    Ex.: MSBuild mySolution.sln /p:ReferencePath=”c:\RefAssemblies\Qualification\”

    How can I be sure that this Reference Path won’t interfere with any Hint Paths defined in the Visual Studio projects?

    First, note that the location provided to MSBuild via the “ReferencePath” parameter will be probed to resolve all “file references” before any other location on the standard probing path. But we also pay attention to not make the assemblies available on the Hint Path on the Build Machines:

    • On Development Workstations, all our assemblies are made available in a single “Reference Assemblies” folder. Developers add references on assemblies in there for development and local testing purpose. They can also start a task at will to update this “Reference Assemblies” folder with the latest version of the assemblies (the versions used in the Integration Environment) or with the version currently deployed in the Qualification or Production Environments (e.g.: for bug fixing purpose).
    • On the Build Machines, there is one “Reference Assemblies” folder per environment (i.e.: updated by the Release Distribution with the assemblies currently in use in that environment). None of those folders is located at the same path as the “Reference Assemblies” folder of the Development Workstations. As a result, MSBuild cannot use the Hint Paths found in the Visual Studio projects to locate the referenced assemblies. Instead, it uses the path of the “Reference Assemblies” folder passed to it via its parameter /p:ReferencePath.

    In addition to the “Reference Assemblies” folders per environment, we also have one  extra folder containing the output of each latest successful Build. This one is used for “Continuous Integration“. No need to update the references in the Visual Studio Projects, MSBuild always find in that folder the latest version of each assembly recently built on any Build Machine (if requested to do so via the Build Definition). This is by the way the default “target environment” for all “Rolling Builds” defined on “Development Branches”, so any breaking features in a new version of a referenced assembly is immediately detected. Builds “candidate” to be promoted use by default the Reference Path with the assemblies from the Integration environment.

    Loading

    ,