Msbuild: MSBuild commandline seems to ignore publish properties

Created on 23 Mar 2017  ·  96Comments  ·  Source: dotnet/msbuild

I'm trying to use msbuild to publish my application to a filesystem location. I've setup a profile from inside VS2017 and from there it works perfectly.
When I run msbuild from the commandline: "_msbuild application.sln /p:DeployOnBuild=true /p:PublishProfile=publishprofile_" it builds the default "Debug|x86" target and nothing else. Nothing is published and the target in the publish profile is set to "release".
When I specify a non-existing publish profile it still build like above, while I would expect an error telling me I specified a non-existing profile.

Most helpful comment

Same here: that's ok with Enterprise VS 2017 on development machine, but nothing is published when running the same build command on a Jenkins box with the build tools (no VS installed).

All 96 comments

+1 I'm having the same issue. The following command builds correctly, but doesn't output anything to the deploy target. The exact same command works on a machine with VS2015 installed.

"C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" /t:Build;Publish TCA.Web\TCA.Web.csproj /p:DeployOnBuild=true /p:PublishProfile=Deploy.pubxml /p:Configuration=Release

I see the following in the build output, but unable to extract why it happens.
_DeploymentUnpublishable:
Skipping unpublishable project.

It works from the Visual Studio 2017 UI. I'm running build 15.0.0+26228.10

Same for me.

Same for me too,

Same for me

Same for me

Hi, still no news from Microsoft's guys? MSBuild 14 cannot build C# 7 code.

Is it possible to build with v15 and do the publish (and only the publish) with 14?

Same here

Same for me

Same here.

Ditto.

Same here

Me as well

Same here.
I try to run publish only (This method worked in previous versions)
MSBuild /t:publish /p:PublishProfile= /p:PublishRootDir= /p:Configuration=Release

I'm also encountering the same problem

I tried to reproduce this but don't think I did, on a new WebApplication type project created in VS2015 U3 and published on the command line from both VS2015 U3 and VS2017 15.1.

Can someone affected by this please post repro steps that are excruciatingly clear, for someone who has never used "publish" before like me? Ideally with a small repro project I could build in various ways, and explicit descriptions of the behavior you expect and what you see instead.

I'm not the original reporter, but experienced this issue attempting to configure a build agent without Visual Studio - using https://aka.ms/vs/15/release/vs_buildtools.exe - excerpt from PS script:

&.\vs_buildtools.exe `
  --add Microsoft.VisualStudio.Workload.MSBuildTools `
  --add Microsoft.VisualStudio.Workload.WebBuildTools `
  --includeRecommended --includeOptional `
  --passive `
  --norestart

Same here: that's ok with Enterprise VS 2017 on development machine, but nothing is published when running the same build command on a Jenkins box with the build tools (no VS installed).

Very annoying issue, has anyone found a workaround when using TFS?

We have the VS 2017 build tools installed on our build agent and see this issue with publishprofile + DeployOnBuild=true

We can't move forward with msbuild 15 because of this.

I had this issue even with VS 2017 Enterprise installed. I had to re-run the Enterprise installer and select the component "ASP.NET and web development tools" in order to get web publish to work from the build server. Now that I think about it, this seems very similar to a problem I had back around VS 2012/2013 that required the Azure SDK to be installed for web publish to work (even though I didn't need to install any Azure components this time around).

MSBuild 15.2 (26430.4) fixed the problem for me. (Just start the the installer; the update will then be available for install.)

This also fixes the issue (via Chocolatey) for versions prior to 15.2: https://chocolatey.org/packages/visualstudio2017-workload-webbuildtools

[Edit: clarification]

Same here, latest version of VS update fix the problem for me to.

Glad to hear that updating seems to be working for folks. Please let us know if you're seeing this problem

  • After installing the Web Build Tools workload
  • On 15.2

If we don't hear a dissenting view, we'll close this as fixed . . .

It's ok for me with latest VS Build Tools. Just take care of adding Web development build tools by modifying installation.

Had the same issue, and this worked for me. Something that confused me for a bit, is that the updater says 15.2 is installed, but the file version on MSBuild.exe is 15.1.1012.6693. I'm unsure if that's normal or not.

@Grandpappy yes, that's the MSBuild version that shipped with VS15.2 (unchanged from 15.1).

Hey Guys, I Tested the MSBuild for VS2017 Preview (15.3) and the problem still the same...

Hi, still have the same issue. :/

@mInternauta @emilegg can you please detail _exactly_ how your machine is set up, what you're doing, and how it differs from what you expect?

@rainersigwald Windows 10, Microsoft Visual Studio Professional 2017 Version 15.2 (26430.13) Release, my command is :
msbuild C:\project\myproject.csproj /p:DeployOnBuild=true /p:PublishProfile=MyPublishProfile and it seems to ignore the Publication profile. It always takes the default value.

Also see this issue still, upgraded from 15.1 to 15.2 using the installer and it did not fix this issue.

@adam-knights @emilegg @mInternauta does your build tools installation contain the web build tools?

vs_buildtools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools

@dasMulli Yes, it is installed.

Here's the output errors (3) :

The OutputPath property is not set for project 'MyProject.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Pl atform='AnyCPU'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.

No destination specified for Copy. Please supply either "DestinationFiles" or "Destination Folder".

The "FindUnderPath" task was not given a value for the required parameter "Path".

nvm, it worked with this command :
bat "msbuild \"C:\\Test\\MyProject.csproj\" /P:DeployOnBuild=true /P:PublishProfile=\"Debug - PUBLISH PROFILE"\ /P:PublishProfileRootFolder=\"C:\\Test\\Properties\\PublishProfiles\" /P:AllowUntrustedCertificate=true /P:Platform=x86 /P:Configuration=\"Debug - CONFIGURATION PROFILE"\"

Thx ! :)

I am using v15.2 and still having this problem. I get the ...

_DeploymentUnpublishable:
Skipping unpublishable project.

I have not installed the Web Build Tools workload. Is this required if I am just publishing to a folder and not doing a web deploy?

I'm figuring out how to build all projects and create a package in the same instruction. Any thoughts?

I have tried v15.3 (exactly 15.3.409.57025) and the problem is still there:
_DeploymentUnpublishable:
Skipping unpublishable project.

I have run into that as well when building visual studio project from jenkins build

  1. C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe - Publishing would be ignore
  2. C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe - Published successfuly

I should mention the project is visual studio 2017 version upgraded from VS2010

I have run following this; and It's work with deployed

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin>msbuild.exe "c:\MyProject\AnyProject.csproj" /P:DeployOnBuild=true /P:PublishProfile=Debug /P:AllowUntrustedCertificate=true /P:Configuration=Debug

Make sure that you use the proper MSBuild.exe. This:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin

Or if IDE (enterprise) installed:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin

If configure an MSBUILD step in a TFS server, set the path of the MSBUILD.exe manualy (Advenced/MSBuild/Specify location)

Using this:
C:\Program Files (x86)\MSBuild\15.0\Bin
will cause that deployment package creation FAIL.

We are using MSBuild 15.3 on our TFS build server and still having this problem. Here's the command we are using:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe "C:\Builds\_work\2\s\RQ.Shared\RQ.Shared.sln" /m /p:"DeployOnBuild=true" /p:"PublishProfile=C:\Builds\_work\2\s\BuildTools\PublishAppServicesScripts\Build\publishProfile-RQ.Shared.pubxml" /p:"SkipInvalidConfigurations=true" /p:"Configuration=Release" /p:"Platform=Any CPU" /verbosity:"minimal" /fileLoggerParameters:"LogFile=C:\Builds\_work\2\b\logs\RQ.Shared.msbuild.log" /flp1:"logfile=C:\Builds\_work\2\b\logs\RQ.Shared.msbuild.error.log;errorsonly"

MSBuild reports that the build completed successfully, but nothing shows up in the expected artifacts directory. We are building/publishing ASP.Net Web Application WCF services. The build servers only have VS 2017 installed on them.

For now we are going to revert back to using MSBuild v14 since the exact same command works there.

@rainersigwald please consider reopening this issue. Many people are still struggling with it, so I don't think the issue has been fully fixed.

If you require any other information from us, or would like us to test other parameters/configurations, please let me or @VincentLangevin know.

@rainersigwald it turns out that using the 64-bit MSBuild works correctly, but the 32-bit MSBuild does not create any artifacts to the output path.

64-bit path (works):

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\amd64\MSBuild.exe

32-bit path (does not work):

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe

Hopefully that will give you guys a hint at the root problem so you can get this fixed in all versions of MSBuild.exe.

I, too, am having this issue. With both the Bin\MSBuild.exe and Bin\amd64\MSBuild.exe.

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64>msbuild /ver
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

15.3.409.57025

@andygerlicher

We're also experiencing this issue. Switching between the 32-bit and 64-bit versions of msbuild makes no difference.

I had the same issue.
Using the build tools version of 2017 on the buildagent.
(Microsoft (R) Build Engine version 15.3.409.57025 for .NET Framework)
Tried both x86 and x64.

My Publish profile is created in Visual Studio 2017, and is just a plain Filesystem copy, without any connectionString changes.

When I checked for Web Deployment Build Tools, I didn't have that installed.
After I ran the installer and selected Web Deployment Build Tools from the UI installer
(also deselected .net core 1.0 dev tools, and selected .net framework 4-4.6 dev tools, .net framework 4.6.2 dev tools, .net framework 4.7 dev tools) it works as expected 👍
Files are being copied to the output dir specified in the publish profile (bin\Release\PublishOutput)

We were having this problem, and I can confirm that the solution outlined by @ruant fixed it for us as well.

for anyone out there that this may help, i was having this issue on a fresh installation of windows that only had VS 2017 installed. I installed VS 2015 on the machine and touched NOTHING else from how I was doing the build, and now it works... I don't get it, but it's suddenly working so i'm going to back away slowly from my machine now...

@mrtristan Might be that VS15 added a bin directory that contains msbuild to your path? (If your not typing in the full path to msbuild in the commandline?)
So the command line now uses the VS2015 msbuild instead of msbuild from VS17.

cmd /c where msbuild will tell you where msbuild is located.

@ruant i confirmed it was using the same msbuild as a machine that was fully functional. it makes no sense.

same here with Build tools v15.3, installed all web/.core
Running with commandline like this:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin\MSBuild.exe 
/flp:PerformanceSummary;Summary;LogFile=log.txt;Encoding=UTF-8 /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=Release /p:VSToolsPath=..\Build DouTree/DouTree.sln

If I change Msbuild to C:\Program Files (x86)\MSBuild\14.0\bin then it works OK

Going through the same issue with v15.3 (VS2017) on a brand new server. We first encountered this issue on our old build server, but it had v14 (VS2015) so we hack it to use the older msbuild tool. The goal of the new server is to completely move to v15.3 (VS2017) and it's been a pain with all of the different tools path.

We finally solved it by passing in the MSBuildExtensionsPath32 parameter:

/t:Build /p:Configuration=Debug /p:DeployOnBuild=true /p:PublishProfile=bta /p:MSBuildExtensionsPath32="C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild"

Note: Since this is on the build server, we use _BuildTools_. Your path may differ with _Professional_, _Enterprise_, etc... if execute from your desktop commandline.

This is the entire command as output on our Jenkins build:

Path To MSBuild.exe: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\amd64\msbuild.exe
Executing the command cmd.exe /C " chcp 1252 && "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\amd64\msbuild.exe" /t:Build /p:Configuration=Debug /p:DeployOnBuild=true /p:PublishProfile=bta "/p:MSBuildExtensionsPath32=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild" src\Gsn.Api.Web\Gsn.Api.Web.sln " 

Note, this is because our research indicates that the issue is related to Microsoft.WebApplication.targets, which ours csproj file has:

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

Notice we also updated $(VisualStudioVersion) to 15.0 instead of 14.0 in our csproj file. You may also pass this as a parameter of your MSBuild if you do not want to updated the csproj file. Hope this help the next person.

@noogen So you have _BuildTools_ and _Professional_ installed on your build server?

@ruant Opps, look like my MSBuild config is pointing to the _Professional_ version. I do have both _BuildTools_ and _Professional_, but you don't have to. In my frustration, I tried many different configurations include installing both _BuildTools_ and _Professional_ on my build server. Anyway, I just switch and build with BuildTools just fine:

Path To MSBuild.exe: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64\msbuild.exe
Executing the command cmd.exe /C " chcp 1252 && "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64\msbuild.exe" /t:Build /p:Configuration=Debug src\Gsn.Digital.Web\Gsn.Digital.Web.sln " && exit %%ERRORLEVEL%% from f:\workspace\ci.digitalstore
[ci.digitalstore] $ cmd.exe /C " chcp 1252 && "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64\msbuild.exe" /t:Build /p:Configuration=Debug src\Gsn.Digital.Web\Gsn.Digital.Web.sln " && exit %%ERRORLEVEL%%
Active code page: 1252

Microsoft (R) Build Engine version 15.3.409.57025 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

This new $MSBuildExtensionsPath32 for different Visual Studio version is frustrating. Why can't they just stick to installing it at the old "C:\Program Files (x86)\MSBuild" path?

Also note that, since I'm only setting $MSBuildExtensionsPath32, it does not affect my developers and the different versions of Visual Studio that they are using.

We are experiencing the same problem on vsts. Strangely enough we only have the problem with one of the projects in the solution... The other projects are published fine.

I can see problem still there with VS 2017, update 15.4.5.
I have legacy web site application, which throws a lot of circular reference error, if I precompile it. So decided not to precompile before publish and made a PublishProfile named AUTO_BUILD with Precompile option unchecked.
Publish from IDE of VS2012/2017 is working fine, but not with below command. Still getting circular reference error even after providing PublishProfile attribute to MSBuild.

Anything wrong with this command?
C:\Windows\Microsoft.NET\Framework\v4.0.30319>MSBuild /p:DeployOnBuild=true /p:PublishProfile=AUTO_BUILD>C:buildlog.txt

even same for
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin>MSBuild /p:DeployOnBuild=true /p:PublishProfile="AUTO_BUILD">C:buildlog.txt

@bhumikadave have you try providing MSBuildExtensionsPath32 parameter?

Something like below with MSBuild Tools installed:

/p:MSBuildExtensionsPath32="C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild"

Check my response under xumix. You may need to modify your csproj file too.

Thanks Tom. I'll check that.
As I said, it is website project, so no .vbproj file..I have only
publish.proj

On 01-Dec-2017 6:57 PM, "Tom Noogen" notifications@github.com wrote:

@bhumikadave https://github.com/bhumikadave have you try providing
MSBuildExtensionsPath32 parameter?

Something like below with MSBuild Tools installed:

/p:MSBuildExtensionsPath32="C:\Program Files (x86)\Microsoft Visual
Studio\2017\BuildTools\MSBuild"

Check my response under xumix. You may need to modify your csproj file too.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/msbuild/issues/1901#issuecomment-348494376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AglDTWSFAt9W9Lvam3HOQIvN7icAiqW0ks5s7_7TgaJpZM4Mm-du
.

This doesn't work as well.

I have WebApplication and DeleteExistingFiles option is ignored. Publish seems to be working, but target directory is not cleaned before publish. Why? How to fix it? Publishing from VS works fine.

I can't believe that this issue is not solved by Microsoft. Some issues are marginal, with little hindrance to the overall development process. Yet some issues like this are fatal to an entire organization in upgrades to new technologies. We've encountered this damn error, and we've tried all of the suggestions above (which by the way, when so many ways exist for a problem to be solved, it means that the problem is not a good one) and we haven't succeeded yet.

We're truly stuck at this point, and all we can think of is to stop our CI/CD automation and go back to old school for a while for delivery, which of course sucks. But we have no other choice and we see no responsibility/commitment from Microsoft's part.

I also realized that the latest release of MSBuild is https://github.com/Microsoft/msbuild/releases/tag/v15.4.8.50001, while my installed version that is updated while I updated Visual Studio 2017 to 15.5.2 is 15.5.180.51428.
How that is possible that a newer version of MSBuild ships with VS, but is not released on the MSBuild github?

It turns out I had deleted some conditional imports which broke the zip packaging. The fix was to delete this from the csproj:

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

And replace it with this:

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

I had uninstalled VS2015, and we had updated our CI machines to 15, so v14 being a problem was pretty obvious in hindsight, as many problems are.


Click to expand old post
I've also hit this issue. None of the solutions/workarounds work for me. So far as I can tell, the upgrade from msbuild 15.3 to 15.5 was the thing that broke things on our CI machines. (AFAIK, 15.4 worked for me locally, but the CI versions of msbuild were a little bit behind.)

Output below from the CI machines. In 15.3, this command build a deployable zip:

msbuild.exe /m /nr:false /verbosity:minimal /p:SemanticVersion=2.0.52 /p:Configuration=Release /p:DeployOnBuild=True /p:DeployTarget=Package /p:DeployIisAppPath=Default Web Site
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  CalendaringService -> C:\jenkins\workspace\MSWPP\MSWPP.CalendaringService.Master\src\CalendaringService\bin\CalendaringService.dll
  Transformed Web.config using C:\jenkins\workspace\MSWPP\MSWPP.CalendaringService.Master\src\CalendaringService\Web.Release.config into obj\Release\TransformWebConfig\transformed\Web.config.
  Auto ConnectionString Transformed obj\Release\TransformWebConfig\transformed\Web.config into obj\Release\CSAutoParameterize\transformed\Web.config.
  Copying all files to temporary location below for package/publish:
  obj\Release\Package\PackageTmp.
  Packaging into C:\jenkins\workspace\MSWPP\MSWPP.CalendaringService.Master\src\CalendaringService\obj\Release\Package\CalendaringService.zip.

<snip>

 Adding declared parameter 'IIS Web Application Name'.
  Package "CalendaringService.zip" is successfully created as single file at the following location:
  file:///C:/jenkins/workspace/MSWPP/MSWPP.CalendaringService.Master/src/CalendaringService/obj/Release/Package

With 15.5, no such luck:

msbuild.exe /m /nr:false /verbosity:minimal /p:SemanticVersion=2.0.66 /p:Configuration=Release /p:DeployOnBuild=True /p:DeployTarget=Package /p:DeployIisAppPath=Default Web Site
Microsoft (R) Build Engine version 15.5.180.51428 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  CalendaringService -> D:\Jenkins\workspace\MSWPP\MSWPP.CalendaringService.Pull-Request\src\CalendaringService\bin\CalendaringService.dll
  PerformanceTests -> D:\Jenkins\workspace\MSWPP\MSWPP.CalendaringService.Pull-Request\CalendaringService.PerformanceTests\bin\Release\PerformanceTests.exe
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): warning MSB3277: Found conflicts between different versions of "Microsoft.Owin" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [D:\Jenkins\workspace\MSWPP\MSWPP.CalendaringService.Pull-Request\src\UnitTests\CalendaringService.UnitTests.csproj]
  CalendaringService.UnitTests -> D:\Jenkins\workspace\MSWPP\MSWPP.CalendaringService.Pull-Request\src\UnitTests\bin\Release\CalendaringService.UnitTests.dll

On the CI machines, we're using the VS Build Tools, and the output above is taken from there. Rebuilding SHAs that previously created deployable artifacts doesn't work, so it must be something with msbuild 15.5.

Locally with 2017 Pro, it doesn't work either. I uninstalled and reinstalled, which didn't help, either. I had used versions of VS with msbuild 15.4, and they had worked, so I'm pretty sure it's a change between msbuild 15.4 and 15.5.

Unfortunately, there are no release notes pertaining to 15.5.

I was having the same issue, and I haven't solved it but I have determined why it's happening.

  <!--
    ============================================================
                                        _DeploymentUnpublishable

    This target is used to block an attempt to ClickOnce publish a non-publishable project, such as a ClassLibrary, when building outside the IDE.
    ============================================================
    -->
  <Target
      Name="_DeploymentUnpublishable">

    <Message Text="Skipping unpublishable project."/>

  </Target>

This is a target from Microsoft.Common.CurrentVersion.targets. It checks the PublishableProject property on the .csproj file and if it's not set to true, it will trigger the "Skipping unpublishable project" message. Web projects are not allowed to have this property set to true, I found. I receive this message from MSBuild:

  C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\amd64\Microsoft.Common.CurrentVersi
on.targets(5134,5): error : Publish is only valid for 'Windows Application' or 'Console Application' project types. [C:

According to https://stackoverflow.com/questions/18485070/publish-web-projects-with-msbuild it seems to be by design that you can't publish web projects with msbuild.

I got it working in my custom build tools container as mentioned in this issue.

# Use the latest Windows Server Core image.
FROM microsoft/windowsservercore

# Download useful tools to C:\Bin.
ADD https://dist.nuget.org/win-x86-commandline/v4.1.0/nuget.exe C:\\Bin\\nuget.exe

# Download the Build Tools bootstrapper outside of the PATH.
ADD https://aka.ms/vs/15/release/vs_buildtools.exe C:\\TEMP\\vs_buildtools.exe

# Add C:\Bin to PATH and install Build Tools excluding workloads and components with known issues.
RUN setx /m PATH "%PATH%;C:\Bin" 
RUN C:\TEMP\vs_buildtools.exe --quiet --wait --norestart --nocache --installPath C:\BuildTool \
    --add Microsoft.VisualStudio.Workload.WebBuildTools;includeRecommended \
    --add Microsoft.VisualStudio.Workload.MSBuildTools \
 || IF "%ERRORLEVEL%"=="3010" EXIT 0

ADD https://download.microsoft.com/download/9/0/1/901B684B-659E-4CBD-BEC8-B3F06967C2E7/NDP471-DevPack-ENU.exe C:\\TEMP\\NDP471-DevPack-ENU.exe
RUN C:\TEMP\NDP471-DevPack-ENU.exe /install /quiet /norestart

# SHELL ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "-command"]

# Start developer command prompt with any other commands specified.
# ENTRYPOINT C:\BuildTools\Common7\Tools\VsDevCmd.bat &&

# Default to PowerShell if no other command specified.
CMD ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

And the Dockerfile for publishing my project in a multi-stage docker build:

FROM that-custom-build-tools-container:latest AS build-env
WORKDIR /app

COPY . ./
RUN nuget restore
RUN C:\BuildTool\MSBuild\15.0\bin\msbuild.exe your-project-here.csproj /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=your-profile-here

FROM microsoft/aspnet:4.7.1-windowsservercore-1709
ARG source
WORKDIR /inetpub/wwwroot
COPY --from=build-env /app/output-folder-of-publish ./

same error. vs 2017 last update

We're also having this problem which is preventing us from upgrading our build agents to handle mixed projects (.net core + framework 4.5.1). Can I kindly ask someone from Microsoft team to share any details if this is a known bug / new behaviour and if there are other ways to publish Webapp from msbuild in command lines?
Thank you!

Update:
Adding
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" />
To csproj file made it work.

MSBuild version: 15.5.180.51428

But I got it working even inside a docker container. For me the trick was installing the recommended components from the build tools installer:

& vs_buildtools.exe --quiet --wait --norestart --nocache --installPath C:\BuildTool `
    --add Microsoft.VisualStudio.Workload.WebBuildTools;includeRecommended `
    --add Microsoft.VisualStudio.Workload.MSBuildTools

I'm using Visual Studio 2017 and have the same issue when I execute the following command

msbuild ./MyProject.csproj /p:DeployOnBuild=true /p:PublishProfile=DeployRelease /p:Configuration=Release

The problem was fixed when I executed script in the Developer Command Prompt VS 2017

I do have the same issue... Any solutions?

I wish to execute in a build server...

Adding @vijayrkn

You can find documentation on how to use PublishProfiles from commandline here - https://github.com/aspnet/websdk#folder-publish

Here is a sample project with a PublishProfile:
https://github.com/vijayrkn/dotnetpublishprofilesample/blob/7dac43543173b4ce908921106cc84d810c6dc623/WebPublishCommandlineSample/Properties/PublishProfiles/SampleFolderProfile.pubxml

MSBuild command to publish to a folder using the above publish profile: https://github.com/vijayrkn/dotnetpublishprofilesample/blob/7dac43543173b4ce908921106cc84d810c6dc623/PublishCommandline.txt

I would be happy to take a look at the issue if some one can provide me a sample project & msbuild command that is not working.

I'm also experiencing this. MSBuild 14 and 15. I used @rianjs's targets change in my process of fixing it, and now it works. But a minor issue: targets I build for the publish process execute during normal building now. Although this isn't a problem for me (it's just a webpack bundle I wanted to execute before publishing) it does slow down my builds that don't need to publish, and it could be a problem for others. I'm not sure why it's being triggered. BeforeTargets="PublishOnly" shouldn't really be happening on a normal build.

Using Visual Studio Build Tools 2017 (15.7.4) same problem. The project Build using Jenkins MsBuild plugin (and create a a file with the bin of the C# programme) but it doesn't publish multiple web-services related. Using Visual Studio IDE to publish works ok but want to automate the process if the publishing is Skipped.
Have some one have news to resolve that problem.

I'm not sure this is related but when trying to provide the PublishProfile it is ignored when defined within a custom target, specifying the properties directly in the project element is working

<Target Name="PublishProperties">
    <PropertyGroup>
      <PublishProfile>Package</PublishProfile>
      <DeployOnBuild>true</DeployOnBuild>
    </PropertyGroup> 
  </Target>
  <Target Name="Package" DependsOnTargets="PublishProperties" >
    <CallTarget Targets="Restore;Build"/> 
</Target>

EDIT: Fixed code example, still not working when I run:
msbuild /t:package

only works if I explicitly pass the profile through the command line:
msbuild /t:package /p:PublishProfile=Package

Any movement or news from Microsoft on this or is Microsoft just gonna keep pretending this is not an issue? I provided a sample project & msbuild command that is not working a month ago and have not heard a single word back.

Pretty much until this issue is fixed, automated deployment is dead for anything that needs to transform a web config as a part of that deployment using the latest versions of MSBuild. So thanks guys, great job! ;)

You'd think that with all the releases for Visual Studio that MS puts out these days this issue would of been fixed by now. But nah, instead we got useless warnings instead like those ones about Resharper slowing down VS. This makes me wonder if this is nothing more than MS trying to keep people on Visual Studio by making it so you can only publish your applications via Visual Studio.

P.S. May I suggest that the MSBuild team incorporates some form of regression testing into their development cycle in order to not break existing features when making changes?

@admin-fsoft I'm guessing it's probably very low priority as MS probably pushing everyone onto their cloud TFS and build.

@admin-fsoft - Sorry for not getting back to you sooner. I looked at the repro project that you shared. The issue is that the profile in the repro project only has 'LastUsedBuildConfiguration' property set (https://github.com/admin-fsoft/TestMSBuild/blob/3a1080e3b9d875083200da3cb592119e101c1b7b/TestMSBuild.Web/Properties/PublishProfiles/Release%20Deploy.pubxml#L10).

This property is only used by VS to determine which configuration to change to as part of publish. MSBuild does not know about this property. If you add the following property to the publish profile, then it would work from both VS and commandline.
<Configuration>Release</Configuration>

or you can pass this in the commandline - /p:Configuration=Release

The issue here is specific to configuration. You will notice that publish is honoring all other properties in the publish profile from the commandline (for e.g: it publishes to the publish folder specified in the profile).

Hope this helps!

There are a lot of other issues discussed here. Also the title seems to indicate that commandline publish is not honoring the profile at all. If you look at the repro project provided by @admin-fsoft (Thank you for providing the repro project) you will see that publish does honor the profile properties (for e.g: publishUrl, ExcludeApp_Data etc).

Configuration and Platform are a little different. You will have to either set them in the profile as Configurationand Platform or pass them from the commandline.

LastUsedBuildConfigurationand LastUsedPlatform are VS specific properties.

Thank you for providing an answer and you are correct as this has resolved the problem with the provided test project.

I am now going to go and create a stack overflow question regarding exactly this and answer it so nobody else has to wait 1 month to get an answer. Thanks again.

@vijayrkn - Visual Studio itself is creating that parameter in the publish profile, when you select the configuration to use. If this parameter should not be used, then this seems like a bug in VS.

I was having this problem, and after trying a lot of different things I managed to solve it.

I'm using Build Tools(MSBuild v14.0) for building my project in a Jenkins job, and in my case the problem was that I was missing some Web Publishing Dlls.

I was able to get them from here: https://www.nuget.org/packages/MSBuild.Microsoft.VisualStudio.Web.targets/14.0.0.3

Putting them on the following directories solved my problem:
C:\Program Files(x86)\Microsoft\VisualStudio\v14.0\Web
C:\Program Files(x86)\Microsoft\VisualStudio\v14.0\WebApplications

@rafabaldoni That wasn't it. For me, the problem was something specific in the csproj file. It was a very old .csproj and had been converted through several steps (I think it originally dates back to VS 2003). I ended up just creating a new default projects and copying all the files and settings to the new one. Then publish started working again.

@efunkenbusch Yeah, maybe there are different problems that result in the same error... If someone is experiencing the same problem I had they might be able to solve it with my comment anyway.

I meet the same problem.

There really is one core problem with the SDK and msbuild... there's zero accountability of dependencies

The csproj file since VS2010 is a mismash of msbuild targets that are yanked in via various ways, with zero dependency management.

Then when msbuild moves from v14 to v15, it all breaks again, because your csproj file doesnt know to say "hey, I need the targets file from Microsoft.NET.SDK.v14.xxxx" with a package manager (I keep hoping nuget will finally figure out how to do proper package dependency management but keep getting disappointed year after year)

Your core problem is usually this: Most of the time, your problem is missing Web.Application.targets file or a Web.Application.targets file that is a different version to what your csproj file is configured for. Not to mention, project upgrades in VS dont seem to deal with this, and leave the old configurations sitting around to muck up the new targets and again, we've traded DLL hell for TARGETS hell.

The answer has always been nuget to some degree, yet has been very slow to get integrated properly due to MS internal emp lack of understanding of whats going on out here, and the opaque nature at how it all worked for a while... with MS finally putting everything up on github, there's a lot more transparency and visibility, and people in the real world able to say "um, guys... that just doesnt make sense beyond basic assumptions"

Found an alternative. Adding a FileSystemPublish task after Publish helps. My command looks something like this.
msbuild application.sln /t:"clean;publish;filesystempublish" /p:PublishProfile=folderprofile

In my case I was dealing with an old web app that was created with an old version of VS I am guessing 2010 or 2012. It did not have project file, just a solution file. Same issue msbuild was ignoring the parameters when I passed the solution file as the parameter, so this is what I did....

msbuild website.publishproj /p:PublishProfile=OnCUWire_publish /p:DeployOnBuild=true /p:Configuration=Debug

website.publishproj is a file that VS created instead of the regular csproj. So by passing it to msbuild was able to publish it as the profile indicated.
I hope this helps

I am going to close this issue as there are many different conversation going on here and I believe the original question has been addressed by Vijay earlier in the thread.

First, thank you @richardszalay
I struggled to find a solution, until I found this answer on Stack Overflow: How to use MsBuild MsDeployPublish to target local file system?

Quoting the answer of the link above:

As per my answer from Using MSBuild, how do I build an MVC4 solution from the command line (applying Web.config transformations in the process) and output to a folder?

msbuild ProjectFile.csproj /p:Configuration=Release ^
                           /p:Platform=AnyCPU ^
                           /t:WebPublish ^
                           /p:WebPublishMethod=FileSystem ^
                           /p:DeleteExistingFiles=True ^
                           /p:publishUrl=c:\output

Or if you are building the solution file:

msbuild Solution.sln /p:Configuration=Release ^ 
                     /p:DeployOnBuild=True ^
                     /p:DeployDefaultTarget=WebPublish ^
                     /p:WebPublishMethod=FileSystem ^
                     /p:DeleteExistingFiles=True ^
                     /p:publishUrl=c:\output

You can also target the project via the solution using the /t:SolutionFolder/Project:Target syntax:

msbuild Solution.sln /t:SolutionFolder/ProjectFile:WebPublish ^
                     /p:Configuration=Release ^ 
                     /p:WebPublishMethod=FileSystem ^
                     /p:DeleteExistingFiles=True ^
                     /p:publishUrl=c:\output
Was this page helpful?
0 / 5 - 0 ratings