Release of SDK 2.7.198 and Runtime 5.7.198 for Windows


Service Fabric version 5.7 of the runtime and 2.7 of the SDK is now available, packed with new features, improvements, and bug fixes for containers, SDK, Reverse Proxy, and the core system itself.

Some highlights of this release:

Run Reliable Services and Reliable Actors in Windows Containers (Preview)

Reliable Services and Reliable Actors can now be packaged and run in Windows containers. This feature is currently **in preview**, with Visual Studio integration planned for an upcoming release.

Assign unique IP addresses to services and containers with open networking mode

In addition to the default “nat” networking mode, Service Fabric now supports “open” networking mode. This mode allows each Service Fabric service - whether it's in a container or not - to get a dynamically assigned IP. Thus, with this feature, you can have multiple services listening on the same port.

ASP.NET Core 2.0 support

The Microsoft.ServiceFabric.AspNetCore.* NuGet packages now support ASP.NET Core 2.0.
Note that only stable builds of ASP.NET Core 2.0 packages are supported; pre-release/preview builds (for example, v2.0.0-preview2-final) of ASP.NET Core 2.0 are not guaranteed to work properly. A final stable build of ASP.NET Core 2.0 packages should be available on NuGet soon.
Also note that the ASP.NET Core WebListener package has been renamed to HttpSys in ASP.NET Core 2.0. Support in Service Fabric for the new HttpSys package is not available yet in this release, but is coming soon. See the full release notes for more details on this.

A consistent cluster configuration between your local development cluster, standalone clusters, and Azure clusters

The cluster configuration for a local development cluster now uses the same clustersettings.json format that a standalone cluster uses, instead of the older ClusterManifest.xml format. This is also more closely aligned with Resource Manager templates for Azure clusters, which has similar settings to clustersettings.json. This will make it much easier to configure a local development cluster to resemble a production cluster, because the configuration format is identical for standalone clusters and more similar to Azure clusters.

Ability to send urgent health reports to the cluster immediately

You can now send urgent health reports to the cluster immediately without waiting for the usual batch send interval. This is very useful in situations where a process crash is imminent, like during unhandled exceptions, where there isn't time to wait for the next batch send interval.

As always, be sure to read through the full release notes for a complete list of new features, improvements, and bug fixes.

See you at our upcoming Service Fabric Community Q&A on August 17th @ 10AM PST. Check back on this blog for more details.

Cheers,
The Service Fabric Team


Comments (37)

  1. George Gkionis says:

    I have created a custom FabricTransportServiceRemotingProviderAttribute for my project, and your latest updates have broken my code.
    More specifically, in my IServiceRemotingListener.CreateServiceRemotingListener implementation, when I try to return a new FabricTransportServiceRemotingListener instance by passing the service Context and a custom ServiceRemotingDispatcher, I get this:

    The error is: Method not found: ‘System.String System.Fabric.ServiceContext.get_ListenAddress()’.
    at Microsoft.ServiceFabric.Services.Remoting.FabricTransport.Runtime.FabricTransportServiceRemotingListener..ctor(ServiceContext serviceContext, IServiceRemotingMessageHandler messageHandler, FabricTransportRemotingListenerSettings listenerSettings)

    Please inform me as soon as possible about what I can do to rectify the problem.

    1. Hi George – please open an issue here: https://github.com/Azure/service-fabric-issues/issues – I’ve informed the engineers and they will look for your issue and respond. Thanks.

      1. Please make sure that the NuGet packages you are using is same or older version than the runtime. E.g. NuGet packages version 5.7 are not supported on clusters running 5.6 or older.

        1. George Gkionis says:

          I’ve managed to download the latest SF SDK (5.7.x), and the behavior returned to normal.

  2. Tomasz Sobkowiak says:

    Exactly the same problem here as George Gkionis mentioned – were there any changes to that?

    1. George Gkionis says:

      Download and install the latest SF SDK (5.7.x).

  3. All links inside DOC file are ending up in HTTP 404 (for example link below in document supposed to tell about new networking mode)
    https://docs.microsoft.com/azure/service-fabric/service-fabric-networking-modes which ends up in HTTP 404

    1. The docs are pending publishing and will be available soon.

  4. Hans Ravnaas says:

    The link for “Service Fabric networking modes” in the release notes seems to be incorrect. Returns a 404.

    1. Please see my comment above – The docs are pending publishing and will be available soon.

  5. Vijay says:

    Thanks Service Fabric team for completely breaking all my service fabric applications with the nuget updates in this release. I have reverted the whole thing.

    1. What specifically broke? Did you update both the cluster and NuGets? New NuGets will not work with older runtime.

      1. Vijay says:

        After spending a bit more time – it got fixed after I deployed compiling in x64 mode. Previously would work even if the solution was set to AnyCPU. But, this is hit or go. I guess x64 works reliably all the time.

        My workers were erroring out for no apparent reason. Some strange, meaningless error indicating service could not start. Also, when I deployed multiple times in this state, once it failed because it could not read the configuration defined in the application parameters xml file.

        1. Thanks for reporting back Vijay, glad you got it working.

  6. Juho Hanhimäki says:

    Updated to the newest VS 2017 SDK but the tools version didn’t update. Will tools be updated separately as VS extension or is there something I am missing?

    1. Nick Randell says:

      I’m seeing errors such as “Unable to find version 1.6.1 of package ‘Microsoft.VisualStudio.Azure.Fabric.MSBuild'”
      nuget only has version 1.6.0

      1. There you go, that was a miss – sorry for the inconvenience.

        FYI the NuGet packages are also distributed with the SDK and tooling.
        SDK: C:\Program Files\Microsoft SDKs\Service Fabric\packages
        Tooling: C:\Program Files (x86)\[VS Version]\Common7\IDE\Extensions\Microsoft\Service Fabric Tools

    2. Visual Studio 2017 Update 3 (15.3) has the tooling version 1.7. For Visual Studio 2015, the updated tooling is available via Web Platform Installer. The 1.6 version of the tooling will still work with the updated SDK.

      1. Juho Hanhimäki says:

        That explains. I am still on 2017 15.2. Would be nice if stuff like this was documented.

  7. iamms says:

    Hi. I have problem with reverse proxy. When i try to browse reverse proxy url (localhost:19081/myapp/myservice) after 60 seconds i get 504 gateway timeout. I tried increase timeout value with Timeout= in url but i get timeout after specified time. I can browse local service url (localhost:808x) and it works. I have cluster with two VMs running Windows server 2016, CodeVersion: 5.7.198.9494, i used this template https://github.com/Azure-Samples/service-fabric-dotnet-standalone-cluster-configuration/blob/master/Samples/ClusterConfig.Windows.MultiMachine.json.

    1. iamms says:

      pls help

      1. Hi Iamms – I would recommend posting your question on Stackoverflow as more people watches questions like these there. Take a look here for troubleshooting 504 errors: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverse-proxy-diagnostics#troubleshoot-using-diagnostics-logs. Now if you do not see this payload, it means that you are not reaching the reverseproxy endpoint in the first place.

  8. Colin Murphy says:

    Applying this update from a 2.6 local cluster has resulted in more of a complicated process of attempting to uninstall and reinstall, with it currently failing to install or configure a runtime.

    Is there a way of completely removing the cluster and runtime from a local workstation, to reinstall and resolve current issues?

    1. Add/ Remove programs has the SDK and runtime MSI packages, you should be bale to uninstall there. If any left overs – deleve the SfDevCluster folder (But it should be empty). If you still face issues, please raise an issue here to engage with our engineers: https://github.com/Azure/service-fabric-issues/

  9. HI team, I have updated my Visual studio 2017 to the latest update (15.3.2) and have upgraded the service fabric and SDK to the latest *.*.198. I have upgraded the Nuget packages to version 5.3.311. When I upgraded it to the latest version available (5.7.198 and 2.7.198 the Remoting namespace is not supported anymore. With the version 5.3.311 and After the update none of the WebApis in my service fabric cluster seem to be working. The errors I get are as below :-
    Partitions
    Error
    Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.
    Partition
    Error
    Unhealthy partition: PartitionId=’e3e2ff39-f25c-4190-8a5f-0818ca8570cf’, AggregatedHealthState=’Error’.
    Event
    Error
    Error event: SourceId=’System.FM’, Property=’State’.
    Partition is below target replica or instance count.
    fabric:/ServiceFabricApplication.ServiceBus.Core/WebApiSignalR 1 1 e3e2ff39-f25c-4190-8a5f-0818ca8570cf
    (Showing 0 out of 0 replicas. Total available replicas: 0.)

    I have tried resetting the cluster, repairing Visual Studio and uninstalling and resinstalling everything many many times but nothing works! Please help!

    1. Hi Fatima, From 5.3 to 5.7 there has been some breaking changes along the way. You need to work through these to get you service up and running again. Best advise is to read through the individual release notes for 5.4 -> 5.7 to understand the changes along the way.
      Stepping through the code in Visual Studio should help you with more meaningful exceptions. The error message you are seeing indicates that the services are not running.

  10. Sandro Pedrocchi says:

    According to the documentation (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-securing-containers) it is necessary to set the hostname attribute in order to use gMSA. There is just one problem. The attribute is not declared in the xsd and the validation fails.

  11. Bruce says:

    Hi. Not sure if here is the best place to post this. I have updated VS2017 to 15.3 and installed latest .NET Core 2.0 and Service Fabric SDK and Runtime. When starting a new Service Fabric project, I select ASP.NET MVC .NET Core 2.0 as my service in the wizard. Without touching a line of code I get the following warning:

    Warning MSB3270 There was a mismatch between the processor architecture of the project being built “AMD64” and the processor architecture of the reference “C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.visualstudio.web.codegeneration.design\2.0.0\lib\net461\dotnet-aspnet-codegenerator-design.exe”, “x86”. This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. Web1 C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets

    As it is a warning I tried to deploy to my local cluster but deployment failed because of the above warning.

    Am I missing something? I can’t seem to find a solution to this problem.

    1. SHerrman says:

      Same problem here.
      BadImageFormatException thrown on call to “dotnet-aspnet-codegenerator-design”, caused by services.addMvc().
      Removing the “DotNetCliToolReference” from csproj-file does not make any difference.
      Creating a new SF project with asp.net core 2.0 does work!
      I spent hours comparing my upgraded project to the new project. I could not find anything causing this error.

      1. SHerrman says:

        I uninstalled the nuget package which was installed in the solution. Started working after that.

    2. Bruce says:

      I removed the Tooling references and got it working on my local cluster, it builds and deploys fine.

      But I still have problems when trying to build the project in VSTS. I get warnings such as:

      2017-08-25T04:03:14.4126956Z C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\amd64\Microsoft.Common.CurrentVersion.targets(1964,5): warning MSB3243: No way to resolve conflict between “System.AppContext, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” and “System.AppContext, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”. Choosing “System.AppContext, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” arbitrarily. [C:\XXXXXX\XXXXX\19\s\WebFront\WebFront.csproj]

      2017-08-25T04:03:14.4283212Z Consider app.config remapping of assembly “System.AppContext, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” from Version “4.0.0.0” [C:\Windows\ServiceProfiles\NetworkService\.nuget\packages\system.appcontext\4.3.0\ref\net46\System.AppContext.dll] to Version “4.1.2.0” [C:\Windows\ServiceProfiles\NetworkService\.nuget\packages\netstandard.library.netframework\2.0.0-preview2-25405-01\build\net461\\ref\System.AppContext.dll] to solve conflict and get rid of warning.

      I tried remapping using the app.config file but still did not working tell me: ” The explicit binding redirect on “System.AppContext, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” conflicts with an autogenerated binding redirect. Consider removing it from the application configuration file or disabling autogenerated binding redirects.”

      When I do remove Auto Generated binding as suggested I get a heap more of conflicts between versions.

  12. FC says:

    I updated the SDK and the Runtime, deployed into the cluster and the performance is degraded to less than half. compared to before with the same code, no changes.
    I need 3 times the same azure instances to hold the same exact traffic than before. I tried a new project with new cluster, same thing.
    Reinstalled the old runtime, all is fast again.
    My cluster contains a single API using TPL library calling external services.
    I love SF but too many headaches.

    1. Pleas open a support ticket in the Azure Portal to diagnose this. Thanks.

  13. Alex says:

    Guys, where is a link to a cab file for graceful upgrade?

  14. Zir01 says:

    Hi, can somebody please help me with this problem? I have successfully upgraded an existing SF project which includes a ASP.NET Core Website to Core 2.0.0, I can deploy directly from my local VS2017 to any cluster and the ASP.NET Core Website works fine. But if I try to build/deploy from VSTS using build and release definition the site returns weird TagHelper errors. For more details, I have started a stackoverflow post here: https://stackoverflow.com/questions/46313922/asp-net-core-2-0-taghelper-errors-after-upgrade

Skip to main content