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.

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 Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.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:\Users\Admin\.nuget\packages\microsoft.servicefabric.services\2.1.150\lib\net45\Microsoft.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:

<RuntimeIdentifiers>win7-x64</RuntimeIdentifiers>

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

<RuntimeIdentifier>win7-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:\AcmeAuctions\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.0\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets(248,5): warning MSB3026: Could not copy "C:\AcmeAuctions\src\Acme.Service.Auction\bin\x64\Debug\net46\win7-x64\Acme.Service.Auction.runtimeconfig.json" to "C:\AcmeAuctions\pkg\Debug\Acme.Service.AuctionPkg\Code". Beginning retry 1 in 1000ms. Could not find a part of the path 'C:\AcmeAuctions\pkg\Debug\Acme.Service.AuctionPkg\Code'.

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:

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.