service-fabric-aspnetcore | repo contains ASP.NET Core integration | Microservice library

 by   microsoft C# Version: Current License: Non-SPDX

kandi X-RAY | service-fabric-aspnetcore Summary

kandi X-RAY | service-fabric-aspnetcore Summary

service-fabric-aspnetcore is a C# library typically used in Architecture, Microservice, Docker applications. service-fabric-aspnetcore has no bugs, it has no vulnerabilities and it has low support. However service-fabric-aspnetcore has a Non-SPDX License. You can download it from GitHub.

This repo contains ASP.NET Core integration for Service Fabric Reliable Services.

            kandi-support Support

              service-fabric-aspnetcore has a low active ecosystem.
              It has 146 star(s) with 45 fork(s). There are 78 watchers for this library.
              It had no major release in the last 6 months.
              There are 6 open issues and 52 have been closed. On average issues are closed in 46 days. There are no pull requests.
              It has a neutral sentiment in the developer community.
              The latest version of service-fabric-aspnetcore is current.

            kandi-Quality Quality

              service-fabric-aspnetcore has 0 bugs and 0 code smells.

            kandi-Security Security

              service-fabric-aspnetcore has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.
              service-fabric-aspnetcore code analysis shows 0 unresolved vulnerabilities.
              There are 0 security hotspots that need review.

            kandi-License License

              service-fabric-aspnetcore has a Non-SPDX License.
              Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

            kandi-Reuse Reuse

              service-fabric-aspnetcore releases are not available. You will need to build from source code and install.
              Installation instructions are available. Examples and code snippets are not available.

            Top functions reviewed by kandi - BETA

            kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
            Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of service-fabric-aspnetcore
            Get all kandi verified functions for this library.

            service-fabric-aspnetcore Key Features

            No Key Features are available at this moment for service-fabric-aspnetcore.

            service-fabric-aspnetcore Examples and Code Snippets

            No Code Snippets are available at this moment for service-fabric-aspnetcore.

            Community Discussions


            "PDB format is not supported" with .NET portable debugging information
            Asked 2019-Mar-11 at 18:37

            The last couple of days I've been hunting down a problem - with the conclusion:

            My Visual Studio 2017 debugger can't work with PDBs in "portable" format in .NET Framework projects.

            With portable format I mean going to a project's settings, then to Build -> Advanced and then selecting portable under Debugging information.

            When I start debugging a .NET Framework project built like this, breakpoints don't get hit.

            When I pause the debugger and look for the reason why it didn't load the symbols, it says (under Symbol load information):

            PDB format is not supported

            I can reproduce this with any .NET Framework project. The target framework doesn't seem to matter. I tried .NET 4.5.2 and 4.6.2.

            It works fine, though, for .NET Core projects.

            Now, the strange thing is that the exact same project works fine on another computer.

            So, it seems that my computer is missing something or has something misconfigured. But my Google search didn't turn up anything. Any ideas how to fix this problem?



            Answered 2019-Mar-11 at 18:37

            You are probably using the wrong debugging engine.

            Navigate: Tools > Options > Debugging > General

            Ensure that the "Use Managed Compatibility Mode" is not ticked.



            Servce Fabric Reverse Proxy Integration in ASP.NET Core 404 Response
            Asked 2018-Jul-21 at 19:51

            I'm working on an implementation of ICommunicationClient and accompanying stuff for HTTP protocol communication which should be compatible with SF reverse proxy. The most subtle part for me is retry policy. According to Azure docs for 404 errors reverse proxy relies on X-Service-Fabric header to be returned from web service when deciding if it should retry.

            ASP.NET Core provides middleware for integration with a reverse proxy which adds X-Service-Fabric header to every 404 response.

            Assume we have the scenario when ServicePartitionClient cached the endpoint for a stateless service listening on port 3001. At some point, this service may be moved to another node. On the first node, the Service Fabric runtime allocates a different service with its own endpoints but using the same middleware and listening on the same 3001 port.

            When a client tries to call the original service at its old (cached) address it will receive 404 response containing the X-Service-Fabric header. According to reverse proxy policies it shouldn't retry, but for me, it seems like the client will stay connected to the wrong service forever and won't attempt to re-resolve the endpoint.

            I can't find any information about this case in the documentation, did I miss something here? Is it safe to rely on this standard middleware and don't do retry attempts on 404 errors with X-Service-Fabric: ResourceNotFound header?



            Answered 2018-Feb-28 at 22:11

            In your given scenario, when your Client encounters a 404, the X-Service-Fabric:ResourceNotFound header isn't the only attribute your code could examine when deciding whether or not to retry some operation.

            To simplistically address your concern that your client won't be able to tell the difference between a "friendly" node and a "newly arrived" node, and since you're already working with http headers, you could add a custom HTTP header to outgoing responses to identify that a request comes from your application. When the client receives a 404, you can simply check for the presence of your custom header to answer the question of whether or not it's a "legit" retry. Of course, adding a custom HTTP header just for the sake of this validation check may be more of a global solution to a local problem. Ed: goes without saying that this should not be used to make security decisions by the application

            A more elegant and complex means of accomplishing the same would be to deduce the same result using a different combination of HTTP headers and response attributes (e.g., see if some other headers are expected/unexpected), but this could also be a hyper-local solution to the problem.



            When should I use ServiceFabricIntegrationOptions.UseUniqueServiceUrl
            Asked 2017-Apr-30 at 03:10

            This seems to say that is is always necessary otherwise you may resolve an incorrect service -- as there is no guarantee that services won't move around etc...

            The default core service template uses UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)

            Is there a reason for this? When is it okay to not use the ServiceFabricIntegration middleware?

            E: I see these are actually a flags enum. So likely you should always use UseUniqueServiceUrl



            Answered 2017-Apr-30 at 03:10

            Respectfully, I don't think you have read the docs well enough. It is well explained here:

            Services that use a dynamically-assigned port should make use of this middleware.

            Services that use a fixed unique port do not have this problem in a cooperative environment. A fixed unique port is typically used for externally-facing services that need a well-known port for client applications to connect to. For example, most Internet-facing web applications will use port 80 or 443 for web browser connections. In this case, the unique identifier should not be enabled.

            So summarized: when using Kestrel or WebListener you can choose to use a dynamic port or a fixed port. See the sections Use WebListener/Kestrel with a static port and Use WebListener/Kestrel with a dynamic port in the mentioned link. When you opt to use a dynamic port use ServiceFabricIntegrationOptions.UseUniqueServiceUrl, otherwise use ServiceFabricIntegrationOptions.None as the parameter for the middleware.

            Now, as of the why you need this unique service url middleware in case of a dynamic port, there is a scenario that describes the possible problem:

            If services use dynamically-assigned application ports, a service replica may coincidentally use the same IP:port endpoint of another service that was previously on the same physical or virtual machine. This can cause a client to mistakely connect to the wrong service. This can happen if the following sequence of events occur:

            • Service A listens on over HTTP.
            • Client resolves Service A and gets address
            • Service A moves to a different node.
            • Service B is placed on and coincidentally uses the same port 30000.
            • Client attempts to connect to service A with cached address
            • Client is now successfully connected to service B not realizing it is connected to the wrong service.

            This can cause bugs at random times that can be difficult to diagnose


            Community Discussions, Code Snippets contain sources that include Stack Exchange Network


            No vulnerabilities reported

            Install service-fabric-aspnetcore

            To build everything and generate NuGet packages, run the build.ps1 script. NuGet packages will be dropped in a drop directory at the repo root. Each project can also be built individually directly through Visual Studio or by running the solution file through MSBuild. Binaries in the build are delay signed, these are fully signed in the official builds released by Microsoft. To use the binaries or to run unit tests from the build of this repository, strong name validation needs to be skipped for these assemblies. This can be done by running SkipStrongName.ps1 script available in the root of the repository. For branches, please see Branching Information.


            Official releases from Microsoft of the NuGet packages in this repo are released directly to NuGet and Web Platform Installer. Get the latest official release here. Only officially released NuGet packages from Microsoft are supported for use in production. If you have a feature or bug fix that you would like to use in your application, please issue a pull request so we can get it into an official release.
            Find more information at:

            Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items

            Find more libraries
          • HTTPS


          • CLI

            gh repo clone microsoft/service-fabric-aspnetcore

          • sshUrl


          • Stay Updated

            Subscribe to our newsletter for trending solutions and developer bootcamps

            Agree to Sign up and Terms & Conditions

            Share this Page

            share link