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 'TwoServicePkg' has changed, but the version number is the same.

I changed only the code of one of the services, so I changed only one version of the code in the manifest.

In this case, there is no problem with the upgrade through Visual Studio.

However, upgrading via VSTS will cause the above error.

Details

I created VSTS CI/CD for Service Fabric as default. (Pipeline: VSTS Git Repo -> Build -> Release)

First 'Commit > Build > Release' is Okay.

Service Fabric Manifest Versions

MyAppType: 1.0.0
  OneService: Pkg 1.0.0 / Code 1.0.0 / Config 1.0.0
  TwoService: Pkg 1.0.0 / Code 1.0.0 / Config 1.0.0

Now, I fix OneService Code only. And Edit verisons of service fabric manifest.

Service Fabric Manifest Versions

MyAppType: 1.0.1(*)
  OneService: Pkg 1.0.1(*) / Code 1.0.1(*) / Config 1.0.0
  TwoService: Pkg 1.0.0 / Code 1.0.0 / Config 1.0.0

Second Commit > Build is Okay. But Release is Failed. The following error appears at log.

The content in ConfigPackage Name:Config and Version:1.0.0.20180315.2 in Service Manifest 'TwoServicePkg' has changed, but the version number is the same.

But I didn't modify TwoService Pkg (Both Code, Config).

Moreover, It's good to Publish To 'Azure Cloud Service Fabric Cluster' through VS2017 IDE, Immediately. (Of course, 'Upgrade the Application' option checked.)

Current temporary solution is to version up all (all pkg / code / config) like below.

Service Fabric Manifest Versions

MyAppType: 1.0.1(*)
  OneService: Pkg 1.0.1(*) / Code 1.0.1(*) / Config 1.0.1(*)
  TwoService: Pkg 1.0.1(*) / Code 1.0.1(*) / Config 1.0.1(*)

I want to construct build pipeline, But It's Confusing.

---

Additional Information

I just use default VSTS Service Fabric template.

And modify only Publish Profile name (Cloud.xml -> Cloud.Development.xml).

Release Task Screenshot

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