Service-fabric: "dotnet msbuild /t:package" doesn't work

[Aleksanderis]

Not sure if it was already discussed - I found some similar topics, but still not exactly same.

I got some real challenges mixing Service Fabric and .NET Core solution.
Through Visual Studio and using C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe myproj.csproj /t:package - everything builds and works fine. However it's not possible to build it on other machines with no VS2017 installed (e.g. CI server), eventhough there is latest .NET Core SDK present.

So the issue is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe myproj.csproj /t:package - works
But:
dotnet msbuild myproj.csproj /t:package - doesn't work and throws:

c:\Projects\MyProj\Source\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.5.0build\Microsoft.VisualStudio.Azure.Fabric.Application.targets(77,5): error MSB4018: The "ValidatePackageSettings" task failed unexpectedly.
c:\Projects\MyProj\Source\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.5.0build\Microsoft.VisualStudio.Azure.Fabric.Application.targets(77,5): error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified. [c:\Projects\MyProj\Source\MyProj.sfproj]

There is an older Visual Studio 2015 present with msbuild 14.0 on CI server, but it also doesn't work, because it fails to parse .NET Core *.csproj files.

Is it really the only option to install VS2017 on CI server? My first impression was that dotnet msbuild is same as msbuild.exe and self-sufficient without VS2017. Also in Microsoft docs (https://docs.microsoft.com/en-us/visualstudio/msbuild/what-s-new-in-msbuild-15-0) it says - MSBuild is now available as part of the .NET Core SDK and can build .NET Core projects on Windows, macOS, and Linux.

Am I doing something wrong, or is it a known issue? Can it be workarounded somehow? Currently *.sfproj files look a bit outdated comparing to .NET Core projects - which is not bad in general, but it's just hard to mix these two worlds.. I have a feeling that we either need to drop .NET Core, or Service Fabric in our project..

Update:
I also investigated VS2017 Build Tools, which is a separate thing, not needed to have VS2017 installed. It sounds like a good option for CI builds, however this guy doesn't have proper support for .NET Core projects.. (related issue - https://github.com/Microsoft/msbuild/issues/1697). So once again - it's hard to mix both worlds.

[cwe1ss]

I'm having the same issue. I'd love to see this "just work" with dotnet publish on the sfproj project.

[mikkelhegn]

@ravipal

[ravipal]

We support dotnet core services, but the application project (*.sfproj) is still '.Net Framework', so dotnet msbuild is not supported.

[Aleksanderis]

@ravipal, yes, I understand it, but the problem that from one side dotnet msbuild is not supported, from another (from .NET Core services) - "classic" msbuild is not supported (it cannot build .NET Core *.csproj). So it's a lose-lose situation.
It's just a slight step aside from happy-path, when it stops working. Both technologies are part of Microsoft stack, that's why it's so strange.

Do you know if there are any close plans to fix such incompatibilities? E.g. adding support for *.sfproj in new format, to make it fully compatible with .NET Core projects, or maybe something else?

[klettier]

I'm sad that one year later this is still an issue :(
I ended up doing

• Restore each dotnet core projects separately (dotnet restore)
• Restore nuget packages on solution (nuget restore)
• Package SF project file (msbuild /t:package)

This is for the moment the quickest way to build an SF solution mixing dotnet core projects and SF project.

[devlie]

We are doing something similar where we do:

1. dotnet restore on .NET Core csproj
2. dotnet build on .sln
3. nuget restore on .sln
4. msbuild /t:package on sfproj

But we found that msbuild /t:package always execute build instead of just packaging. Is there a way to skip build when packaging?

[abatishchev]

Why not dotnet pack then?

[klettier]

@devlie you should be able to remove dotnet build on sln and use msbuild /t:package to build and produce package

[devlie]

@abatishchev , as far as I know, dotnet pack doesn't support packaging SF package.

@klettier I could have, but msbuild /t:package only builds SF app's dependencies (my service code), and I have my client code csproj in the same solution which is not getting built. Can be solved with custom steps, was just wondering if there's anything more convenient 🤔

[abatishchev]

Right! It doesn't. Sorry, got confused.

We're using "raw" nuspec to package SF: pkg -> sfpkg -> nupkg.