MSBuild publish web project from command line does Package instead of FileSystem

Question

I have a web project that I am publishing from the command line, using a publish profile that does a few additional tasks (excludes some files and folders, grunt, publishing another project in turn).

One two machines (A and B), it works fine from right-click > Publish... in Visual Studio, and choosing the correct publish profile.

Historically, on both machines, it has also worked with the following command line:

msbuild MyProject.csproj /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=myProfile  /v:n

However now, machine B is not publishing correctly.

The publish profile is configured with <WebPublishMethod>FileSystem</WebPublishMethod at the top, however from the logs, it is attempting a Package publish type instead, for no apparent reason.

Here is the full publish profile:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <WebPublishMethod>FileSystem</WebPublishMethod>
        <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
        <LastUsedPlatform>Any CPU</LastUsedPlatform>
        <SiteUrlToLaunchAfterPublish />
        <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
        <ExcludeApp_Data>False</ExcludeApp_Data>
        <publishUrl>..\Production</publishUrl>
        <DeleteExistingFiles>False</DeleteExistingFiles>
        <ExcludeFoldersFromDeployment>Content;Scripts;Pages</ExcludeFoldersFromDeployment>
        <ExcludeFilesFromDeployment>index-dev.html;index.html;debug.html;JSLintNet.json;Gruntfile.js;package.json;packages.config;publishall.bat;publishapi.bat</ExcludeFilesFromDeployment>
        <BuildDependsOn>
            $(BuildDependsOn);
            RunGrunt;
            PublishApi;
        </BuildDependsOn>
    </PropertyGroup>
    <Target Name="RunGrunt">
        <Message Text="Running grunt production..." />
        <Exec Command="grunt production" />
    </Target>
    <Target Name="PublishApi">
        <Message Text="Publishing API..." />
        <Exec Command="publishapi" />
    </Target>
</Project>

As you'd expect, because it is just doing a Package, no files ever appear in the publishUrl directory. Again, the publish profile works fine from VS2013, using right-click publish.

In the log on machine A I get this excerpt:

**ValidatePublishProfileSettings**:
  Validating PublishProfile(myProfile) settings.

But in machine B it doesn't appear.

Later in the log on machine A it contains:

**WebFileSystemPublish**:
  Creating directory "..\Production".
  Copying obj\Release\Package\PackageTmp\cache.manifest to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\cache.manifest.
  Copying obj\Release\Package\PackageTmp\Global.asax to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Global.asax.
  Copying obj\Release\Package\PackageTmp\Web.config to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Web.config.
  Copying obj\Release\Package\PackageTmp\bin\MyProject.dll to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Blithe.Web.Collect.dll.

but later in the log on machine B, in place of the above, it contains:

**Package**:   
  Invoking Web Deploy to generate the package with the following settings:   
  $(LocalIisVersion) is 7  
  $(DestinationIisVersion) is 7   
  $(UseIis) is True   
  $(IisUrl) is <<<some url>>>  
  $(IncludeIisSettings) is False  
  $(_DeploymentUseIis) is False   
  $(DestinationUseIis) is False

The only difference I can think of between the two machines, is that I installed an update on machine B (the problem machine) for 'Windows Azure SDK for .NET (VS2013) - 2.3'. Any ideas how and why this might have broken it?

I tried adding /p:PublishProfileRootFolder="Properties\PublishProfiles" as mentioned here but this didn't work.

Answer 1

Adding:

/p:VisualStudioVersion=12.0

to the command worked.

Machine B had Visual Studio 2008 installed on it as well, whereas Machine A didn't. Setting the version to 12.0, or even 11.0 works. Setting it to 10.0 ignores the publish profile and just does a package install.

Surprisingly it seems to default to 10.0.

This issue did not emerge until the update to Azure SDK 2.3, which DID have some changes to Web Publish, so that may well have led to this issue.