Create your first C# Service Fabric stateful Reliable Services application
Learn how to deploy your first Azure Service Fabric application for .NET on Windows in just a few minutes. When you're finished, you'll have a local cluster that's running with a Reliable Services application.
Before you get started, make sure that you've set up your development environment. This process includes installing the Service Fabric SDK and Visual Studio 2017 or 2015.
Create the application
Start Visual Studio as an administrator.
Create a project by selecting Ctrl+Shift+N.
In the New Project dialog box, select Cloud > Service Fabric Application.
Name the application MyApplication. Then select OK.
You can create any type of Service Fabric application from the next dialog box. For this quickstart, choose .Net Core 2.0 > Stateful Service.
Name the service MyStatefulService. Then select OK.
Visual Studio creates the application project and the stateful service project. Then it displays them in Solution Explorer.
The application project (MyApplication) does not have any code. Instead, it references a set of service projects. It also has three other types of content:
Profiles for deploying to different environments.
PowerShell scripts for deploying or upgrading your application.
Includes the ApplicationManifest.xml file under ApplicationPackageRoot, which describes your application's composition. Associated application parameter files are under ApplicationParameters, which can be used to specify environment-specific parameters. Visual Studio selects an application parameter file that's specified in the associated publish profile.
For an overview of the contents of the service project, see Getting started with Reliable Services.
Deploy and debug the application
Now that you have an application, run, deploy, and debug it by taking the following steps.
In Visual Studio, select F5 to deploy the application for debugging.
The first time you run and deploy the application locally, Visual Studio creates a local cluster for debugging. This might take some time. The cluster creation status is displayed in the Visual Studio output window.
When the cluster is ready, you get a notification from the local cluster system tray manager application that's included with the SDK.
After the application starts, Visual Studio automatically brings up the Diagnostics Event Viewer, where you can see trace output from your services.
Events should automatically start tracking in the Diagnostic Events Viewer. If you need to manually configure the Diagnostic Events Viewer, first open the
ServiceEventSource.csfile, which is located in the project MyStatefulService. Copy the value of the
EventSourceattribute at the top of the
ServiceEventSourceclass. In the following example, the event source is called
"MyCompany-MyApplication-MyStatefulService", which might be different in your situation.
Next, open the ETW Providers dialog box. Then select the gear icon that's located on the Diagnostics Events tab. Paste the name of the event source that you copied into the ETW Providers input box. Then select the Apply button. This automatically starts tracing events.
You should now see events appear in the Diagnostics Events window.
The stateful service template shows a counter value that's incrementing in the
RunAsyncmethod of MyStatefulService.cs.
Expand one of the events to see more details, including the node where the code is running. In this case, it is _Node_0, though it might differ on your machine.
The local cluster contains five nodes that are hosted on a single machine. In a production environment, each node is hosted on a distinct physical or virtual machine. To simulate the loss of a machine while you're exercising the Visual Studio debugger, take down one of the nodes on the local cluster.
In the Solution Explorer window, open MyStatefulService.cs.
RunAsyncmethod, and then set a breakpoint on the first line of the method.
Start the Service Fabric Explorer tool by right-clicking the Local Cluster Manager system tray application and then selecting Manage Local Cluster.
Service Fabric Explorer offers a visual representation of a cluster. It includes the set of applications that is deployed to it and the set of physical nodes that make it up.
In the left pane, expand Cluster > Nodes, and find the node where your code is running. Then, to simulate a machine restarting, select Actions > Deactivate (Restart).
Momentarily, you should see your breakpoint hit in Visual Studio as the computation you were doing on one node seamlessly fails over to another.
Next, return to the Diagnostic Events Viewer and observe the messages. The counter has continued incrementing, even though the events are actually coming from a different node.
Clean up the local cluster (optional)
Remember, this local cluster is real. Stopping the debugger removes your application instance and unregisters the application type. However, the cluster continues to run in the background. When you're ready to stop the local cluster, there are a couple options.
Keep application and trace data
Shut down the cluster by right-clicking the Local Cluster Manager system tray application and then selecting Stop Local Cluster.
Delete the cluster and all data
Remove the cluster by right-clicking the Local Cluster Manager system tray application. Then choose Remove Local Cluster.
If you choose this option, Visual Studio redeploys the cluster the next time you run the application. Choose this option if you don't intend to use the local cluster for a while or if you need to reclaim resources.
Read more about Reliable Services.