Copying DotNet Core Application to image store in Service Fabric is taking a long time

2
votes

My service fabric app (all .net core 2.1 applications) is made up of 14 services. After the package process in my VSTS build I notice that each service is about 100mb each giving 1.4GB (ish) for the total.

The consequence of this is that when copying the package files around, it is taking a long time! About 10 minutes for the "Copying application to image store..." release phase.

Looking at the package it seems to include the .net core 2.1 framework assemblies, and I guess that is why each service package is so large.

Is it strictly necessary that the package process includes the .net core 2.1 framework components? Is there a way to package it without the .net core framework, and if I do is there a way to install the .net framework on all the VMs of the service fabric cluster, and keep that framework up to date?

2
.net-coreazure-service-fabricazure-pipelines-release-pipeline

2 Answers

2
votes

See this repo for how to skip including the runtime as part of the package. We use a very a similar method for our application consisting of 32 .Net Core 2.0 services which decreased our package size from ~2.5 GB to ~600MB.

This however means that we need to install the runtimes (.Net Core and ASP.Net Core) manually on each of the SF nodes. If somebody know how to automate that part, I'm also very interested in this.

2
votes

We have a similar situation where deploying the Service Fabric application with many microservices times out when trying to upload the package to the image store.

For .net core 2.2 you can deploy framework dependent executable (FDE) which strips the .net runtime from your output folder. It behaves exactly how .net full framework executable would have been working. TL;DR; do the following:

  • Add <SelfContained>True</SelfContained> in csproj (or if you publish by dotnet publish use the --self-contained false flag

Additional optimization is to make use of target manifest file for dependencies. Read more about it the runtime package store docs.
This can be used to remove SwashBuckle (10 MB) dependency from your services and just deploy it on the target environment.

For Service Fabric Actor projects, as @morten-fischer-madsen suggested in one of the comments above, you need to:

  • Set <UpdateServiceFabricManifestEnabled>False</UpdateServiceFabricManifestEnabled> in your csproj or remove it, otherwise the build will fail due to Microsoft.ServiceFabric.Actors nuget e.g.
The command "dotnet "obj\\FabActUtilTemp\FabActUtil.dll" /spp:"PackageRoot" /t:manifest /sp:"Actor1" /in:"bin\Debug\netcoreapp2.2\win7-x64\\Actor1.dll" /arp:"C:\Users\%username%\source\repos\Application1\Actor1\bin\Debug\netcoreapp2.2\win7-x64\\" " exited with code -2147450745.
Actor1
C:\Users\%username%\.nuget\packages\microsoft.servicefabric.actors\3.3.654\build\netcoreapp2.0\Microsoft.ServiceFabric.Actors.targets
22

I've opened a bug for this here