Visual Studio

Using MsBuild tasks to build SSIS packages

In a previous blog post, I explained how to recompile the MsBuild task for SSIS 2016. Now that we’ve this task, we’ll see how to use it.

First,let define a new file (here named Build.proj) in our SSIS solution

Then, we’ll need to define our headers and namespaces:


The last attribute DefaultTargets is defining the part of the xml file that will be used when this file will be executed. In our case we’ll just have one version of the Target but it’s better to already correctly define it.

We also have to specify to MsBuild that an external assembly will be used (the community tasks to build SSIS packages).


It’s now time to create a kind of variable to host the name/path of our SSIS project. Within MsBuild you achieve this task by using the following syntax:

    <SSISProjPath Include="..\anotherFolder\MySSISProject.dtproj" />

SSISProjPath is the name of the variable and the value is defined in the Include attribute.

Now, let’s focus on the Target itself. The target is named SSISBuild and will display a message before using the task to compile the SSIS project. The second step is performed by invoking the task DeploymentFileCompilerTask

<Target Name="SSISBuild">
   <Message Text="*********** Building SSIS project ***********"/>

The first parameter of DeploymentFileCompilerTask is the name of your project, you can safely use your variable by specifying the @() syntax. The second parameter is the configuration, personnaly I never change it and use Development but up-to-you. The protection level will override the corresponding property of your project.

If you want to compile, your project you can call MsBuild and specify Build.proj as the parameter, it will do the job! But it’s more interesting if you can include this in your build steps. I’ll just show you how you can include this in your TeamCity configuration:

  1. Create a build step
  2. Define the runner type as MsBuild
  3. Specify the MSBuild property for version as Microsoft Build Tools 2015 and ToolsVersion as 14.0
  4. Don’t forget to specify the name of your target
    as SSISBuild

Once you’ve this setup in place, you can trigger your TeamCity project to get the following message and your build ready.


Building the MsBuild Tasks for SSIS 2016

MsBuild Tasks are a set of two tasks available in the community project supported by Microsoft (project SSISMSBuild) and hosted on Codeplex. They aim to support the build of SSIS packages from MsBuild files. This a great way to automate the build of your packages without the need of Visual Studio (and so without licences issues). Unfortunately, this project has not been updated since 2010 but the source code is still available. It means that you need to update the dependencies and compile these tasks if you want to use it with SQL Server 2012, 2014 or 2016 (or vNext).

Download the solution and open it with Visual Studio:


To “upgrade” for SSIS 2016, open the solution with Notepad++ or any other text editor. Change the hint paths (not just once but all of them) to redirect to your version of Visual Studio:

  • Visual Studio 11.0  = Visual Studio 2012
  • Visual Studio 12.0  = Visual Studio 2013
  • Visual Studio 14.0  = Visual Studio 2015
  • Visual Studio 15.0  = Visual Studio 2017

Then, it’s time to update the references to SQL Server in the project. Check the path of the dll named Microsoft.SqlServer.ManagedDTS. Keep in mind the following matches:

  • v11 = SQL Server 2012
  • v12 = SQL Server 2014
  • v13 = SQL Server 2016
  • v14 = SQL Server vNext


You also need to sign your build. Don’t panic it’s really easy. Open the properties of your project and create a new key:


You must update the target framework to be inline with the framework of SSDT … currently .NET framework 4.5.


Build and finally copy/paste your new dll to the directory C:\Program files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ (If needed change the path to target the correct version of Visual Studio).

That’s it, you now have correct version of the MsBuild tasks for SSIS, in a next blog post, I’ll explain how to use it.

Create a syntax highlighter for Visual Studio and Visual Code with TextMate Bundle

Yesterday, I decide to create a syntax highlighter for the genbiL language. The end-result is available on this GitHub repository. The goal was to provide a better experience for users editing these files from their favorite code editor. It was a completely new experience for me and it appeared to be much easier than expected.


if you’re using genbiL, I recommend that you install it through the following commands:

cd %userprofile%\.vs\Extensions
git clone git:// genbil

Visual Studio and Visual Code use an international standard for syntaxes and snippets: TextMate Bundles. If you want to create a new TextMate Bundle for a given language, start by creating a new folder under %userprofile%/.vs/Extensions with the name of your language and then a subfolder named syntaxes.

In this folder create a new empty file or (much more easier) copy/paste an existing file from another language. The format of this file is a property list, an xml-like file with just a few elements:

  • <key/> will specify the type of content for the next element
  • <string/>specify the value associated to the <key/> defined above
  • <array/>is a container to specify multiples values for the <key/>
  • <dict/>let’s you specify a <key/> and <string/> pair

It sounds weird at the beginning but it’s relatively easy to use.

First action to take is to change or write a few key information:

  • uuid is a unique identifier for this syntax definition. Each new syntax definition must have its own uuid. Don’t re-use them or your editor will not be able to load your syntax.
  • The name of your language. Use a short, descriptive name. Typically, you will be using the programming language’s name you are creating the syntax definition for.
  • The top level scope for this syntax definition is the scopeName. It takes the form source.languageName
  • fileTypes is a list of file extensions. When opening files of these types, Visual Studio will automatically activate this syntax definition for them.




After this initial definition, you’ll have to create patterns. Each pattern starts by a match. A match is defined through a regular expression.

Then comes the name. In fact the name is a naming scope and isn’t obvious sometimes. Check the Textmate online manual for guidance on scope names. It is important to re-use the basic categories outlined there if you want to achieve the highest compatibility with existing themes.

Colors from the theme have hardcoded scope names in them. They could not possibly include every scope name you can think of, so they target the standard ones plus some rarer ones on occasion. This means that two colors using the same syntax definition may render the text differently!

Bear in mind too that you should use the scope name that best suits your needs or preferences. It’d be perfectly fine to assign a scope like constant.numeric to anything other than a number if you have a good reason to do so.