"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.0\build\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.0\build\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 - dotnet/msbuild#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.

[ThomasPorterAVEVA]

Hello from the year 2021 A.D.
Good: We are post .NET 5 support for Service Fabric with v8
Bad: It appears there is still no full support for packaging an sfproj file using the dotnet command line.

The sfproj file format is still very much in Framework (and required a packages.config for NuGet). Does anyone have any other information on if sfproj projects will be modernized?

This issue that seems relevant: #885

[ghost]

Bad: It appears there is still no full support for packaging an sfproj file using the dotnet command line.

My team has been on (unsupported) dotnet build of sfproj for about 6 months and it appears stable. You linked to the relevant thread, workaround provided there. But I understand your frustration -- a supported approach would be preferable.

@masnider Engaged the sfproj owners on that thread to try and get you a better answer there.

[ThomasPorterAVEVA]

Thanks for the suggestion, but, as you suspected, we need something more official for our official development.

Although it wouldn't hurt to do a proof of concept with that solution for my own personal Service Fabric knowledge.