When we work with Windows Store apps, there are scenarios where we need to do Sideloading. Basically, Sideloading lets us install a Windows Store app without using the Windows Store. There can be many reasons to want to do Sideloading: testing the app locally before uploading it to the store, installing the app on a few devices for friends&family testing, or simply using the app at a corporate level outside the Windows Store.

In one of the projects I’m working on right now, we’re in exactly those scenarios. We have an app that’s distributed through Sideloading, and we also have a QA team that tests both the development versions and the release candidates.

Since it was pretty tedious to depend on generating the Sideloading packages by hand, we decided to create these packages automatically from our continuous integration environment. In this case we use Jenkins, but what’s described here works for any other system.

Microsoft tells us in this link how to create a package using msbuild. Basically, it just asks msbuild to build the Windows Store app project:

MSBuild MyProject.csproj /p:OutDir=C:\builds\droplocation\

The problem with this approach is that in big projects it’s normal to have a solution with several projects (but don’t overdo it, eh!). With several projects we usually have a folder structure that means that, when building a project on its own, msbuild has trouble finding the NuGet packages, because it looks for them relative to the solution path and not to the project path.

Anyway, whether we have this problem or not, and it could be solved in plenty of other ways, a very simple way to get an app package is to modify the .csproj so it creates the app package every time we build the project (whether inside a solution or on its own). To do that, we need to add these lines to the .csproj of our Store app:

<PropertyGroup Condition="'$(BuildingInsideVisualStudio)' != 'true'">
	<GenerateAppxPackageOnBuild>True</GenerateAppxPackageOnBuild>
	<AppxPackageDir>$(OutputPath)AppPackages</AppxPackageDir>
	<AppxPackageName>$(AssemblyName)_$(Platform)</AppxPackageName>
</PropertyGroup>

It’s very important to pay attention to the PropertyGroup’s Condition attribute, because that way we avoid generating the app package every time we build it from Visual Studio (we don’t want to penalize the development team’s build time). Of course, we can change this condition to one that takes the build profile or any other factor into account, but this one seemed quite suitable to us.

On the other hand, by specifying the AppxPackageName we always get the same .appx file name, avoiding the default behavior of including the version number in the file name. That makes life easier for the automation processes I’ll describe in upcoming posts.

Another important detail is to include the platform in the package name, because it has happened to me that msbuild generates the 32-bit and 64-bit .appx files in the same folder, overwriting the first one when generating the last one, which will give you serious headaches.