I was on StackOverflow today and noticed a question along these lines “How to I create a target which is executed when CoreCompile is, and that is skipped when CoreCompile is skipped?” Below is my answer.

This is a tricky problem to solve for the general case, but it is pretty easy in your case because CoreCompile has special built in support for this scenario. Before I go into the details of how you can accomplish this with CoreCompile let me explain how it works in general.

Explanation of the general case

In MSBuild targets are skipped due to Incremental Building. Incremental Build is driven purely off of the Inputs and Outputs attributes on the Target itself. The inputs are a list of files that the target will "use" and the outputs are a list of files that are "generated" by the target. I'm using quotes because its a loose concept not a concrete one. To simplify it you can just treat inputs/outputs as lists of files. When the target is about to be executed MSBuild will take the inputs and compare the timestamps of them to the outputs. If all the outputs are newer then the inputs then the target will be skipped. (FYI If you want to know what happens when only some outputs are out-of-date read my blog athttp://sedodream.com/2010/09/23/MSBuildYouveHeardOfIncrementalBuildingButHaveYouHeardOfPartialBuilding.aspx).

In any case if you want a target to be skipped you have to craft your Inputs/Outputs correctly. In your case you want to skip your target whenever the CoreCompile is skipped, so at the surface it would seem that you could simply copy the Inputs/Outputs of CoreCompile but that doesn't work. It doesn't work because when CoreCompile is executed the files may be out-of-date but that target itself brings them up-to-date. Then when you target is executed since they are all up-to-date it will be skipped. You would have to copy the Inputs/Outputs and append an additional file to inputs/outputs which you target creates. This would ensure that your target wouldn't get skipped during that first pass.

Specific solution for CoreCompile

If you take a look at the project file you will see towards the bottom that the file Microsoft.Common.targets is Imported, this file will then import the language specific .targets file. For example it will Import either Microsoft.CSharp.targets or Microsoft.VisualBasic.targets (if you are using C# or VB). In those .targets files you will find CoreCompile defined. In the definition for CoreCompile you will find the following at the end.

<CallTarget Targets="$(TargetsTriggeredByCompilation)" Condition="'$(TargetsTriggeredByCompilation)' != ''"/>

This will call all the targets defined in the TargetsTriggeredByCompilation property. So if you want your target to be called whenever CoreCompile is executed you can extend that property. Here is how to do that.

<PropertyGroup>
  <TargetsTriggeredByCompilation>
    $(TargetsTriggeredByCompilation);
    MyCustomTarget
  </TargetsTriggeredByCompilation>
</PropertyGroup>

<Target Name="MyCustomTarget">
  <Message Text="MyCustomTarget called" Importance ="high"/>
</Target>

In this case I define the property TargetsTriggeredByCompilation and I append MyCustomTarget to it. It's very important that you include the $(TargetsTriggeredByCompilation); there, if you don't then you won't be appending but overwriting. So if anyone else used this technique you'd wipe out their target.

Below is an image showing where I build once and CoreCompile and MyCustomTarget are executed. Then the second build CoreCompile is skipped any MyCustomTarget is never called.

Sayed Ibrahim Hashimi @SayedIHashimi

If you have used the Visual Studio web publish in either VS 2010 or VS 11 to create Web Deploy packages then you probably know that we parameterize connection strings in web.config automatically. In case you are not familiar with Web Deploy parameters, they are a way to declare that you want to easily be able to update a value of something when publishing the package later on. Connection strings are good examples of something which typically needs to be updated during publish.

As I previously stated if you create a Web Deploy package in Visual Studio we will automatically create Web Deploy parameters for all your connection strings in web.config. Earlier today I saw a question on StackOverflow asking how to parameterize connection strings in non-web.config files (question actually asked something else, but I think this is what he’s really wanting). I created a sample showing how to do this. Below is what the connectionStrings element looks like in web.config.

<connectionStrings configSource="connectionStrings.config" />

And here is connectionStrings.config

<?xml version="1.0" encoding="utf-8" ?>
<connectionStrings>
  <clear/>
  <add name="ApplicationServices"
           connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true"
           providerName="System.Data.SqlClient" />
  <add name="OtherConnectionString"
       connectionString="data source=.\SQLExpress;Integrated Security=SSPI;Initial Catalog=foo"
       providerName="System.Data.SqlClient"/>
</connectionStrings>

In order to parameterize these connection strings you will have to extend the Web Publish Pipeline. To do that create a file named {project-name}.wpp.targets in the root of the project in which you are working (for VS 11 projects you can place all this directly inside of the .pubxml files). This will be an MSBuild file which will get imported into the build/publish process. Below is the file which needs to be created.

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <ItemGroup>
    <!-- Here we need to declare MSDeploy parameters for connection strings in connectionStrings.config -->
    <MsDeployDeclareParameters Include="ApplicationServices-ConnectionString" >
      <Kind>XmlFile</Kind>
      <Scope>connectionStrings.config$</Scope>
      <Match>/connectionStrings/add[@name='ApplicationServices']/@connectionString</Match>
      <Description>Connection string for ApplicationServices</Description>
      <DefaultValue>data source=(localhost);Initial Catalog=AppServices</DefaultValue>
      <Tags>SqlConnectionString</Tags>
    </MsDeployDeclareParameters>

    <MsDeployDeclareParameters Include="OtherConnectionString-ConnectionString" >
      <Kind>XmlFile</Kind>
      <Scope>connectionStrings.config$</Scope>
      <Match>/connectionStrings/add[@name='OtherConnectionString']/@connectionString</Match>
      <Description>Connection string for OtherConnectionString</Description>
      <DefaultValue>data source=(localhost);Initial Catalog=OtherDb</DefaultValue>
      <Tags>SqlConnectionString</Tags>
    </MsDeployDeclareParameters>
  </ItemGroup>

</Project>

Here you can see that I am creating values for MSDeployDeclareParameters. When you package/publish this item list is used to create the MSDeploy parameters. Below is an explanation of the metadata values each contain.

• Kind = for this case it will always be Xmlfile, learn more
• Scope = a regular expression to the file which needs to be modified
• Match = an XPath expression to the attribute/element to be updated
• Description = optional description (this will show up in the IIS manager if the pkg is imported)
• DefaultValue = optional default value for the for the parameter
• Tags = optional, for connection strings use SqlConnectionString

After you create this file you will need to close/re-open VS (it caches imported .targets files). Then you can create a web deploy package. When you do so these new parameters will be declared. In my case I then imported this in the IIS manager and here is the dialog which shows up for the parameters.

As you can see the Application Path parameter is shown there as well as my custom connection string values. When I update the values in the text box and opened connectionStrings.config on my web server they were the values I entered in the dialog box.

FYI I have uploaded this sample to my github account at ParameterizeConStringConfig.

Sayed Ibrahim Hashimi @SayedIHashimi

\I receive a lot of questions regarding web.config transforms, which have existed in Visual Studio since 2010, and wanted to clear up the support that we have in this area. These transforms show up in the solution explorer underneath web.config as shown in the image below.

Since the names of these transforms include the build configuration many people expect that web.config will be transformed when they start debugging (F5) or run the app (CTRL+F5) in Visual Studio. But sadly this is not the case. These transforms are kicked in only when the web is packaged or published. I totally agree that this would be awesome, and I even blogged about how to enable it at http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx. It may seem like it would be really easy for us to include this support in the box, but unfortunately that is not the case. The reason why we are not able to implement this feature at this time is because a lot of our tooling (and many partners) relies on web.config directly. For example when you drag and drop a database object onto a web form, it will generate a connection string into the web.config. There are a lot of features are like this. It is a significant investment for us to make a change of this level. We were not able to get this done for Visual Studio 11, but it is on our radar and we are looking to see what we can do in this area in the future.

Sayed Ibrahim Hashimi @SayedIHashimi

Have you ever tried to perform an operation on a file (i.e. delete) just to be faced with an error relating to the fact that an application is locking the file? This happens to me a lot, including just now. I was writing some code and tried to switch branches and was given the error below.

So I closed down Visual Studio as well as IIS Express as I figured those were the ones which had the lock on the file, and tried again (a few times actually ) but continued to receive the error above. In order to determine which file had a handle open to that file I downloaded Handle from the sysinternals suite. (I actually already had the items downloaded inside of a Dropbox share which I use between multiple computers.) I then executed the command handle.exe nlog and the results are shown below. Note: I had to open a command prompt window to run handle.exe, for some reason it wasn’t working from a PowerShell prompt.

As you can see there was a rogue devenv.exe process holding on to the file. After killing the process I was able to proceed.

Sayed Ibrahim Hashimi @SayedIHashimi

I’ve been using Git for my open source projects recently and have been loving it. If you are like me and you like using the PowerShell prompt instead of the normal command prompt then you have to install posh-git. posh-git extends the PowerShell prompt to include information about the git repository and also makes remote operations simpler. After using git in this way I quickly noticed that the colors were not very readable. For example take a look at the screen shot below.

In the image above you can see that the text in dark red is difficult to read. This text comes from two different places. For the text relating to modified and untracked files, that is coming directly from git.exe and for the text after [master that is coming from posh-git. In order to make this easier to read we have to modify the color settings for both.

Modifying text color settings for git.exe

When using git.exe you can configure the color settings using git config. There are a bunch of color settings which you can control, which are all listed on the manpage for git config. In my case I want to update the color for modified files and untracked files, those can be configured with color.status.changed and color.status.untracked respectively. The color options that you have to pick from include:

• normal
• black
• red
• green
• yellow
• blue
• magenta
• cyan
• white

In my case I wanted the text for those settings to be the same color as the master text in the image above. In order to set the color you can use the syntax:

git config <color-to-update> “foreground-color background-color attribute”

The attribute value can be any of these values; bold, dim, ul, blink and reverse.

In my case I executed the following command:

git config --global color.status.changed "cyan normal bold"
git config --global color.status.untracked "cyan normal bold"

Notice that I used the --global switch to indicate that I wanted the settings to be persisted in the global .gitconfig file instead of the one for the specific project that I was working on. So this got me to:

Almost there, now I need to modify the color for the summary provided by posh-git. A good resource for more info here is http://git-scm.com/book/ch7-1.html#Colors-in-Git.

Modifying text color for posh-git

posh-git stores all of it’s color settings in the $global:GitPromptSettings variable, you can see them declared in the GitPrompt.ps1 file. If you want to change the values for the colors you should not edit that file (that file might get updated later). Instead all you need to do is to override the value for the particular color after posh-git has been loaded. The best way to do this is to edit your PowerShell profile. This file is executed every time you open a PS prompt. You can find the location of this file by executing $profile in a PS prompt. In that file you should see a line initializing posh-git in my case it was:

. 'G:\Data\Development\OpenSource\posh-git\profile.example.ps1'

You should place your customizations after this statement. So in my case I wanted to change the summary text from dark red to yellow, so I added the following lines to my PS profile.

$global:GitPromptSettings.WorkingForegroundColor    = [ConsoleColor]::Yellow
$global:GitPromptSettings.UntrackedForegroundColor  = [ConsoleColor]::Yellow

I closed the PS window and opened a new one and now here is the result.

Now that’s better!

FYI if you are looking to install posh-git you can follow a simple walk through on Phil Haack’s blog at Better Git with PowerShell.

I’d like to thank Brad Wilson and Keith Dahlby for pointing me in the right direction regarding these settings.

Sayed Ibrahim Hashimi | @SayedIHashimi

My Github account

In case you are not familiar with SlowCheetah, it is a Visual Studio extension which allows you to transform app.config files in the same way that web.config files are. More info on the project page http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5.

I wanted to let everyone know that I have updated SlowCheetah to support Visual Studio 11 and I have also placed the project on github at https://github.com/sayedihashimi/slow-cheetah. Regarding the VS 11 support there is one known issue that we currently do not support the preview functionality on VS 11. This is an item which we will be fixing for the next release.

Thanks,
Sayed Ibrahim Hashimi @SayedIHashimi

Reminder: even though I work for Microsoft this is a personal project and not formally affiliated with Microsoft

If you have tried out the web publish feature in Visual Studio then you may have noticed the message seen in the image towards the end of the post in the database section.

We did not have time for VS 11 beta to light up these features, but if you want a sneak peak of the behavior then take a look at the channel 9 video I posted recently Dirt Simple Web and Database Deployment in Visual Studio 11. If you have any questions/feedback feel free to send me an email: sayedha [at] {Microsoft}dotCOM.

Thanks,

Sayed Ibrahim Hashimi @SayedIHashimi

Recently I recorded a video on Channel 9 with Brady Gaster Dirt Simple Web and Database Deployment in Visual Studio 11. In this video I show the work that we have done to enable Entity Framework Code First migrations during publish and I also cover the investments that we are making regarding incremental database schema publish when you are not using EF Code First. If you get a chance I’d love for you to watch the video and give feedback regarding the direction that we are taking with VS Web Publishing.

Thanks,
Sayed Ibrahim Hashimi @SayedIHashimi

A couple months ago I blogged about a Package-Web which is a NuGet package that extends the web packaging process in Visual Studio to enable you to create a single package which can be published to multiple environments (it captures all of your web.config transforms and has the ability to transform on non-dev machines). Since that release I have updated the project and tonight I created a video which shows the features a bit you can check it out on Youtube. It’s embedded below.

You can install this via NuGet, the package name is PackageWeb.

Package-Web is an open source project and you can find it on my github account at https://github.com/sayedihashimi/package-web.

Thanks,
Sayed Ibrahim Hashimi @SayedIHashimi

The other day I saw a question on StackOverflow (link in resources below) asking How you can create a Web Deploy (AKA MSDeploy) package when publishing a ClickOnce project. The easiest way to do this is to use the Web Deploy command line utility, msdeploy.exe. With the command line you can easily create an MSDeploy package from a folder with a command like the following:

    %msdeploy% 
      -verb:sync 
      -source:contentPath="C:\Temp\_NET\WebPackageWithClickOnce\WebPackageWithClickOnce\bin\Debug\app.publish" 
      -dest:package="C:\Temp\_NET\WebPackageWithClickOnce\WebPackageWithClickOnce\bin\Debug\co-pkg.zip"

Here you can see that I’m using the sync verb, along with a contentPath provider (which points to a folder) as the source and the destination is using the package provider, this point to where I want the package to be stored.

Now that we understand how to create an MSDeploy package from a folder we need to extend the ClickOnce publish process to create a package. I’m not a ClickOnce expert, but the ClickOnce publish process is captured in MSBuild so after investigating for a bit I found the following relevant details.

• The ClickOnce publish process is contained in the Microsoft.Common.targets file
• The ClickOnce publish process is tied together through the Publish target
• ClickOnce prepares the files to be published in a folder under bin named app.publish which is governed by the MSBuild property PublishDir

Now that we know what target to extend as well as what property we can use to refer to the folder which has the content we can complete sample. We need to edit the project file. Below is the full contents which I have placed at the bottom of the project file (right above </Project>).

  <PropertyGroup>
    <WebDeployPackageName Condition=" '$(WebDeployPackageName)'=='' ">$(MSBuildProjectName).zip</WebDeployPackageName>
    <!--Unless specified otherwise, the tools will go to HKLM\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\1 to get the installpath for msdeploy.exe.-->
    <MSDeployPath Condition="'$(MSDeployPath)'==''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\3@InstallPath)</MSDeployPath>
    <MSDeployPath Condition="'$(MSDeployPath)'==''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\2@InstallPath)</MSDeployPath>
    <MSDeployPath Condition="'$(MSDeployPath)'==''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\1@InstallPath)</MSDeployPath>
    <MSDeployExe Condition=" '$(MSDeployExe)'=='' ">$(MSDeployPath)msdeploy.exe</MSDeployExe>
  </PropertyGroup>
  <Target Name="CreateWebDeployPackage" AfterTargets="Publish" DependsOnTargets="Publish">
    <!--
    %msdeploy% 
      -verb:sync 
      -source:contentPath="C:\Temp\_NET\WebPackageWithClickOnce\WebPackageWithClickOnce\bin\Debug\app.publish" 
      -dest:package="C:\Temp\_NET\WebPackageWithClickOnce\WebPackageWithClickOnce\bin\Debug\co-pkg.zip"
      -->
    <PropertyGroup>
      <Cmd>"$(MSDeployExe)" -verb:sync -source:contentPath="$(MSBuildProjectDirectory)\$(PublishDir)" -dest:package="$(OutDir)$(WebDeployPackageName)"</Cmd>
    </PropertyGroup>
    <Message Text="Creating web deploy package with command: $(Cmd)" />
    <Exec Command="$(Cmd)" />
  </Target>

Here I’ve created a couple properties as well as a new target, CreateWebDeployPackage. I have declared the property WebDeployPackageName which will be the name (excluding path) of the Web Deploy package which gets created. This defaults to the name of the project, but you can override it if you want. Next I define the property, MSDeployPath, which points to msdeploy.exe. It will pick the latest version.

The CreateWebDeployPackage target just constructs the full command line call which needs to be executed and invokes it using the Exec MSBuild task. There are a couple subtle details on the target itself though which are worth pointing out. The target has declared AfterTargets=”Publish” which means that it will be invoked after the Publish target. It also declares DependsOnTargets=”Publish”. Which means that whenever the target gets invoked that Publish will need to be executed before CreateWebDeployPackage.

Now that we have defined these updates when you publish your ClickOnce project (wither through Visual Studio or the command line/build servers) a Web Deploy package will be generated in the output folder which you can use to incrementally publish your ClickOnce app to your web server. You can find the latest version of this sample on my github repository.

Sayed Ibrahim Hashimi @SayedIHashimi

Resources

• StackOverflow question: Create a clickonce webdeploy package
• MSDeploy.exe verb
• MSDeploy contentPath provider
• MSDeploy package provider
• MSBuild Exec task

The other day I saw a question posted on StackOverflow (link to question below in resources section) asking if it was possible to update web.config using MSDeploy. I actually used a technique where I updated a single file in one of my previous posts at How to take your web app offline during publishing but it wasn’t called out too much. In any case I’ll show you how you can update a single file (in this case web.config) using MSDeploy.

You can use the contentPath provider to facilitate updating a single file. Using contentPath you can sync either a single file or an entire folder. You can also use IIS app paths to resolve where the file/folder resides. For example if I have a web.config file in a local folder named “C:\Data\Personal\My Repo\sayed-samples\UpdateWebConfig” and I want to update my IIS site UpdateWebCfg running in the Default Web Site on my folder I would use the command shown below.

%msdeploy% -verb:sync -source:contentPath="C:\Data\Personal\My Repo\sayed-samples\UpdateWebConfig\web.config" -dest:contentPath="Default Web Site/UpdateWebCfg/web.config"

From the command above you can see that I set the source content path to the local file and the dest content path using the IIS path {SiteName}/{AppName}/{file-path}. In this case I am updating a site running in IIS on my local machine. In order to update one that is running on a remote machine you will have to add ComputerName and possibly some other values to the –dest argument.

You can view the latest sources for this sample at my github repo, link is below.

Hope that helps!

Sayed Ibrahim Hashimi – @SayedIHashimi

Resources:

• StackOverflow question – How to update web.config
• Latest sources for this sample on my github account

I blogged in December about SlowCheetah which is a Visual Studio add in which can be used to transform app.config (or any XML file for that matter) in ways similar to web.config. A few days back we released an update to this adding with a few key items which are listed below.

1. Support for ClickOnce
2. Support for Setup projects
3. Support for F# projects
4. Support for a custom diff viewer
5. Support for XP/Win server 2003
6. Better error handling, logging

I’ve created a set of samples for SlowCheetah which I’ll use to describe these new features. Download links for the samples, as well as pointers to the latest versions are at the bottom of this page.

Support for ClickOnce

If you are building a windows client application (Win forms or WPF) then you can use ClickOnce to publish this application. When you publish a project using ClickOnce a setup.exe will be generated as well as an HTML page which can be served by a web server to enable users to download it. When this setup.exe is generated all of the files needed to run your application (including app.config) are placed inside of that executable. When you have a project using SlowCheetah and you publish using a specific configuration it will now publish the transformed app.config (as well as any other transformed files).

In order to demonstrate this I’ve created a sample WPF application which I will publish with ClickOnce (download link is at the bottom). This project has an app.config file as well as app.Debug.config and app.Release.config.

Below is what the original app.configfile looks like.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="appName" value="WPF Demo-Debug-default"/>
    <add key="url" value="http://localhost:8080/Default/"/>
    <add key="email" value="demo-default@contoso.com"/>
  </appSettings>
  
  <connectionStrings>
    <clear />
    <add name="RecordsDb" connectionString=".\SQLExpress;Initial Catalog=RecordsDb-Default;Integrated Security=true"/>  
  </connectionStrings>
  
</configuration>

And here is app.Debug.Config

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  
  <appSettings>
    <add key="appName" value="WPF Demo-Debug" xdt:Transform="Replace" xdt:Locator="Match(key)"/>
    <add key="url" value="http://localhost:8080/" xdt:Transform="Replace" xdt:Locator="Match(key)"/>
    <add key="email" value="debug@contoso.com" xdt:Transform="Replace" xdt:Locator="Match(key)"/>
  </appSettings>

  <connectionStrings>
    <add name="RecordsDb" connectionString=".\SQLExpress;Initial Catalog=RecordsDb;Integrated Security=true"
         xdt:Transform="Replace" xdt:Locator="Match(name)"/>
  </connectionStrings>
  
</configuration>

ddd

As you can see I am transforming both the appSettings as well as the connection string. The application itself is pretty simple, it has a single page which shows the following values.

• App settings
• Connection strings
• Content of app.config

When I run this application in Debug mode I will get the following result.

In previous versions of SlowCheetah when you published your application with ClickOnce the original version of app.config was getting published instead of the transformed one. This was actually a bug in the .targets files for ClickOnce, but we have now worked around it in the SlowCheetah .targets files. So let’s say that you have a ClickOnce application and you need to publish different versions which have config changes then you can now easily do that with SlowCheetah.

Support for Setup projects

Visual Studio 2010 also has Setup projects, which can be used to generate an MSI. When you create the MSI you can specify that it includes the outputs of a project in the solution. We had a similar story here in which the original app.config was being placed into the MSI instead of the transformed on in the output folder. We have now fixed that and if you have a Setup project which reference a project with SlowCheetah transforms then the transformed files will endup in the resulting MSI instead of the original one.

Support for F# projects

If you have F# project and tried SlowCheetah you probably noticed that the “Add Transforms” menu item didn’t show up for those project types. They now do.

After you invoke this command you will see a transform created for each configuration defined for the project. In other project types these transform appear as child items, but F# projects don’t support this in the same way as C#/VB projects so they will not be nested. So they will show up as the following.

I created a very simple F# application to demonstrate the behavior, below is the code.

// A simple application to create the config and show results in the console
let settingOne = System.Configuration.ConfigurationManager.AppSettings.["settingOne"];
let settingTwo = System.Configuration.ConfigurationManager.AppSettings.["settingTwo"];
let settingthree = System.Configuration.ConfigurationManager.AppSettings.["settingThree"];


printfn "settingOne: %s" settingOne
printfn "settingTwo: %s" settingTwo
printfn "settingThree: %s" settingthree

printfn " "
printfn "Press any key to close"
System.Console.ReadKey(true)

As you can see this app just reads a few config values from app.config and displays them on the console. Here is the original app.config file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="settingOne" value="one default value"/>
    <add key="settingTwo" value="two default value"/>
    <add key="settingThree" value="three default value"/>
  </appSettings>
</configuration>

Here is app.Debug.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings>
    <add key="settingOne" value="one Debug"
         xdt:Locator="Match(key)" xdt:Transform="Replace" />
    
    <add key="settingTwo" value="two Debug"
         xdt:Locator="Match(key)" xdt:Transform="Replace" />
    
    <add key="settingThree" value="three Debug"
         xdt:Locator="Match(key)" xdt:Transform="Replace" />
  </appSettings>
</configuration>

There is a similar app.Release.config as well for this project.

When I run this in Debug mode below is the result

When I run this in Release mode below is the result.

As you can see F# project will now pickup up the transformed web.config file instead of the original one when running.

Support for a custom diff viewer

As you may know SlowCheetah has a Preview Transform functionality that allows you to quickly see the difference between the source file and the transformed one. For example in my Wpf.Transform project I have a app.config file and app.Debug.config when I select one of the transforms I can see this menu item.

When that menu item is invoked we open the Visual Studio diff viewer to show you the difference between these two files. We have received a number of requests to support different diff viewers and we have enabled this in the latest release.

After installing SlowCheetah you can go to Tools->Options and then pick SlowCheetah on the left hand side. You will see the following.

Here we have three settings which you can customize, they are outlined below.

If you want to use KDiff with SlowCheetah then you need it to invoke the following command:

“C:\Program Files (x86)\KDiff3\kdiff3.exe” {Path-to-original-file} {Path-to-transformed-file}

So in this case I just have to update the value for Preview Tool Executable Path to be C:\Program Files (x86)\KDiff3\kdiff3.exe. After that when I perform a transform I will see something like.

Support for XP/Win server 2003

After publishing the original version of SlowCheetah users started complaining that it didn’t work for either Windows XP or Windows Server 2003. This is because SlowCheetah writes file under the %LocalAppData% folder. What I didn’t realize was that XP and Win server 2003 don’t have this environment variable defined! Because of this I had to update the logic of where to write the files if that environment variable didn’t exist. Now everything works seamlessly.

Better error handling, logging

We had some issues in previous builds and they were difficult to diagnose because we didn’t have any logging support. We have now updated this and we should be able to diagnose user issues much easier.

Below are a list of resources and pointers, I hope that you guys like these updates and please do continue giving us feedback on this!

Resources

• SlowCheetah download page
• Download these samples in a .zip file
• My github repo for the latest version of these samples

Sayed Ibrahim Hashimi @SayedIHashimi

Note: I work for Microsoft but this add in was not created nor is supported by Microsoft.