dotnet publish solution with ARM template project fails

[jeroenwo]

Steps to reproduce

Create a VS 2017 solution with an Azure Resource Group project and add an empty ARM template.

Run the following command:
dotnet publish [location of solution] -c release -o [output directory] --verbosity normal
(my example: dotnet publish C:\Temp\buildtest\buildtest\buildtest.sln -c release -o c:\temp\build --verbosity normal)

Even though there is no .NET Core project included, these steps will reproduce the problem of a larger scale solution.

Expected behavior

The publish step succeeds, no application is published. (As an ARM template is Azure specific and there is no .NET Core application code.)

Actual behavior

The publish step fails with the following error:

C:\Program Files\dotnet\sdk\2.0.2\Microsoft.Common.CurrentVersion.targets(3845,5): error MSB3030: Could not copy the file "obj\Release\TestArm.exe" because it was not found. [C:\Temp\buildtest\buildtest\TestArm\TestArm.deployproj]

The targets file contains a ClickOnce section at the mentioned location:

<!-- Copy the application executable from Obj folder to app.publish folder.
    This is being done to avoid Windows Forms designer memory issues that can arise while operating directly on files located in Obj directory. -->
    <Copy
      SourceFiles="@(_DeploymentManifestEntryPoint)"
      DestinationFolder="$(PublishDir)">

      <Output TaskParameter="DestinationFiles" ItemName="_DeploymentClickOnceApplicationExecutable" />
    </Copy>

Environment data

dotnet --info output:
.NET Command Line Tools (2.0.2)

Product Information:
Version: 2.0.2
Commit SHA-1 hash: a04b4bf

Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.2\

Microsoft .NET Core Shared Framework Host

Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

[livarcocc]

This is by design. We don't restrict the kind of projects being build by the CLI and at this point, what we do is invoke MSBuild to build the project.

We do this, because given the very nature of MSBuild, we would not be able to predict if a project is buildable by MSBuild or not.

Is this particular case, this fails in the CLI because this project uses MSBuild props/targets that are not available to the CLI.

Lastly, skipping a project and silently claiming success would be the wrong thing to do here, as it would give people the impression that the CLI managed to successfully build their project, when in reality it did nothing. It would lead to confusion and questions along the lines of "where is my build output, etc".

[jeroenwo]

Thanks for your response! As I am new to using the CLI, I hope you can clarify some things for me..

You, as well as this SO post have explained that the dotnet CLI invokes MSBuild to build the project.

Is there a way I can publish an extending amount of .NET Core applications using MSBuild and my solution (without modifying the build definition every time an application is added):

• so it doesn't break with the above-mentioned error?
• and I can keep all pieces of the puzzle together in the VS solution (including the ARM template)?

As to your remark about leading to confusion: I was quite confused to receive a ClickOnce error when my solution didn't use that.. :) I wasn't aware that for publishing a deployproj there are apparently more props/targets required by MSBuild.

[erick-thompson]

It would be really nice if publish would simply copy the project contents to the publish folder. I want to include the artifacts needed to deploy the application with the application.

[jeroenwo]

@erick-thompson: I have now separated my projects into two solutions. One for the application code and one for the ARM template. Both these solutions reside in the same repository and are triggered the same way. In the release itself I add both the artifacts so I can use them:

1. Create Azure resources using the ARM template
2. Deploy the application code to the created resources

[erick-thompson]

I ended up taking a similar approach, but with linked items so the items get copied over automatically during the build/publish. It's not perfect, but it does work.

[PawelBaranowski]

Hello, I'm terribly late to the party, but stumbled upon this issue today and found an easy fix.
In my .deployproj file I added one line to a <PropertyGroup>:

+ <OutputType>Library</OutputType>

It looks that the OutputType defaults to Exe in this case. Simply forcing it to Library makes dotnet publish succeed.
Hope this helps someone.