[Feature]: Switch to a dotnet build in order to facilitate non-VS development

[WhitWaldo]

Is your feature request related to a problem? Please describe your workload details. The vast majority of my development time these days isn't spent authoring SF projects per-se, but rather the content and functionality running atop them, e.g. Blazor-based websites. For large enough projects like mine, I just don't find the Visual Studio support for Blazor to be all that stable (styling issues, code showing as invalid until an IDE restart, bad Intellisense, etc.) so over the last week, I started developing with JetBrains' Rider IDE instead (and have been vastly more productive).

There are two four year-old tickets in JetBrains' issue tracker asking for it to support Azure Service Fabric development and it's received a couple hundred upvotes since then (including mine) and a creative (hacky) user workaround. But it occurs to me that the JetBrains team may simply have looked at the closed support for .sfproj files, the inability to just kick off a dotnet build outside Visual Studio and thus put this on the backburner, so I'd like to request support for just that.

Describe the solution you'd like If I were able to do a full SF build issuing little more than dotnet build in a CLI outside of Visual Studio, there'd be nothing stopping Rider from having full SF support on day one of the release as that's how it kicks off all its own .NET builds from what I can tell.

Importantly, enabling this support wouldn't just open development to Rider users, but also to the larger community using VS Code or any other IDE. This would in turn allow community development of new project templates outside of Visual Studio (and potentially showcasing of new features) in a way not currently possible today. Because the SF templating mechanism in Visual Studio isn't currently open source, I cannot submit or develop my own templates to:

• demonstrate new services using IHost
• reflect .NET 6 (and later) support
• ship whole example templates showcasing use of YARP/Traefik
• just build out my own templates to configure logging and DI consistently (instead of applying those changes myself every time I add another service to the solution)

What's more, you get the benefit of generally supporting .NET releases on day one like other Microsoft products as it's on the dotnet team to support the new .NET language features. Out of the box with no effort on your part, customers would get top-level statements, global usings and with the support for IHost, the ability to better accommodate the DI facilities embraced by the ASP.NET team all without necessitating new SF bits.

And when there's dotnet functionality that's not explicitly supported, you'd need only call it out ahead of time (e.g. Hot Reload using dotnet watch and why, but such callouts seem like they'd usually be few and far between.

Describe alternatives you've considered Exclusively staying with Visual Studio is increasingly out of the question. If I have to keep it around for template generation or producing new builds, I will, but it'd be great to expand the IDE horizons to more performant options.

Reading some of the comments on the above Rider comments, other developers are using a mix of IDEs, but that's clearly not ideal either.

Area/Component: Build tooling

Expected behavior I expect this would significantly improve the developer experience as:

• We'd go from only being able to work with VS to being able to use any generally other IDE
• Developers can use Windows, Mac or Linux to write SF projects
• Open the door to customer-contributed/maintained project templates in a way that's not feasible today with VS
• CI pipelines are simplified. Don't need the msbuild step anymore and can use the same build pipeline as every other modern .NET project (just a dotnet build call).
• New .NET language support handled by dotnet team, generally not needing SF-specific bits

Service Fabric Runtime Version: 8.*+

Environment: Would enable development on all of them

---

Assignees: /cc @microsoft/service-fabric-triage @sukanyamsft

[esbenbach]

@sukanyamsft you mentioned in the community call that you have: not heard an ask for it.

Which is really weird, because #1085 is not exactly new, and while it does not say "dotnet build" specifically, it ends up being sort of the same requirement and need.

Issues in general related to sfproj (which again are not directly dotnet build related but they sort of point to the same ancient/legacy issue with sfproj files): #907 #885 #826 (though its a restore thing it boils down to the same tooling/project issues) #191

In general looking at the issues list (searching for "sfproj") there SEEMS to be a lot of feedback around the public build/restore/template tooling.

[jahmai-ca]

I have a project that produces an sfpkg with the wrong assemblies in it, because it references a net6 project (which service fabric does support), but because the deployment project targets net472, it packages up the wrong assemblies. In this case it's System.Drawing.Common, where the reference service project packages the win runtime version of the dll, but the sfpkg contains the netstandard version, and fails at runtime.

I believe updating the the project format and allowing it to target netX TFM's would address these kinds of issues.

[esbenbach]

@sukanyamsft and @craftyhouse - any updates on this? Now with the advent of NuGet CPM, there is yet another thing I need to handle specifically for my *.sfproj in the CI/CD pipeline because I have to restore *.sfproj dependency (Fabric.MSBuild) using NuGet and it does not understand the upstream sources concept used by Azure DevOps Artifact Feeds.

I realize the issue is not directly due to sfproj files, but having them compatible with the new tooling (i.e. dotnet restore in this case) would probably have prevented the issue in the first place.

[jahmai-ca]

Any progress on this? Is Service Fabric and NETx support not a priority for MS?

[jahmai-ca]

One more yearning bump.

[RustyDes]

+1

[jahmai-ca]

Can we get some kind of response from MS on this? It's been a year...