sdk: Unable to publish multiple projects at the same time.

This is a 3 year old issue that should be trivial to fix, so I’m not sure why this is still lingering around? Several suggested solutions have been presented and even the referencing issues to this one outline how this mistake came to be.

1. What we need is to either have the -o append each project name (just like pack is doing) to create a sub folder for each project.
2. Or allow us to add a variable argument to the output path that is replaced.

It does not make sense to dump everything to a single folder when publishing a solution and I would argue that when it would, this feature would be the minority and you would want a flag to enable it as the amount of issues this can cause has been outlined in other issues.

For now, I have choosen to build tooling around my tooling and removed the -o param and have instead wrote a script to recursively find all the publish folders generated under each project and to move them to a root level folder.

Closing issue, there is probably an alternative by now.

@joelharkes why was this closed? There is no alternative solution and nothing in this issue suggests there is.

@piotrpMSFT I think multi publish should be considered.

Our architecture is made up of 2 kestrel console apps and 3 other console applications. now i have to execute 5 times dotnet publish. 5 times going over library projects and all executing in synchronous order (otherwise i don’t know if it will run into locking problems with trying to build the same project). This is a lot of overhead. if this is managed by the CLI, projects could be run asynchronously, speeding up the build performance with a big factor.

@neman That is exactly what you want to avoid for 2 main reasons:

• They ported back to msbuild so you could use an msbuild file for this instead of powershell
• This is either: Slow because its all executed after each other or gets into locking issues because trying to build multiple projects at once.

I made a script that builds the dependency trees for all projects and then executes builds in parallel (Promises nodejs) according to the builds. I got a major decrease in build/publish time (on a multi core environment).

Too bad though our build server agents only use 1 processor per agent but, but locally for developers its still better this way.

I’ve managed to bring down build+test time by using msbuild scripts like this (even in non-parallel builds): https://gist.github.com/dasMulli/69f5303aa79a8cd4060e44891c90fd2d

Essentially, making a single build.proj file that calls publish on others via <MSBuild/> tasks (=> dotnet msbuild build.proj.

^ would be nice to have something like this for Github Actions!

This is can be easy be done with powershell script. You just have to create for each project build/publish script, and then execute it within loop. This way I build/publish/create nuget/push nuget with one command for more than 30 projects in one solution.

This code could be in some PublishMultipleProjects.ps1 script. You can extend this by adding parms what to include and so on…

Push-Location $PSScriptRoot     
$files = get-childitem -Recurse -Include "Build.ps1"   
foreach ($file in $files)    
{   
    # Execute each Build.ps1 script   
    & $file   
}   
Push-Location $PSScriptRoot

found this which seems relevant:

https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish You can publish a solution (not just a project).

dotnet publish YourSolution.sln -c Release -p:PublishDir=.\publish

If you specify a relative path when publishing a solution, all output for all projects goes into the specified folder relative to the current working directory. To make publish output go to separate folders for each project, specify a relative path by using the msbuild PublishDir property instead of the --output option. For example, dotnet publish -p:PublishDir=.\publish sends publish output for each project to a publish folder under the folder that contains the project file.

this was added in .NET Core 3.0

This would be helpful for us.

something like:

dotnet publish -o OutDir -PublishAllSeparately

dotnet publish -o OutDir -ProjectsSeparated Project1,Project2,Project3

The it could publish them in folders individually or just publish the ones specified in the folders (sometimes there’s libraries in the solution you wouldn’t want published by itself)

It finally works!

I hope this helps someone else out; it did work for my pipeline, building multiple project with one command. After trying multiple configurations, this is what worked for me.

I added modifyOutputPath: true to the dotnet publish task and it seems to work now with -o <root directory> argument. I have not tested with dotnet build or other commands.

my YAML task:

- task: DotNetCoreCLI@2
  displayName: 'dotnet publish'
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '**/*.csproj'
    arguments: '-p:Version=$(Version) -o $(Build.ArtifactStagingDirectory) --no-restore'
    zipAfterPublish: false
    modifyOutputPath: true    <------ add this

We build a single docker image for our Api and Cli projects (we use the Cli project to run k8s jobs, like run migrations before deploying the new Api version). We want to publish those two projects and their dependencies without having the test projects and their dependencies.

Since this issue was reported nearly 5 years ago, someone bothered to change the error instead of resolving the actual issue: MSBUILD : error MSB1008: Only one project can be specified.

Based on the comment from @williamdenton we can have both scenarios described here (publish to separate folders and publish to a single folder) for a solution file. So why not for multiple projects from the command line? Sure, I can create a .sln for any combination of projects I’d want to publish in a single go but surely it shouldn’t be too difficult to just fix this?

@Lanayx no this is exactly what doesn’t work, and what brought me to this issue. Running dotnet publish -o outputPath on the solution will not create a separate folder for each project, it will dump everything into the single folder outputPath.

@gandarez when you say “The MSBUILD does not have that behaviour”, how have you been using msbuild? the msbuild equivalent of dotnet publish -o foo would be msbuild /t:Publish /p:PublishDir=foo. If you have been using /p:DeployOnBuild=true with a publish profile, that is a different way of publishing specific to asp.net and asp.net core and may behave differently. It should also be noted that if you pass a relative path to the -o parameter, it is always interpreted relative to the individual csproj file, not relative to the path the dotnet publish command is invoked from.

@KathleenDollard The solution contains two web api core projects and I’m using dot net publish to publish them. But the cli put every single project to the same root output directory. The MSBUILD does not have that behaviour, it groups each project in its respective folder.

@blackdwarf will propose the intention change here.