Deployment for Service Fabric service version upgrade fails on VSTS Release

Question

Summary

The following error appears at log.

The content in ConfigPackage Name:Config and Version:1.0.0.20180315.2 in Service Manifest \'TwoServiceP         


        

Answer 1

The error you get as the error message suggest :

'The content in ConfigPackage Service Manifest 'PackageName' has changed, but the version number is the same.

That means: we found something different in this package that does not match the previous version, because you've said the version should be the same, they should match, so I don't know what to do and will let you fix that.

The message is not very suggestive, so at first glance you get lost.

I have answered the same questions here error-while-upgrading-azure-service-fabric-through-vsts-ci-cd, please check if the answer help you solve your problem.

I will explain a bit more:

Whenever you register an application, service fabric will compare the new version being registered with the versions currently in the server, if the same service version is already there, it will compare the packages, the config packages, the code package and so on, if any of them doesn't match it will fail the deployment.

Every small change on any of these, should trigger a version upgrade, for example, if you add or remove a config setting in the Setting.xml you have to upgrade the version of your config file and one in the service manifest.

Before:

app1 -------> 1.0.0
  service1 -> 1.0.0
    code ---> 1.0.0
    config -> 1.0.0

After

app1 -------> 1.0.1
  service1 -> 1.0.1
    code ---> 1.0.0
    config -> 1.0.1

For the code package the same happens, and if you upgrade the code and config at same time, you should only upgrade the service manifest only one version, like:

app1 -------> 1.0.1
  service1 -> 1.0.1
    code ---> 1.0.1
    config -> 1.0.1

The trickiest challenge here are the code changes, whenever a new build is triggered, the build will download the source and compile everything, you know what has changed based on commit changes, but for the build everything will generate an assembly, so it does not care if it changed or not, it will generate a new assembly, despite the code being the same from previous build the output binary on most of the times will be different.

Going through the Application Registration, if the version keep the same, these binaries should match the existing ones, what is not gonna happen. To solve this, the differential packaging join the party, I won't give too much details here because is out of scope for this answer, but you can get more information on these links:

Service Fabric Application with a diff package

StackOverflow Question: Differential Packaging