esbenbach
commented
2 years ago @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
RustyDes
aschan
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 buildoutside 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 buildin 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:
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 watchand 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:
dotnet buildcall).Service Fabric Runtime Version: 8.*+
Environment: Would enable development on all of them
Assignees: /cc @microsoft/service-fabric-triage @sukanyamsft