Home » Advertising » Upgrade Your .NET Core Service Fabric Microservices From VS 2015 to VS 2017

Upgrade Your .NET Core Service Fabric Microservices From VS 2015 to VS 2017

Service Fabric projects have evolved at what feels like a break-neck pace, along with the .NET Core platform and tooling, and with the recent release of Visual Studio 2017, no doubt you are considering the productivity merits of upgrading (container support). For Service Fabric projects designed in Visual Studio 2015 and using the .Net Core .xproj/project.json structures now deprecated in Visual Studio 2017, the automatic upgrade process may result in only partial conversion success.

In this article, we’ll take a look at the issues encountered while upgrading a .NET Core Service Fabric solution containing 77 .xproj/project.json projects to Visual Studio 2017.

From .Net Core Visual Studio 2015 .xproj/project.json to Visual Studio 2017 .csproj

To begin, let’s take a look at a simplified example of a stateful .NET Core microservice defined with the following project.json (VS 2015) structure:

{
  "title": "Acme.Service.Auction",
  "description": "Acme.Service.Auction",
  "version": "1.0.0-*",

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true,
    "compile": {
      "exclude": [
        "PackageRoot"
      ]
    }
  },

  "dependencies": {
    "Microsoft.ServiceFabric": "5.1.150",
    "Microsoft.ServiceFabric.Services": "2.1.150",
    "EnterpriseLibrary.SemanticLogging": "2.0.1406.1"
  },

  "frameworks": {
    "net46": {}
  },

  "runtimes": {
    "win7-x64": {}
  }

}

Once the automatic Visual Studio 2017 conversion completes, you’ll end up with a .csproj file similar to what I’ve got below:

Project Sdk="Microsoft.NET.Sdk"

  PropertyGroup
    DescriptionAcme.Service.Auction/Description
    AssemblyTitleAcme.Service.Auction/AssemblyTitle
    TargetFrameworknet46/TargetFramework
    PreserveCompilationContexttrue/PreserveCompilationContext
    AssemblyNameAcme.Service.Auction/AssemblyName
    OutputTypeExe/OutputType
    PackageIdAcme.Service.Auction/PackageId
    RuntimeIdentifierswin7-x64/RuntimeIdentifiers
    GenerateAssemblyTitleAttributefalse/GenerateAssemblyTitleAttribute
    GenerateAssemblyDescriptionAttributefalse/GenerateAssemblyDescriptionAttribute
    GenerateAssemblyConfigurationAttributefalse/GenerateAssemblyConfigurationAttribute
    GenerateAssemblyCompanyAttributefalse/GenerateAssemblyCompanyAttribute
    GenerateAssemblyProductAttributefalse/GenerateAssemblyProductAttribute
    GenerateAssemblyCopyrightAttributefalse/GenerateAssemblyCopyrightAttribute
    GenerateAssemblyVersionAttributefalse/GenerateAssemblyVersionAttribute
    GenerateAssemblyFileVersionAttributefalse/GenerateAssemblyFileVersionAttribute
    IsServiceFabricServiceProjectTrue/IsServiceFabricServiceProject
  /PropertyGroup

  ItemGroup
    Compile Remove="PackageRoot***" /
  /ItemGroup

  ItemGroup
    PackageReference Include="Microsoft.ServiceFabric" Version="5.1.150" /
    PackageReference Include="Microsoft.ServiceFabric.Services" Version="2.1.150" /
    PackageReference Include="EnterpriseLibrary.SemanticLogging" Version="2.0.1406.1" /
  /ItemGroup

  ItemGroup Condition=" '$(TargetFramework)' == 'net46' "
    Reference Include="System" /
    Reference Include="Microsoft.CSharp" /
  /ItemGroup

/Project

Processor Architecture Mismatch Warnings

If you compile the above project, in the build output window you may notice processor architecture mismatch warnings, for example:

C:Microsoft Visual Studio2017EnterpriseMSBuild15.0BinMicrosoft.Common.CurrentVersion.targets(1964,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built “MSIL” and the processor architecture of the reference “C:UsersAdmin.nugetpackagesmicrosoft.servicefabric.services2.1.150libnet45Microsoft.ServiceFabric.Services.dll”, “AMD64”. 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.

To fix these and similar processor architecture mismatch warnings, replace:

RuntimeIdentifierswin7-x64/RuntimeIdentifiers

With this (there is no ‘s’ on the end):

RuntimeIdentifierwin7-x64/RuntimeIdentifier

Packaging and Publishing… Not so Fast!

So the converted microservice now compiles without any warnings, what’s all the fuss about? Well, if you now attempt to package and publish this microservice to Service Fabric, it fails with a message similar to what I’ve listed below:

C:AcmeAuctionspackagesMicrosoft.VisualStudio.Azure.Fabric.MSBuild.1.6.0buildMicrosoft.VisualStudio.Azure.Fabric.Application.targets(248,5): warning MSB3026: Could not copy “C:AcmeAuctionssrcAcme.Service.Auctionbinx64Debugnet46win7-x64Acme.Service.Auction.runtimeconfig.json” to “C:AcmeAuctionspkgDebugAcme.Service.AuctionPkgCode”. Beginning retry 1 in 1000ms. Could not find a part of the path ‘C:AcmeAuctionspkgDebugAcme.Service.AuctionPkgCode’.

Cross checking various existing GitHub and StackOverflow issues, the current Service Fabric SDK for VS 2017 and MSBuild tooling appear to not support .NET Core projects for Actor, Stateful, and Stateless services defined with Microsoft.NET.Sdk. To clarify, the tooling supports Stateful and Stateless ASP.NET Core service projects only, however, I prefer all projects to be in .NET Core, not just my ASP.NET microservices. Hence I replace this:

Project Sdk="Microsoft.NET.Sdk"

With the code below (as I expect the above scenario to be resolved in the near future with an SDK and tooling update, I’ve simply switched to a supported Service Fabric and VS 2017 template scenario which is to define all microservice .csproj files using Microsoft.NET.Sdk.Web):

Project Sdk="Microsoft.NET.Sdk.Web"

With this simple change, your Service Fabric microservices will support .NET Core Actor, Stateful and Stateless VS 2017 projects, and will package and publish normally. Note that in Visual Studio 2017 the project icon will change to a web project, and you may optionally want to git ignore and exclude launchSettings.json files. Given the non-intrusive workaround, however, I believe it’s well worth it. To remove the launchSettings.json file from your project, modify the ItemGroup to the following:

ItemGroup
  Compile Remove="PackageRoot***" /
  Content Remove="PropertieslaunchSettings.json" /
/ItemGroup

Summary

We’ve looked at some simple changes you can make to your converted and upgraded Service Fabric project files. The changes allow you to write your Actor, Stateful, and Stateless services in .NET Core while taking advantage of the great new productivity gains (Azure integration, Docker support, etc.) offered by Visual Studio 2017 and Service Fabric!

In our next article, we’ll continue the upgrade journey by walking through a few DevOps limitations encountered while reconfiguring a Service Fabric Visual Studio Team Services CI/CD pipeline.

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*

cover letter