Open WhitWaldo opened 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):
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.
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.
@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.
Any progress on this? Is Service Fabric and NETx support not a priority for MS?
One more yearning bump.
+1
Can we get some kind of response from MS on this? It's been a year...
So it has been almost 2½ years since this was posted. Any updates?
Its not going to happen (at least not in the open). The SF teams is either being told to not do anything in public or being understaffed, the people who originally asked Whit to post his issue here are no longer with the SF team, and they have stopped communicating with the public entirely.
Unfortunately :(
SF Team, please please please prove me wrong on this.
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:
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:
dotnet build
call).Service Fabric Runtime Version: 8.*+
Environment: Would enable development on all of them
Assignees: /cc @microsoft/service-fabric-triage @sukanyamsft