- | rssFeed | My book on MSBuild and Team Build | Archives and Categories Monday, May 13, 2013

How to compress a Visual Studio Extension (VSIX) during build

Lately I’ve been working with Mads Kristensen on a cool new Visual Studio Extension, Farticus, and wanted to share with you guys one of the things that I learned.

When you are developing Visual Studio extension on of the things you should keep in mind is the download size of the extension. This is the size of the .vsix file which you upload to the gallery. If the download size is too large typically people may get impatient and cancel the install. Because of this it’s a good idea to try and get your .vsix to the smallest size possible.

The good news here is that the .vsix file is already compressed. It’s actually a .zip file renamed to .vsix. If you want to see what’s in a .vsix just rename it to .zip and extract it out. The bad news is that the CreateZipPackage task used by the Microsoft.VsSdk.targets file does not perform the best compression. Fortunately there are tasks to create Zip files that we can use. I have chosen to use the Zip task from the MSBuild Extension Pack.

Before I go over all the details let’s take a look at what the final result will be after we compress with the MSBuild Extension Pack. See the table below for the comparison for two different projects.

Project

VSIX Size Before

VSIX Size After

Reduction

Farticus 442 kb 248 kb 43 %
VS Web Essentials 2102 kb 740 kb 65 %

From the table above we can see that we can gain a significant amount of additional compression by using the MSBuild extension pack.

Below is the content that I pated into the .csproj file. I’ll paste it in it’s entirety and then explain.

<PropertyGroup>
  <EnableCompressVsix Condition=" '$(EnableCompressVsix)'=='' ">true</EnableCompressVsix>
  <BuildLib Condition=" '$(BuildLib)'=='' ">$(MSBuildProjectDirectory)\..\Build\Lib\</BuildLib>

</PropertyGroup>
<UsingTask AssemblyFile="$(BuildLib)MSBuild.ExtensionPack.dll" TaskName="MSBuild.ExtensionPack.Compression.Zip"/>

<Target Name="CompressVsix" 
        AfterTargets="CreateVsixContainer" 
        DependsOnTargets="PrepareReplceVsixTemp" 
        Condition=" '$(EnableCompressVsix)'=='true' ">
    
  <!-- copy the file to the obj folder and then party on it -->
  <MakeDir Directories="$(_TmpVsixDir);$(_TmpVsixDir)\Extracted\"/>

  <Copy SourceFiles="$(TargetVsixContainer)"
        DestinationFolder="$(_TmpVsixDir)">
    <Output TaskParameter="CopiedFiles" ItemName="_TmpVsixCopy"/>
  </Copy>
    
  <!-- extract out the .zip file -->
  <MSBuild.ExtensionPack.Compression.Zip 
    TaskAction="Extract" 
    ExtractPath="$(_TmpVsixDir)Extracted\" 
    ZipFileName="@(_TmpVsixCopy->'%(FullPath)')"/>

  <ItemGroup>
    <_FilesToZip Remove="@(_FilesToZip)"/>
    <_FilesToZip Include="$(_TmpVsixDir)Extracted\**\*"/>
  </ItemGroup>

  <MSBuild.ExtensionPack.Compression.Zip
    TaskAction="Create"
    CompressFiles="@(_FilesToZip)"
    ZipFileName="%(_TmpVsixCopy.FullPath)"
    RemoveRoot="$(_TmpVsixDir)Extracted\"
    CompressionLevel="BestCompression" />

  <Delete Files ="$(TargetVsixContainer)"/>
  <Copy SourceFiles="%(_TmpVsixCopy.FullPath)" DestinationFiles="$(TargetVsixContainer)" />
</Target>

<Target Name="PrepareReplceVsixTemp" DependsOnTargets="CreateVsixContainer">
  <ItemGroup>
    <_VsixItem Remove="@(_VsixItem)"/>
    <_VsixItem Include="$(TargetVsixContainer)" />

    <_TmpVsixPathItem Include="$(IntermediateOutputPath)VsixTemp\%(_VsixItem.Filename)%(_VsixItem.Extension)"/>
  </ItemGroup>
    
  <PropertyGroup>
    <_TmpVsixDir>%(_TmpVsixPathItem.RootDir)%(_TmpVsixPathItem.Directory)</_TmpVsixDir>
  </PropertyGroup>

  <RemoveDir Directories="$(_TmpVsixDir)"/>  
</Target>  

 

The snippet above perform the following actions.

  1. Remove the old VsixTemp folder from any previous build if it exists
  2. Copy the source .vsix to the intermediate output path (i.e. obj\debug or obj\release)
  3. Extract out the contents to a folder
  4. Re-zip the file using MSBuild extension pack
  5. Replace the output .vsix with the compressed one

 

When building now the .vsix in the output folder should be smaller than it was before.

In my case I have copied the necessary assemblies from the MSBuild Extension pack and placed them in the projects repository. For the Zip task you’ll need the following files.

In my case I’ve placed them in a folder named Build\lib\.

You should be able to copy/paste what I have here into your VSIX projects. You’ll need to update the path to the MSBuild extension pack assemblies if you put them in a different location. Note: I’ve only tested this with Visual Studio 2012.

The MSBuild elements used here is pretty straight forward. If you have any questions on this let me know.

 

You can find the source for the Farticus project at https://github.com/ligershark/Farticus/. Please send us a Pull (my finger) Request.

 

Thanks,
Sayed Ibrahim Hashimi | http://msbuildbook.com | @SayedIHashimi

Visual Studio 11 | vs-extension | VSIX Monday, May 13, 2013 1:11:54 AM (GMT Daylight Time, UTC+01:00)  #     | 
Sunday, August 19, 2012

Visual Studio project compatability and VisualStudioVersion

One of the most requested features of Visual Studio 2012 was the ability to open projects in both VS 2012 as well as VS 2010 (requires VS 2010 SP1). In case you haven’t heard we did implement that feature. You may be wondering how we were able to do this and how this may impact you.

If you open the .csproj/.vbproj for a Web Project created in VS2010 you will see the following import statement.

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\
v10.0\WebApplications\Microsoft.WebApplication.targets" />

When you open this project in VS 2012 there are a few changes made to your project file to ensure that it can be opened in both VS 2010 SP1 and VS 2012. One of the changes made to the project when it is first loaded in VS 2012 is to add the following to replace that import statement.

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">
    $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

We removed the hard-coded 10.0 and instead used the property VisualStudioVersion. When building in Visual Studio 2012 this value will always be 11.0, but for VS 2010 it doesn’t exist. That is why we defaulted it to 10.0 above.

There are some scenarios where building from the command line will require to set this property explicitly. Before we get there let me explain how this property gets set (in this order)

  1. If VisualStudioVersion is defined as an environment variable/global MSBuild property, that is used.
    • This is how VS and the VS developer command prompt set this value
  2. Based on the file format version of the .sln file (toolset used is sln file format –1)
    • To simplify this statement, the .sln file will build with specifying VisualStudioVersion to the value of the version of VS which created the .sln file.
  3. Choose default
    • 10.0 if VS 2010 is installed
    • Highest-versioned sub-toolset version installed

For #2 when you are building a .sln file the value of VisulStudioVersion will be –1 of the Format Version found in the .sln file. The important thing to note here is that if you build a .sln file it will build with the value of VisulStudioVersion corresponding to the version of VS which created the .sln file. So if you create a .sln file in VS2012 and you always build that .sln file the value for VisualStudioVersion will be 11.0. In many cases if you build the .sln file you are good.

If you are building .csproj/.vbproj files w/o going through a .sln file? If you build a web project from the command line (not the developer prompt) then the value for VisualStudioVersion used will be 10.0. That is an artifact of the properties which I showed above. In this case you should pass this in as an MSBuild property. For example

msbuild.exe MyAwesomeWeb.csproj /p:VisualStudioVersion=11.0

In this case I’m passing in the property explicitly. This will always override any other mechanism to determine the value for VisualStudioVersion. If you are using the MSBuild task in a build script, then you can specify the property either in the Properties attribute or the AdditionalProperties attribute. See my previous blog post on the difference between Properties and AdditionalProperties.

If you encounter any funny behavior when building/publishing and you notice that the wrong .targets files are being imported then you may need to specify this property.

Sayed Ibrahim Hashimi | @SayedIHashimi

msbuild | Visual Studio | Visual Studio 11 | Visual Studio 2010 | Visual Studio 2012 | web | Web Publishing Pipeline Sunday, August 19, 2012 10:06:56 PM (GMT Daylight Time, UTC+01:00)  #     | 
Thursday, August 16, 2012

SlowCheetah v2.4 Released

I jus released a new version of SlowCheetah, my Visual Studio extension which enables you to transform app.config, and other XML files, during F5 for non-web projects. In this update I added support for Visual Studio 2012 as well as the bug fixes below.
  1. Fix for Preview command doesn't show up for all web.config transforms
  2. Fix for XML transforms not working with Azure SDK
  3. Fix for XML transforms not working with Azure SDK
  4. Fix for .config files do no transform in VS 2012 RC
  5. Fix for In web project, project File gets modified while adding transformation
  6. Fix for Add Transform should not show up for .settings files
  7. Fix for Transforms should be added as None

If you are interested in the project you can take a look at the code at https://github.com/sayedihashimi/slow-cheetah and if you have any issues please file a bug at https://github.com/sayedihashimi/slow-cheetah/issues.

 

Thanks,
Sayed Ibrahim Hashimi | @SayedIHashimi

    SlowCheetah | Visual Studio | Visual Studio 11 | Visual Studio 2010 | Visual Studio 2012 Thursday, August 16, 2012 1:54:26 AM (GMT Daylight Time, UTC+01:00)  #     | 
    Thursday, August 09, 2012

    How to create Web Deploy packages in Visual Studio 2012

    When building Visual Studio 2012 we made an effort to reduce the amount of menu options which are shown on toolbars as well as context menus. If you have used any of the pre-release versions of VS 2012 then you might have noticed that the Build Deployment Package and Package/Publish Settings context menu options are gone from Web Application Project.

    In VS2010 when creating a Web Deploy package the publish dialog was not used because there were no relevant settings. Now that we have enabled features like integration to enable Entity Framework Code First migrations, incremental database updates (coming in the final release), connection string updates, etc. we needed to find a way that you could leverage these great features when creating Web Deploy packages. The solution that we decided to go with was to have first class support for creating packages directly from the publish dialog.

    After that, we felt that it would be better to have a single way to create a package than two different ways with pros and cons. And we would benefit by being able to simplify our context menu. To create a package for your Web Application Project in VS 2012 (or in VS 2010 if you have the Azure SDK 1.7+) you can follow the steps below.

    1. Right click on your project and select Publish
    2. Create a new profile for your Web Deploy package
    3. Specify the path where the package should go (must end with a .zip)
    4. Click Publish

    After the initial create for the profile, creating additional packages is even easier. You just right click on your project select Publish and then click the Publish button.

    The reason why we remove the context menu for the Package/Publish Settings is that most of the package and publish related settings are on the publish dialog. The existing settings from VS 2010 are still available on the property pages if you need to get to them.

    One other change which we made was to hide the One Click toolbar. This is a toolbar which can be used to publish your web project in one click after the web publish profile has been created. After looking at the number of times that the button was used we determined that it did not meet the bar to be shown by default. Don’t worry if that was your favorite button (I know it was mine), you can bring it back quickly. The easiest way to turn it on is to press CTRL + Q (to bring up the quick launch), type in ‘one click’ and then click on the single result. That should show the One Click toolbar.

    FYI if you want to learn more we have a great walk through on publishing a web project with an EF Code First model at Deploying an ASP.NET Web Application to a Windows Azure Web Site and SQL Database.

    If you have any questions feel free to email me at sayedha@microsoft.com.

    Sayed Ibrahim Hashimi | @SayedIHashimi

    Visual Studio | Visual Studio 11 | Visual Studio 2012 | Web Publishing Pipeline Thursday, August 09, 2012 10:39:46 PM (GMT Daylight Time, UTC+01:00)  #     | 
    Friday, June 15, 2012

    Downloading the Visual Studio Web Publish Updates

    I have written a few posts recently describing out updated web publish experience. These new experience is available for both Visual Studio 2010 as well as Visual Studio 2012 RC. You can use the links below to download these updates in the Azure SDK download. Below are links for both versions.

    The Web Publish experience is chained into VS 2012 RC so if you have installed VS 2012 RC with the Web features then you already have these features.

    Thanks,
    Sayed Ibrahim Hashimi @SayedIHashimi

    asp.net | Deployment | Visual Studio | Visual Studio 11 | Visual Studio 2010 | web | Web Deployment Tool | Web Publishing Pipeline Friday, June 15, 2012 8:30:40 PM (GMT Daylight Time, UTC+01:00)  #     | 
    Thursday, June 07, 2012

    ASP.NET providers and SQL Azure

    We have two sets of ASP.NET providers which currently exist; the ASP.NET SQL providers, and the ASP.NET Universal Providers. In VS 2010 the SQL providers were in only providers used for our project templates. In VS 2012 we have switched to using the Universal Providers. One of the drawbacks of the SQL providers is that it leverages DB objects of SQL server which are not available in SQL Azure.

    In our updated web publish experience we have an Update Database checkbox which can be used to incrementally publish the database to the destination database. In this case if the source connection string is used by the ASP.NET SQL providers and you are publishing to SQL Azure then you will see the following message on the dialog.

    SNAGHTML48cbb8

    Note: you may see the Update Database checkbox disabled, please visit http://sedodream.com/2012/06/07/VSPublishDialogUpdateDatabaseDialogDisabled.aspx for more info on why.

    The publish dialog is letting you know that the SQL providers are not compatible with SQL Azure and helps you convert to using the Universal Providers. After you install the Universal Providers the web.config entry will be commented out and new entries will be inserted for the Universal Providers. Your existing database will not be impacted, we’ll create a new connection string pointing to a new database. If you had any data in the SQL Providers database you will have to re-create those objects in the new database.

    If you have any questions please feel free to directly reach out to me at sayedha(at){MicrosoftDOTCom}.

    Sayed Ibrahim Hashimi @SayedIHashimi

    Visual Studio | Visual Studio 11 | Visual Studio 2010 | web | Web Publishing Pipeline Thursday, June 07, 2012 11:41:46 PM (GMT Daylight Time, UTC+01:00)  #     | 

    VS Publish dialog Update Database dialog disabled

    If you have tried out our new Web Publish experience in Visual Studio you may have noticed that the Update Database checkbox is disabled. See the image below.

    image

    The intended behavior of this checkbox is to enable you to incrementally publish your database schema from the source (the connection string in web.config) to the destination (whatever connection string is in the text box). The difference between an incremental publish and a typical publish is that for incremental publishes only changes are transferred from source to destination. With a full publish the first time that you publish your DB schema everything is created, and the next time that you try to publish you will receive an error because it tries to re-create existing DB objects.

    The functionality of the Update database checkbox leverages an MSDeploy provider. We were hoping to complete that provider and give it to hosters in time for the release but we were unable to do so. We are working on completing the provider and partnering with hosters to install these in time for the launch of Visual Studio 2012 RTM.

    In the mean time if you need to publish your DB schema you can use the Package/Publish SQL tab (caution: the DB publishing here is not incremental). If you are going to use the PP/Sql tab to publish to SQL Azure then there are some special consideraions that you will need to take. You can learn more about those by visiting http://msdn.microsoft.com/en-us/library/dd465343.aspx and searching for “Azure” on that page.

    If you have any questions please feel free to directly reach out to me at sayedha(at){MicrosoftDOTCom}.


    Thanks,
    Sayed Ibrahim Hashimi @SayedIHashimi

    Visual Studio | Visual Studio 11 | Visual Studio 2010 | web | Web Development | Web Publishing Pipeline Thursday, June 07, 2012 10:44:26 PM (GMT Daylight Time, UTC+01:00)  #     | 
    Friday, April 27, 2012

    SlowCheetah VS 11 support and now on github

    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

    msbuild | SlowCheetah | Visual Studio 11 | Visual Studio 2010 Friday, April 27, 2012 7:52:02 PM (GMT Daylight Time, UTC+01:00)  #     |