7

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 Release Task Screenshot

Minos
  • 218
  • 2
  • 7
  • How does your VSTS build pipeline look like, which tasks are you using and how are they configured? – Ivan G. Mar 16 '18 at 13:07
  • Thank you for your attention. I added screenshot. – Minos Mar 16 '18 at 13:41
  • 1
    Can you share detail build log on the OneDrive? (set system.debug variable to true, then queue build and share this log) Can you reproduce this issue with the new project? If so, you can share sample project on the OneDrive. – starian chen-MSFT Mar 19 '18 at 02:43
  • 1
    Check whether it is related to deterministic compiler flag: https://stackoverflow.com/questions/49236009/net-framework-class-library-dll-always-changes-when-updating-service-fabric-ser – starian chen-MSFT Mar 20 '18 at 01:37
  • @starianchen-MSFT I used the default template and confirmed that the option was already turned on. There is nothing special about the project. The service fabric example in github also produces the same error. But in your answer, I have some information and it seems to be helpful. Thank you for the reply. – Minos Mar 20 '18 at 04:37

1 Answers1

4

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

Diego Mendes
  • 10,631
  • 2
  • 32
  • 36
  • Thank you. I tried to check 'Use Diff Package' of 'Deploy Service Fabric Application'. Then, the upgrade is normally performed. On the page you linked to, the following is mentioned. When an application is upgraded using Visual Studio, a diff package is published automatically. To create a diff package manually, the application manifest and the service manifests must be updated, but only the changed packages should be included in the final application package. So (maybe) I was able to make the VSTS CD to the VS2017 env and it works. – Minos Mar 20 '18 at 04:33
  • But I still have questions. Why is the VSTS Service Fabric Release Template turned off by default? If you are configuring a VSTS CI / CD for Production, I would like to know what settings you recommend. – Minos Mar 20 '18 at 04:33
  • Does the 'Use Diff Package' option of VSTS have the same effect as 'Upgrade the Application' of VS2017 Publish option? (That is, it must be turned off at first, then turned on at the next upgrade) – Minos Mar 20 '18 at 04:56
  • On VSTS you have two CI steps for service fabric, one is Update Manifest Versions and the other is deploy SF Application. If you want to upgrade the manifest version on every build, you should use the update task and them deploy. It is turned off by default because it is easier to upgrade all services every time than creating differential packaging, the differential packaging is very tricky and needs a deeper understanding how thing works in SF. – Diego Mendes Mar 20 '18 at 10:17
  • They are slightly different, but the overall result is pretty much the same. I don't remember the exact differences right know. – Diego Mendes Mar 20 '18 at 10:20
  • I've read this multiple times and still doesn't explain it well enough or what we have to do to resolve it. – Andrew Apr 13 '22 at 07:40