Long, very technical story, interesting only to Windows Store programmers. Recording this mostly to document the experience.

Scenario

1. We have a universal app that contains a Windows Store and a Windows Phone project for Windows 8.1.
2. I manually generated packages for both projects in Visual Studio 2013 Update 4.
3. Visual studio changed the project files and I checked that in.
4. After that the build server started complaining about some weird build errors:

MakeAppx : error : Error info: error 80080204: The package with file name “ProjectNameHere.Windows_0.4.0.1_ARM.appx” and package full name “678ad2fe-4933-4bd3-8fa1-af702e4be0ca_0.4.0.1_arm__qe2w54mdbegfm” is not valid in the bundle because it has a different package family name than other packages in the bundle. The expected package name is 3a8de3e9-51fd-4584-8e4b-420e196d0f1a.

Immediate cause of failure

Visual studio added the following properties to my .csproj file:
<AppxAutoIncrementPackageRevision>True</AppxAutoIncrementPackageRevision>
<AppxBundlePlatforms>x86</AppxBundlePlatforms>

Apparently this leads to automatic execution of target _CreateBundle from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppxPackage.Targets.

The target tried to bundle Windows Store and Windows Phone apps in the same bundle. Obviously, this could not possibly work. It seems that the target is invoked when building the solution with MSBuild, but not when building it from Visual Studio, which further complicates matters. MSBuild command that triggered the problem:

"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" /p:Configuration=Release;Platform=ARM;RunCodeAnalysis=Never src/ProjectNameHere/ProjectNameHere.sln

Root cause

The problem lies in the MsBuild property named PlatformSpecificBundleArtifactsListDir. Microsoft.AppxPackage.Targets is structured so that if that property is already set, it will not be changed. The property is initially set for my Windows Store project, and then not changed when the Windows Phone project is compiled. The property points to the BundleArtifacts directory that contains files like x86.txt and arm.txt that determine what to put in the bundle. When the property points to the wrong project wrong files end up in the bundle and it goes all downhill from there.

Obviously, this is going to affect you only if you have more than one bundle-generating project.

Solution

For each bundle-generating project explicitly add the following line after the first <PropertyGroup>:

<PlatformSpecificBundleArtifactsListDir>$(ProjectDir)BundleArtifacts</PlatformSpecificBundleArtifactsListDir>