Welcome to EMC Consulting Blogs

So, there’s been a bit of storm blowing through the part of the InterWeb that I inhabit recently – see http://blog.benday.com/archive/2009/07/27/23233.aspx for the low-down.

I’ve seen these types of discussions countless times, both online and in the real world – the thing that wears me down the most is the seemingly constant assertion that ‘SVN/Git/Mercurial = TFS’, as if source control is the only consideration.

Let me lay down a couple points of order before I get flamed to oblivion:

1. I’ve generalised this assertion, somewhat
2. I’ve spent time using both SVN and Git and like them both
3. I have no desire to sound like a Microsoft shill!

Fundamentally, SVN and TFS are implementations of a centralised version control system (VCS) that are designed using polar-opposite philosophies – TFS is server-centric whilst SVN is client-centric.  The reality is that both of these approaches have advantages and disadvantages in terms of usability and performance.

Regarding the centralised versus distributed debate, I actually like a lot of things about Git et. al. and I would guess that as the various tooling/integration stories develop we will see more corporate and enterprise adoption.

Getting to my point though, most of the customers I talk to rarely arrive at the TFS ‘answer’ on the basis of a VCS selection process (those that have, usually get a suggestion from me to look at other open source alternatives), they get there because they are looking for something to satisfy their Application Lifecycle Management (ALM) needs – I consider TFS to be pretty cost-effective in the ALM space.  Granted, there is a sizable chunk of TFS adopters who migrate from Visual SourceSafe (and are pre-disposed to use Microsoft tools) but as a like-for-like swap Microsoft have, in general terms, made that migration relatively painless.

However, increasingly we’re seeing customers who have arrived at the TFS ‘answer’ because they use Scrum to manage their development projects and have chosen Scrum for Team System (a TFS process template we make available for free) as their preferred project management tool - and from their perspective TFS comes with the added bonus of not having to worry about selecting and integrating a separate VCS and automated build system.

A customer recently contacted me saying that they had upgraded to Visual Studio 2008 and had also taken the opportunity to switch from a Web Site Project to a Web Application Project.  A while back I'd helped them to centralise some of their configuration so that they only had a single copy of all the configuration sections that were referenced by multiple projects (e.g. the web site, various unit test projects etc.).

This involved creating separate configuration files for each section and referencing them from the main web/app config using the 'configSource' attribute, for example:

The above referenced configuration file would something like this:

Due to the 'configSource' attribute not supporting relative paths, it was necessary to setup pre-Build events to copy the referenced files into the project folder - especially for the Web Site project where a valid web.config is required by the ASPNET compiler.

After the switch to the Web Application project model the client was wondering whether they needed to change how they were handling these shared configuration files.  My initial response was to suggest that they discontinue the pre-build scripts and instead use the 'linked files' feature that was available with web application projects (much like they have been for other types of projects a long time).

For those of you unfamiliar with this useful feature, here's how you add a linked file via the 'Add Existing Item' option:

Such files appear in Solution Explorer as normal project items, albeit with a shortcut icon.

However, after trying it, they reported that those files were missing from the web site which was causing all manner of problems.

It turns out that when you build the project linked files are not copied into the project folder, which is obviously a problem as it means that the file is not available to the web site at runtime.  Your first thought might be to enable the 'Copy Local' option for the linked files, however, all this does is to copy the linked files to the 'bin' folder... not exactly the result we're after.

Before carrying on, it's worth looking at how the linked items are stored in the actual web application project file, as it will later help us understand why this issue occurs.

From this you can see the main path for the item (the 'Include' attribute) is a relative path to the shared configuration file, whilst the 'Link' attribute tells Visual Studio where the item exists within the project - in this case, the file was added to the root of the project.

To investigate further I took a look at the 'Microsoft.WebApplication.targets' file that contains the Web Application project build process and typically lives in the 'C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications' folder.  There I found a target called '_CopyWebApplication' which only gets executed when the output directory has been overridden (e.g. what TeamBuild does to redirect all build outputs into a single directory):

At the end of this Target there is the following call to the MSBuild Copy task:

So when the above Copy task executes it's going to use the relative path to the linked item as part of the destination path, rather than the path within the project (i.e. the 'Link' attribute) - so this explains why the files aren't getting copied:

1. When building in Visual Studio, nothing special happens to copy the content files (linked or otherwise)
2. When redirecting the output path, normal Content files are copied fine (their 'Include' attribute does not contain a relative path), but the linked content files will get copied to a folder with the same relative path to the actual output folder, as the linked item has to the project file (e.g. 'MyOutDir\..\..\dbConfig.config' instead of 'MyOutDir\dbConfig.config')

Anyway, let's cut to the chase... here is my suggested workaround:

1. Fix the 'Copy' task to not include linked files
2. Create another target to handle the copying of linked files using the correct destination path

To achieve the first, we'll need to override the built-in '_CopyWebApplication' target by pasting it into our web application's project file and tweaking the 'Copy' task mentioned above:

  <!--

  ============================================================

  _CopyWebApplication

  MODIFIED: Ignores linked files as part of normal deployment logic.

  This target will copy the build outputs along with the

  content files into a _PublishedWebsites folder.

  This Task is only necessary when $(OutDir) has been redirected

  to a folder other than ~\bin such as is the case with Team Build.

  ============================================================

  -->

  <Target Name="_CopyWebApplication" Condition="'$(OutDir)' != '$(OutputPath)'">

    <!-- Log tasks -->

    <Message Text="Copying Web Application Project Files for $(MSBuildProjectName)" />

    <!-- Create the _PublishedWebsites\app\bin folder -->

    <MakeDir Directories="$(WebProjectOutputDir)\bin" />

    <!-- Copy build outputs to _PublishedWebsites\app\bin folder -->

    <Copy SourceFiles="@(IntermediateAssembly)"

          DestinationFolder="$(WebProjectOutputDir)\bin"

          SkipUnchangedFiles="true" />

    <Copy SourceFiles="@(AddModules)"

          DestinationFolder="$(WebProjectOutputDir)\bin"

          SkipUnchangedFiles="true" />

    <Copy SourceFiles="$(IntermediateOutputPath)$(_SGenDllName)"

          DestinationFolder="$(WebProjectOutputDir)\%(Content.SubFolder)%(Content.RecursiveDir)"

          SkipUnchangedFiles="true"

          Condition="'$(_SGenDllCreated)'=='true'" />

    <Copy SourceFiles="$(IntermediateOutputPath)$(TargetName).pdb"

          DestinationFolder="$(WebProjectOutputDir)\bin"

          SkipUnchangedFiles="true"

          Condition="'$(_DebugSymbolsProduced)'=='true'" />

    <Copy SourceFiles="@(DocFileItem)"

          DestinationFolder="$(WebProjectOutputDir)\bin"

          SkipUnchangedFiles="true"

          Condition="'$(_DocumentationFileProduced)'=='true'" />

    <Copy SourceFiles="@(IntermediateSatelliteAssembliesWithTargetPath)"

          DestinationFiles="@(IntermediateSatelliteAssembliesWithTargetPath->'$(WebProjectOutputDir)\bin\%(Culture)\$(TargetName).resources.dll')"

          SkipUnchangedFiles="true" />

    <Copy SourceFiles="@(ReferenceComWrappersToCopyLocal); @(ResolvedIsolatedComModules); @(_DeploymentLooseManifestFile); @(NativeReferenceFile)"

          DestinationFolder="$(WebProjectOutputDir)\bin"

          SkipUnchangedFiles="true" />

    <!-- copy any referenced assemblies to _PublishedWebsites\app\bin folder -->

    <Copy SourceFiles="@(ReferenceCopyLocalPaths)"

          DestinationFolder="$(WebProjectOutputDir)\bin"

          SkipUnchangedFiles="true" />

    <!-- MODIFICATION HERE: Copy local content files (i.e. non-linked files) recursively to _PublishedWebsites\app\ folder -->

    <Copy Condition=" '%(Content.Link)' == '' "

          SourceFiles="%(Content.Identity)"

          DestinationFolder="$(WebProjectOutputDir)\%(Content.RelativeDir)" />

  </Target>

For the second, we need to add a new target to our project file and override the default dependencies to have it executed:

  <!--

  ============================================================

  CopyLinkedContentFiles

  A new target to copy any linked content files into the

  web application output folder.

  NOTE: This is necessary even when '$(OutDir)' has not been redirected.

  ============================================================

  -->

  <Target Name="CopyLinkedContentFiles">

    <!-- Remove any old copies of the files -->

    <Delete Condition=" '%(Content.Link)' != '' AND Exists('$(WebProjectOutputDir)\%(Content.Link)') "

            Files="$(WebProjectOutputDir)\%(Content.Link)" />

    <!-- Copy linked content files recursively to the project folder -->

    <Copy Condition=" '%(Content.Link)' != '' "

          SourceFiles="%(Content.Identity)"

          DestinationFiles="$(WebProjectOutputDir)\%(Content.Link)" />

  </Target>

  <!-- Override the default target dependencies to -->

  <!-- include the new _CopyLinkedContentFiles target. -->

  <PropertyGroup>

    <PrepareForRunDependsOn>

      $(PrepareForRunDependsOn);

      _CopyWebApplication;

      CopyLinkedContentFiles;

      _BuiltWebOutputGroupOutput

    </PrepareForRunDependsOn>

  </PropertyGroup>

With these changes, whenever you build the web project any linked content files will be copied into the web application's folder structure  - whether you override the default output directory or not.

If anyone is interested I've attached a sample solution that demonstrates the above workaround (as well as an unmodified project file so you can see the issue).

Part of me wonders whether this is a bug at all, or whether it is in fact just an unexpected feature that was never supposed to be supported... I've raised a bug on Connect, so I guess I'll find out in due course.

This post started out as a comment on one of Jamie's recent posts, however, I realised that the explanation would be easier to follow with screenshots... so here we go.

To paraphrase, Jamie's issue was that whilst trying to use an SSIS package he was getting a DCOM access denied error (full details here) - this had worked in previous environments, but not once it got to Production.  The eventual solution that got everything working was to make the account running the package a local administrator (as it was in other environments) and reboot the server.

Whilst this obviously got things working, what I'd like to illustrate here is a more secure way of overcoming this type of issue - as a platform guy, developer code running with full admin rights makes me twitchy!

DCOM security is managed using the 'Component Services' MMC snap-in, a shortcut to which is 'Start -> Run -> DCOMCNFG'

The next step is locate the component that needs to have its security tweaked.  Jamie's post shows how to use the CLSID from the error message to locate the registration information for the component in the Registry.

The value of the ''AppID' key is the surefire way of locating the component in DCOMCNFG, however, this is only visible from the component's property page - so ideally you want to find
the component by name.  However, the names in DCOMCNFG do not necessarily exactly match those in the registry (typically it's a substring).

Armed with the AppID and some ideas about the component name, return to DCOMCNFG and start hunting:

Once you've found a candiate, open its properties and verify the AppID

If you've found it, select the 'Security' tab, select 'Customize' and 'Edit..' under 'Launch and Activation Permissions', and grant the required user the rights requested in the original error message.

Now you should be good to go. (complete with that warm and fuzzy feeling that you get from knowing that you haven't unduly compromised server security)
 

Whilst trying to finalise some unattended server build scripts for deploying BizTalk 2006 into a multi-server environment I hit the following error when trying to configure the 'BAM Tools':

This despite the fact that the SQL Server Management Tools had in fact already been installed.

A bit of Googling revealed other people who had seen the same issue, but with no solution.  So I cast my net a little wider and found this posting indicating an issue with DTS.CustomTask that was resolved in SQL 2000 SP2.  I had already installed SP4 (a pre-req for running BizTalk 2006 on SQL 2000), but this got me wondering whether it had installed properly.

We were using unattended installs of SQL Server that had previously been created, and thus far, had assumed that all was well with them - it turned out that there was a problem with the unattended SP4 install when run against a partial install of SQL Server (i.e. a Management Tools only install).

One manual re-install of SP4 later and the error vanished.... happy days.

Finally, all that was left to do was to record a new 'setup.iss' file for SP4 against the partial SQL install and we were good to go.... not before time!

I'd heard about this forthcoming edition of Visual Studio 2005 Team System (Team Edition for Database Professionals) a while back but was reminded by Jamie's recent post to actually download the CTP and give it a whirl.

After a painless installation, I cranked-up VSTS, created a new 'SQL Server 2000' project and clicked on the 'Import Database Schema' with much anticipation.... only to be met with a rather abrupt and anti-climatic 'object reference not set' error:

After an unsuccessful bit of Googling, and an uninstall/reboot/install cycle I eventually discovered that the import functionality worked fine when running with local Administrator rights, but not when using my everyday unprivileged account - irrespective of any other SQL-related permissions.

So now I'll make sure that I run the ever useful 'MakeMeAdmin' before doing this sort of thing again.

Incidentally, running VS2005 without admin rights is officially supported (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vs05security.asp), and to-date has worked well for me - a definite improvement on VS.NET 2003 in this respect.

So last week I had my first official introduction to Visual Studio Team System (VSTS) and Team Foundation Server (TFS) when I attended a 'VSTS Readiness Workshop' that was co-led by Joel.

By Day 2 we'd started looking at the new source control system that ships with TFS and I was keen to see how the new/improved features (database back-end, concurrent check-out, transactional check-ins aka changesets  etc.) might affect our approach to versioning and release management - in particular I was interested to see how much the branch/merge functionality had been improved.

One of the main differences is that creating a branch does not immediately result in a duplicates of each affected object (and thus double the storage requirements) - initially the branch contains links to the files, and only when a file is actually changed in the branch does a new version get created. With this in mind, I set about simulating a typical scenario to put the merge/branch functionality through its paces - and got some 'interesting' results.

The scenario (and resulting issue) is summarised below:

As you can see above, Class1.cs in 'Sprint 2' has been overwritten by the version in 'Sprint 1' and the all the new methods have been lost. It seems that TFS assumes that a merge operation should result in identical files, which of course is not necessarily the case.

I'd be interested to hear from anyone who cannot recreate the above issue - I also plan to re-test this scenario using the December CTP version of TFS that was recently released to see if it behaves differently.

As previously discussed by Simon, there are issues with pointing MSBuild at a Visual Studio solution file to build your project assemblies - the alternatives are to either build each of the projects individually (using <MSBuild/> tasks) or to call VS itself to build the solution (the SDC Build Tools project has a custom task to easily do this).

The former approach causes some maintenance headaches by requiring the MSBuild script to be updated anytime a project is added or removed from the solution - whereas the latter option means you must have Visual Studio installed (which was supposed to be one of the benefits of using MSBuild) and can also result in some referencing issues the first time you build a solution after project changes.

In order to try and get the best of boths worlds, I started thinking about dynamically generating an MSBuild script with all the tasks needed to build each VS project referenced by the targetted .sln file (i.e. the first of the above approaches, but with all the leg-work automated).  My preferred tool for such things (since being introduced to it by Howard) is the excellent CodeSmith .

By running the template below prior to calling MSBuild, the tasks needed to build all the Solution's projects are written to a .targets file that can be <Import'd by the main MSBuild script - in my case this 2-step process is wrapped by a simple batch file that gets called by CruiseControl.

<%--
Description: Generates an MSBuild script to build each of the Visual Studio
             projects found within the specified Visual Studio Solution file.
%>
<%@ CodeTemplate Language="C#" TargetLanguage="Text" Src="" Inherits="" Debug="False" Description="Generate MSBuild actions from Solution file" %>

<%@ Property Name="SolutionFile" Type="System.String" Default="" Optional="False" Category="Strings" Description="VS.NET Solution file to process" %>

<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<%@ Import Namespace="System.Text.RegularExpressions" %>

<%
if ( !File.Exists(this.SolutionFile) )
{
    throw new ArgumentException("ERROR:\nUnable to find the VS.NET Solution file:\n" + this.SolutionFile);
}
else
{
    this.SolutionFile = Path.GetFullPath(this.SolutionFile);
}
%>
<?xml version="1.0" encoding="utf-8" ?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="BuildProjects">
<%
string contents;
using ( StreamReader sr = new StreamReader(this.SolutionFile) )
{
    contents = sr.ReadToEnd();
}

// The regular expression below extracts the project information from
// the relevant part of the solution file - the format of which seems to
// be the same in VS 2003 & 2005
Regex regex = new Regex("^Project\\(.*\\s=\\s\"(?<projectName>.*)\",\\s\"(?<projectPath>.*)\",");
MatchCollection matches = regex.Matches(contents);
if ( matches.Count > 0 )
{
    foreach ( Match match in matches )
    {
        string projectName = match.Groups["projectName"].Value;
        string projectPath = match.Groups["projectPath"].Value;
        Trace.WriteLine( string.Format("ProjectName: {0}\nProjectPath: {1}", projectName, projectPath) );
       
        // Make sure that the reference in the .sln file is really a project
        // and not just a Solution Folder
        if ( projectName != projectPath && projectPath.EndsWith("proj") )
        {
        %>
            <MSBuild Projects="<%=Path.Combine(Path.GetDirectoryName(this.SolutionFile),projectPath)%>" Targets="Clean;Rebuild" />
        <%
        }
    }
}
else
{
    throw new ApplicationException( string.Format("ERROR:\nThe specified Solution file contains no projects:\n{0}", this.SolutionFile) );
}
%>
    </Target>
</Project>

<script runat="template">
</script>