.Net Framework Class Library dll always changes when updating Service Fabric services

Question

I have a stateless .Net Core services running in Service Fabric. In my services, I reference a class library that targets .Net Framework 4.7.1. I deploy the application via VSTS and one of the build steps updates the app version for services with changes. https://learn.microsoft.com/en-us/vsts/build-release/tasks/utility/service-fabric-versioning

Everything works fine except that changes are always detected for the class library's dll-file. Even though I haven't changed anything in the code library! This causes the build step to bump the version of every single service. Not just services that actually has updates.

The logs looks like bellow. 'MyClassLibrary.dll' is a .Net Framework Class Library that I haven't touched the code in.

2018-03-12T11:39:51.1989307Z     Searching service 'MyServicePkg' for 
changes...
2018-03-12T11:39:51.2247570Z         Searching package 'Code' for changes...
2018-03-12T11:39:51.9878149Z             The file 'MyClassLibrary.dll' has 
changed.
2018-03-12T11:39:54.3850926Z           Updated package 'MyServicePkg\Code' 
from version '1.0.0' to '1.0.1'.

I'm aware that the check for changes in the code package is binary comparison. So the binary obviously change when the project is compiled. However, I don't know why. I also have code libraries that targets .Net Standard 2.0 and they don't cause this issue as changes are only detected when I actually have touched the code.

I'm also aware that it is possible to manually omit files that shouldn't update from the application package https://stackoverflow.com/a/34886586 However, that is not an option since the deployment chain is automated.

So I have the following questions:

1. What causes the binary for a .Net Framework class library to change?
2. In what way does it differ from a .Net Standard class library?
3. How do I work around it so my services only updates when I make real changes? Port from .Net Framework to .Net Standard?

Some insight in the matter is greatly appreciated.

Adamok

It is updating the projects because the libraries has been reBuild, probably because it identified a change on it, maybe in a timestamp, dependecy or something. Are you using Hosted build or OnPrem? On hosted, you don't keep the history to track the changes, so every build would create a new package. – Leishmaniasis

Answer 1

By default, the compiler will create different outputs even if you made no changes. Use the deterministic compiler flag to ensure builds with the same inputs produce the same outputs.

So, you need to specify /p:Deterministic=true argument in MSBuild Arguments.

The simple way is using Azure Service Fabric Application build template: Create a new build definition > Select Azure Service Fabric Application template, then you will find, there is /p:Deterministic=true /p:PathMap=$(Agent.BuildDirectory)=C:\ in MSBuild Arguments of Visual Studio Build task.

Peskoff

I'm already using the Azure Service Fabric Application template so the Deterministic flag was already set when building the sln-file. However, it was not set in the next step when building the Service Fabric application's sfproj-file. Setting the flag there solved the issue./t:Package /p:PackageLocation=$(build.artifactstagingdirectory)\applicationpackage /p:Deterministic=true – Adamok