SDK doesnt publish exes correctly when used as a project reference

[jaredpar]

Often a group of exes need to be built and deployed together. This is common in applications like Roslyn where we ship several exes as a single unit: csc, vbc and VBCSCompiler.

Rather than building each project separately and then copying the outputs together we create deployment projects. Essentially dummy exes projects that just reference all of the exes that we need via project reference elements

<ProjectReference Include="..\..\src\Compilers\CSharp\csc\csc.csproj" />
<ProjectReference Include="..\..\src\Compilers\VisualBasic\vbc\vbc.csproj" />
<ProjectReference Include="..\..\src\Compilers\Server\VBCSCompiler\VBCSCompiler.csproj" />

This approach works fine in desktop MSBuild as it will correctly deploy all of the runtime assets. The same approach does not work on SDK projects though as the publish step fails to include critical files like deps.json and runtimeconfig.json. That completely breaks this approach.

If this isn't meant to be supported by SDK that would be unfortunate but understandable. I would expect an error though positively asserting that this case is not supported. Today everything builds and publishes without error but the output is completely unusable.

Repo:

Clone https://github.com/jaredpar/roslyn and checkout the branch repro/group-exe. Then run the following commands:

> dotnet restore build/ToolsetPackages/BaseToolset.csproj
> dotnet restore build/ToolsetPackages/CoreToolset.csproj
> dotnet restore build/Toolset/CoreToolset.csproj
> dotnet publish -o ${HOME}/temp/test --framework netcoreapp2.0 build/Toolset/CoreToolset.csproj

The directory ${HOME}/temp/test should contain the deps.json / runtimeconfig.json for csc, vbc and VBCSCompiler but it does not. That means the output of publish is unusable.

CC @khyperia

[livarcocc]

So, if I understand this correct, you have a project that references three other self-contained netcoreapp projects as project references and you expect that publish this aggregator project will also publish all its references as an app?

If that's the case, you are right, we do not support that. P2P references are treated as libraries and not applications. In order to accomplish this I think you could change your aggregator project to have a list of projects that it needs to publish and for you to invoke publish in each of them separately.

[jaredpar]

. In order to accomplish this I think you could change your aggregator project to have a list of projects that it needs to publish and for you to invoke publish in each of them separately.

That doesn't quite get the behavior we want though. Part of the advantage to using the <ProjectReference> route is that MSBuild hepls ensure we have consistent dependencies across the projects. If any dependencies are wrong the standard warnings around conflicts will come into play.

This is important because the versions need to be consistent in order to ensure the exes will run correctly when all their dependencies are dumped into a single directory.

If that's the case, you are right, we do not support that. P2P references are treated as libraries and not applications

In that case why do the app.config files get deployed at all? Thats only relevant when running the application. I would assume, possibly wrong, that app.config, runtimeconfig.json and deps.json would all be deployed or none.

[dsplaisted]

I would also like some way to publish multiple apps to the same folder (and correctly handle the dependencies).

However, it's not as simple as copying the additional files when an app project is referenced. The deps.json and runtimeconfig.json will have been generated within the context of the app's dependencies. If the "publish" project ends up resolving different versions of those dependencies, then the versions deployed won't match what the app is expecting, which I think could lead to failures.

[jaredpar]

If the "publish" project ends up resolving different versions of those dependencies, then the versions deployed won't match what the app is expecting, which I think could lead to failures.

Exactly. We want these failures. It tells us that we screwed up our dependencies 😄

[dsplaisted]

Here's a potential workaround that includes the deps.json and runtimeconfig.json in the files that referenced projects will copy.

  <!-- Include MSBuild.deps.json and MSBuild.runtimeconfig.json in ContentWithTargetPath so they will be copied to the output folder of projects
       that reference this one. -->
  <Target Name="AddRuntimeDependenciesToContent" Condition=" '$(TargetFrameworkIdentifier)' == '.NETCoreApp'" BeforeTargets="GetCopyToOutputDirectoryItems">
    <ItemGroup>
      <ContentWithTargetPath Include="$(ProjectDepsFilePath)" CopyToOutputDirectory="PreserveNewest" TargetPath="$(ProjectDepsFileName)" />

      <ContentWithTargetPath Include="$(ProjectRuntimeConfigFilePath)" CopyToOutputDirectory="PreserveNewest" TargetPath="$(ProjectRuntimeConfigFileName)" />
    </ItemGroup>
  </Target>

[jaredpar]

@dsplaisted

How supported is that work around? This is a feature we sorely miss since switching to the new SDK / Exes (lots of duplication + missed errors). If this is fairly supported we'd consider switching to use it.

[dsplaisted]

@jaredpar I wouldn't call it supported. The problem is going to be if the different Exes have different versions of shared dependencies. If that's not the case, then I think everything should work well.

[jaredpar]

If it's not supported I'm rather hesitant to move to it. Depending on unsupported features is equally painful to both our teams when they eventually get broken

[ericstj]

@dsplaisted what part of this are you feeling like is unsupported? Ensuring the workaround stays working? Seems like we can just add a test case to make sure that is true. If the SDK does add support for this then you can make sure you won't break the workaround. I don't think there is anything fundamentally wrong with flowing the deps/runtimeconfig along with other things. I can see how this might be important for other project types like NuProj/WixProj/Azure-packages/etc.

It sounds like @jaredpar's not asking us to vouch for the deployment strategy of combining apps into a single directory as "supported" since he's expecting it to fail sometimes if they do the wrong thing and mentioned they'll need to test for that.