Improvements in sfproj file format

[am11]

The CPS-based csproj and vbproj has brought a revolution not only in project system, but also the project file format. For instance:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

</Project>

It would be a wonderful improvement if all default target calls are wrapped into a ServiceFabric SDK (with option to override them in infrequent scenarios), so that the template project file will looks like:

<Project Sdk="Microsoft.Azure.ServiceFabric.Sdk">

  <ItemGroup>
    <ProjectReference Include="{path-to-my-csproj}" />
  </ItemGroup>

</Project>

This will:

• reduce the 47 lines of XML in template to 5-7 lines
• implicitly include all configs that are under ApplicationPackageRoot, ApplicationParameters, PublishProfiles and Scripts directories.
  • user can override it with a property like DefaultItemExcludes (that new csproj provides) for this purpose.
• waive the requirement of having a separate packages.config that typically has Microsoft.VisualStudio.Azure.Fabric.MSBuild.

---

PS: is SF team considering to upstream the MSBuild patches to https://github.com/Microsoft/msbuild, so we are not required to pull Microsoft.VisualStudio.Azure.Fabric.MSBuild separately?

[Mardoxx]

Can't for the life of me find it... but I am sure I read that one of the SF team said that this was in the works and would cone once better xplat support was released? (Sf on linux?)

[mkosieradzki]

Just to make sure that one important option is not removed.

I am changing inide all sfprojs DefaultTargets to "Package". It's very important because I am building multiple Service Fabric Projects as part of one VS Solution.

So in the new format I need to enable building packages on CI/CD pipeline easily.

[mikkelhegn]

@dbreshears

[Igorbek]

I was sure that microsoft/service-fabric-issues#194 was about that change, but apparently it only covered services projects and not .sfproj. Is any plans to support SDK-based format of .sfproj that would use modern packaging (through PackageReference)? /cc @ravipal @dbreshears

[NickDarvey]

If there's any work being done on the project system, please also consider making it compatible with props and targets from NuGet packages. Right now NuGet doesn't generate a obj/*.sfproj.nuget.g.targets or obj/*.sfproj.nuget.g.props file like it would for a csproj.

cc @ravipal

[lkts]

Hi everyone, are there any updates on this? Current sfproj format causes annoying issues like https://github.com/Azure/service-fabric-issues/issues/840 when using ASP.NET Core projects with Fabric. Basically recommended for such projects "dotnet restore" functionality is not available to use now.

[am11]

With built-in custom SDK resolution implemented in MSBuild and recent improvements in NuGet APIs, SDK trend has started to gain more traction. One concise example is: https://github.com/Microsoft/MSBuildSdks/tree/5580d48/src/Traversal. Another example which doesn't require an extra .nuspec file: https://github.com/aspnet/Razor/tree/a13a0aa/src/Microsoft.NET.Sdk.Razor

@MikkelHegn, @jeffkl, would it be a good idea to include sfproj's SDK in Microsoft/MSBuildSdks repo or in a separate directory under https://github.com/Microsoft/service-fabric/tree/15b6be4/src?

[jeffkl]

I would keep your SDK in your own repo since you own and maintain it. Be sure to keep your SDK package as small as possible. Your build logic with tasks and a DLL should still be a NuGet package and your SDK can be a small Sdk.props and Sdk.targets that has a <PackageReference />.

MSBuild will not fully evaluate a project until the SDKs are resolved. If your SDK package is large, project load times will be bad and VS could hang. Packages are cached but the resolver still has to query the NuGet API which queries the disk. NuGet package references are restored more asynchronously so they can be much bigger.

[bklooste]

Still an issue

[pdylanross]

Jumping in on the pile here to say that this would improve our workflow a ton. Adding dotnet cli templates would also be hugely beneficial.

[aL3891]

Any word on this one? would love to see it as well. We've extended the sf packaging with nuget packages and now we have to manually edit the sfproj files to include the targets. having the new project system eliminate that step

[shacal]

Kick - make it happen ! 🥇

[esbenbach]

Get going already :(

[chuanboz]

It's 2019 now, any new update for this or plan to support this?

[chuanboz]

Or, even this is not officially supported, has someone found ways to make sfproj to support package reference at a minimal? I am asking because then I could leverage default package props and targets from NuGet packages

[BigMorty]

Mike here from the VS team, I am the PM for the Service Fabric & Service Fabric Mesh tools in Visual Studio. We will be investigating this request soon, with the hope of supporting the new SDK-based project format for our .sfproj in the future.

[namvan]

It would be nice, BigMorty. We are in the middle of migrating all our ~300 projects to nuget package reference and it proves to be very good and clean. Then here comes this one with service fabric projects stuck in package.config. It is a bit disappointed to find out.

[aL3891]

That's great news @BigMorty, we've got some custom build targets for sf projects and the nuget integration in the new project system makes that so much easier

[chuanboz]

same as @aL3891 , we also have custom build targets to extend the sfproj to generate a deployable package to handle runtime certificate and other environment specific settings, if would be benificial if the new sfproj improvement could also clear document the extensions point in the built-in sfproj targets, to allow customize the ApplicationManifest.xml and ServiceManifest.xml generation.

[BigMorty]

Thanks @aL3891 and @chuanboz for the thumbs up on this investigation. @chuanboz - ironically, we are also working on documenting the project properties available to developers to customize Service Fabric projects. We will share those here and/or in the docs.

[aL3891]

Feel free tag me in PRs @BigMorty if you'd like some feedback or other assistance :)

[BigMorty]

Thanks Allan!

[Onaiplee]

Really need this feature!

[BigMorty]

Sorry to say but we are currently blocked from supporting SDK-style sfproj by the following issues: https://github.com/dotnet/project-system/issues/2491 https://github.com/Microsoft/msbuild/issues/4025

[wesleytsai]

Also looking for this

[amis92]

How is https://github.com/Microsoft/msbuild/issues/4025 blocking? 'Tis just a performance issue and not a very big one, considering that there is only one sfproj in solution (in most cases I've seen at least).

[abatishchev]

Any update on this, please? Is work in progress? Is anything blocking by now?

[BigMorty]

The two issues that are blocking this (dotnet/project-system#2491 and microsoft/msbuild#4025) have still not been resolved. My understanding is 4025 is blocking us not only because of a performance issue but it also has led to hanging Visual Studio.

[aL3891]

But then how could the mesh project files use the new sdk style?

[ghost]

Speaking as another user of Service Fabric, as a stopgap you might want to try using <RestoreProjectStyle>PackageReference</RestoreProjectStyle> with the existing sfproj format. We've been using that effectively in our repo with Microsoft.VisualStudio.Azure.Fabric.MSBuild/1.6.7.

E.g.: (Updated Jan 14)

    <!-- MyApp.sfproj -->
    <Project>
      <PropertyGroup>
        <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
        <!-- Suppress Microsoft.Common.props from importing project extension props, as we're already importing them here. -->
        <ImportProjectExtensionProps>false</ImportProjectExtensionProps>
      </PropertyGroup>
      <Import Project="$(MSBuildProjectDirectory)\obj\*.g.props" />
      <Import Project="$(PkgMicrosoft_VisualStudio_Azure_Fabric_MSBuild)\build\Microsoft.VisualStudio.Azure.Fabric.Application.props" />
      ...
      <ItemGroup>
        <PackageReference Include="Microsoft.VisualStudio.Azure.Fabric.MSBuild" Version="[1.6.7]" GeneratePathProperty="true" />
      </ItemGroup>
      <Import Project="$(PkgMicrosoft_VisualStudio_Azure_Fabric_MSBuild)\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets" />
    </Project>

This seems to work fine in VS 2017, but I've had problems loading such projects under VS 2019 -- just speculating, but maybe a regression in the sfproj plugin to VS? I just get an error "The operation failed as details for project ExampleApp could not be loaded". But it works fine in VS 2017, and works fine in command line builds and ADO YAML build pipelines.

We use this with dotnetsdk 3.1.405.