New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSBuild commandline seems to ignore publish properties #1901

Open
comburo opened this Issue Mar 23, 2017 · 92 comments

Comments

Projects
None yet
@comburo
Copy link

comburo commented Mar 23, 2017

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.

@oexenhave

This comment has been minimized.

Copy link

oexenhave commented Mar 29, 2017

+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

@frbar

This comment has been minimized.

Copy link

frbar commented Mar 31, 2017

Same for me.

@faemm

This comment has been minimized.

Copy link

faemm commented Apr 11, 2017

Same for me too,

@ducseb

This comment has been minimized.

Copy link

ducseb commented Apr 21, 2017

Same for me

1 similar comment
@ewilli

This comment has been minimized.

Copy link

ewilli commented Apr 24, 2017

Same for me

@frbar

This comment has been minimized.

Copy link

frbar commented Apr 24, 2017

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?

@tran-barry

This comment has been minimized.

Copy link

tran-barry commented Apr 24, 2017

Same here

@deadlydog

This comment has been minimized.

Copy link

deadlydog commented Apr 26, 2017

Same for me

@jamest-iqmetrix

This comment has been minimized.

Copy link

jamest-iqmetrix commented Apr 26, 2017

Same here.

@vicp-iq

This comment has been minimized.

Copy link

vicp-iq commented Apr 26, 2017

Ditto.

@RyanMarcotte

This comment has been minimized.

Copy link

RyanMarcotte commented Apr 26, 2017

Same here

@andrewk-iq

This comment has been minimized.

Copy link

andrewk-iq commented Apr 26, 2017

Me as well

@shkup

This comment has been minimized.

Copy link

shkup commented Apr 27, 2017

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

@VincentLangevin

This comment has been minimized.

Copy link

VincentLangevin commented Apr 27, 2017

I'm also encountering the same problem

@rainersigwald

This comment has been minimized.

Copy link
Contributor

rainersigwald commented Apr 27, 2017

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.

@mattlwilliams

This comment has been minimized.

Copy link

mattlwilliams commented Apr 27, 2017

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
@frbar

This comment has been minimized.

Copy link

frbar commented Apr 28, 2017

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).

@adam-knights

This comment has been minimized.

Copy link

adam-knights commented May 3, 2017

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

@ehaackXceligent

This comment has been minimized.

Copy link

ehaackXceligent commented May 10, 2017

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

@doughless

This comment has been minimized.

Copy link

doughless commented May 12, 2017

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).

@ewilli

This comment has been minimized.

Copy link

ewilli commented May 15, 2017

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

@ehaackXceligent

This comment has been minimized.

Copy link

ehaackXceligent commented May 15, 2017

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

[Edit: clarification]

@ducseb

This comment has been minimized.

Copy link

ducseb commented May 16, 2017

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

@rainersigwald

This comment has been minimized.

Copy link
Contributor

rainersigwald commented May 16, 2017

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 . . .

@faemm

This comment has been minimized.

Copy link

faemm commented May 19, 2017

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

@Grandpappy

This comment has been minimized.

Copy link

Grandpappy commented May 25, 2017

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.

@rainersigwald

This comment has been minimized.

Copy link
Contributor

rainersigwald commented May 25, 2017

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

@mInternauta

This comment has been minimized.

Copy link

mInternauta commented Jun 1, 2017

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

@emilegg

This comment has been minimized.

Copy link

emilegg commented Jun 12, 2017

Hi, still have the same issue. :/

@nefcanto

This comment has been minimized.

Copy link

nefcanto commented Dec 24, 2017

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.

@nefcanto

This comment has been minimized.

Copy link

nefcanto commented Dec 24, 2017

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?

@rianjs

This comment has been minimized.

Copy link

rianjs commented Feb 8, 2018

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.

@davvves

This comment has been minimized.

Copy link

davvves commented Feb 9, 2018

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.

@riezebosch

This comment has been minimized.

Copy link

riezebosch commented Feb 12, 2018

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 ./
@cSharpProCompany

This comment has been minimized.

Copy link

cSharpProCompany commented Mar 1, 2018

same error. vs 2017 last update

@damtur

This comment has been minimized.

Copy link

damtur commented Mar 5, 2018

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!

@damtur

This comment has been minimized.

Copy link

damtur commented Mar 5, 2018

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

@riezebosch

This comment has been minimized.

Copy link

riezebosch commented Mar 5, 2018

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
@aliakseimaniuk

This comment has been minimized.

Copy link

aliakseimaniuk commented Mar 7, 2018

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

@blkrishnan2k

This comment has been minimized.

Copy link

blkrishnan2k commented Mar 9, 2018

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

@blkrishnan2k

This comment has been minimized.

Copy link

blkrishnan2k commented Mar 9, 2018

I wish to execute in a build server...

@mlorbetske

This comment has been minimized.

Copy link

mlorbetske commented Mar 29, 2018

Adding @vijayrkn

@vijayrkn

This comment has been minimized.

Copy link
Member

vijayrkn commented Mar 29, 2018

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.

@IronSean

This comment has been minimized.

Copy link

IronSean commented May 10, 2018

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.

@admin-fsoft

This comment has been minimized.

@brunoAmado

This comment has been minimized.

Copy link

brunoAmado commented Jul 6, 2018

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.

@dejoost

This comment has been minimized.

Copy link

dejoost commented Jul 10, 2018

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

@admin-fsoft

This comment has been minimized.

Copy link

admin-fsoft commented Jul 11, 2018

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?

@noogen

This comment has been minimized.

Copy link

noogen commented Jul 11, 2018

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

@vijayrkn

This comment has been minimized.

Copy link
Member

vijayrkn commented Jul 11, 2018

@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!

@vijayrkn

This comment has been minimized.

Copy link
Member

vijayrkn commented Jul 11, 2018

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 Configuration and Platform or pass them from the commandline.

LastUsedBuildConfiguration and LastUsedPlatform are VS specific properties.

@admin-fsoft

This comment has been minimized.

Copy link

admin-fsoft commented Jul 12, 2018

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.

@efunkenbusch

This comment has been minimized.

Copy link

efunkenbusch commented Oct 29, 2018

@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.

@rafabaldoni

This comment has been minimized.

Copy link

rafabaldoni commented Dec 6, 2018

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

@efunkenbusch

This comment has been minimized.

Copy link

efunkenbusch commented Dec 6, 2018

@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.

@rafabaldoni

This comment has been minimized.

Copy link

rafabaldoni commented Dec 6, 2018

@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.

@qcmiao1998

This comment has been minimized.

Copy link

qcmiao1998 commented Dec 20, 2018

I meet the same problem.

@ericnewton76

This comment has been minimized.

Copy link

ericnewton76 commented Jan 7, 2019

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment