Service-fabric: Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.8 gives build errors

[FernandoNunes]

After upgrading to Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.8 from Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7 our .sfproj started failing Building on Azure DevOps Builds.

It generates obj\netcoreapp.2.2 and bin\netcoreapp2.2\ and compiles StatelessServices but then fails copying the Services .dll files to Publish folder.

At the moment I can't share any logs, but was to check if anyone has these same issues or solution for the issue.

By the way, we're using .NET Core 2.2.5 using SDK (2.2.107) and restoring packages with Nuget 4.9.3

[festivus]

Yes, I had the same problem. Packaging from visual studio worked, running msbuild with t:/Package failed. Couldn't find the compiled dlls to copy to the package folder, seemed to be looking in the wrong place. I had to revert everything and start over. The 2nd time I upgraded all the nuget pkgs except Microsoft.VisualStudio.Azure.Fabric.MSBuild. I left it at 1.6.7 and things seem ok.

[Adebeer]

Thanks for the info - I had same issue trying to figure out misleading MSB3030 error on Azure DevOps. Rolling back to 1.6.7. fixed issue.

Error trying to compile Asp.Net.Core 2.2 API Stateless service

_CopyResolvedFilesToPublishPreserveNewest:
  Copying file from "d:\a\1\s\Src\Apps\MyProjXyZ\ApiGateway\appsettings.json" to "d:\a\1\s\Src\Apps\MyProjXyZ\ApiGateway\obj\Release\netcoreapp2.2\win7-x64\PubTmp\Out\appsettings.json".
  Creating directory "d:\a\1\s\Src\Apps\MyProjXyZ\ApiGateway\obj\Release\netcoreapp2.2\win7-x64\PubTmp\Out\Connected Services\Application Insights".
  Copying file from "d:\a\1\s\Src\Apps\MyProjXyZ\ApiGateway\Connected Services\Application Insights\ConnectedService.json" to "d:\a\1\s\Src\Apps\MyProjXyZ\ApiGateway\obj\Release\netcoreapp2.2\win7-x64\PubTmp\Out\Connected Services\Application Insights\ConnectedService.json".
##[error]C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(169,5): Error MSB3030: Could not copy the file "obj\Release\netcoreapp2.2\win7-x64\ApiGateway.dll" because it was not found.
C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(169,5): error MSB3030: Could not copy the file "obj\Release\netcoreapp2.2\win7-x64\ApiGateway.dll" because it was not found. [d:\a\1\s\Src\Apps\MyProjXyZ\ApiGateway\ApiGateway.csproj]
##[error]C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(169,5): Error MSB3030: Could not copy the file "obj\Release\netcoreapp2.2\win7-x64\ApiGateway.pdb" because it was not found.

[clazarr]

I'm seeing the same behavior when attempting to package Service Fabric stateless services targeting full .NET Framework (net462) - "C:\Program Files\dotnet\sdk\2.2.103\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(169,5): error MSB3030" with similar path as @Adebeer is seeing since upgrading from 1.6.7 to 1.6.8 on Azure DevOps with MSBuild v15.0. "Package" from Visual Studio 2019 works fine on my local machine.

[jahmai-ca]

I'm getting

error MSB4057: The target "Package" does not exist in the project.

[somanysteves]

Any word on this, or is downgrade the official stance?

[vladislav-karamfilov]

I now see that 1.6.9 is released and upgraded to it. The build and deploy in Azure DevOps were successful. I guess this version included the fix for this problem but someone from the SF team can confirm that this is the correct path to move on.

[nacitar]

I ran into this... it looked like it was manifesting in service fabric projects with an internal service that is a Web project and are also x64 only (no AnyCPU) and it looked like the disconnect was where the build was putting the intermediate output files and where the sfproj Package target was expecting them to be...
The correct fix is to either use 1.6.7 or 1.6.9 to have a real fix, but I did find that this workaround worked when I was testing...
/p:IntermediateOutputPath=obj\x64\Release\
Adding that ONLY to the /t:Package of the sfproj file (not the building of the solution!) works around the problem... but, again, just bump the version for a real fix.