0

I have incremented the version of one of the services in my Service Fabric application.

However, when I try to upgrade the cluster I get the error below:

The content in CodePackage Name:Code and Version:1.0.0 in Service Manifest 
3>'MYAPPLICATION.ServiceFabricPkg' has changed, but the version number is the same.
3>At C:\Program Files\Microsoft SDKs\Service 
3>Fabric\Tools\PSModule\ServiceFabricSDK\Publish-UpgradedServiceFabricApplication.ps1:135 char:38

This is a huge issue for me as one of the best selling points of Service Fabric is being able update one service without touching others.

Does anyone know a solution for this?

Research points to the error being related to compression, so I added

<CopyPackageParameters CompressPackage="false" />

to my Local5Node.xml file.

This makes no difference.

I am trying to do this via publish with Visual Studio 2017.

Cheers

Paul

Super Jade
  • 5,609
  • 7
  • 39
  • 61
Paul
  • 2,773
  • 7
  • 41
  • 96

2 Answers2

1

This happens because you have updated the service binaries and didn't update the manifests with a new version number, the manifest points to the same version as before but the binaries are different.

Service fabric use the manifest versions to identify which services should be updated during an application upgrade, because you didn't set the new versions and the binaries has changed, it will rollback to avoid issues.

A quick search about this error return a few results with the reason for this, please take a look on these answers:

Error while upgrading Azure Service Fabric through VSTS CI/CD

Deployment for Service Fabric service version upgrade fails on VSTS Release

Differential packaging

Diego Mendes
  • 10,631
  • 2
  • 32
  • 36
  • I only changed code in a single service which is the one I changed the manifest versions of in the application. The service it is complaining about was not changed at all – Paul Aug 02 '18 at 17:17
  • I normally build and deploy via visual studio directly its a bit of a pain having to setup all the team services stuff but I will give it a go. Hopefully this will fit into team city and octopus as that’s what I want to use long term – Paul Aug 02 '18 at 17:59
  • Every time you build your code, a new version of the binaries are created, even though the code is the same, the hash will be different. If you don't want to create new binaries, you have to setup VS to build only if the code has changed. – Diego Mendes Aug 02 '18 at 18:01
  • That sounds better and faster overall – Paul Aug 02 '18 at 18:02
  • How do I do that in Visual Studio (setup VS to only build if code has changed)? – Paul Aug 02 '18 at 23:56
  • I want to be able to deploy to my local cluster and also to debug – Paul Aug 03 '18 at 00:19
  • Visual Studio actually does that out of the box if you do a Build (not a Rebuild), you just have to check if it is working as expected, you also have to setup differential packaging as described in the link I posted in the original answer, and also as described in this docs: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-upgrade-advanced#upgrade-with-a-diff-package – Diego Mendes Aug 03 '18 at 07:50
  • Looks like I will have to do diff packaging shame I have to go through all this is this not a bug? I don’t want to have to push code just to be able to update my local cluster so can’t really use the team services option. I thought publish does a build which would prevent interception – Paul Aug 03 '18 at 07:53
  • I am not sure if you can do differential packaging with debugging, by the way you said, Ithink what you whant is to set the debug mode, instead of deployment please check this link https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-manage-application-in-visual-studio#application-debug-mode – Diego Mendes Aug 03 '18 at 07:55
  • This is really bad now I have reverted all my changes and this error is still happening – Paul Aug 03 '18 at 10:00
0

I think you can have a problem when you have updated the service code, updated code version in the ServiceManifest.xml but haven't updated the application version in ApplicationManifest.xml.

Here are examples if you are updating you service from version 1.0.0 to 1.1.0.

Manual Approach

In ServiceManifest.xml

  1. Update version of code package.
<CodePackage Name="Code" Version="1.1.0" />
  1. Update version of service manifest.
<ServiceManifest Name="ServicePkg" Version="1.1.0" />

In ApplicationManifest.xml

  1. Update version of service manifest reference.
<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="ServicePkg" ServiceManifestVersion="1.1.0" />
  <ConfigOverrides />
</ServiceManifestImport>
  1. Update version of application type
<ApplicationManifest ApplicationTypeName="AppType" ApplicationTypeVersion="1.1.0" />

Visual Studio Approach

  1. Select Service Fabric Application project and Right Click on in
  2. Choose 'Edit Manifest Versions...'
  3. Check 'Automatically update application and service versions'
  4. Change version of 'Code' in service you like.

Hope this helps.

Oleg Karasik
  • 959
  • 6
  • 17
  • I have always used the visual studio way that’s what’s so frustrating – Paul Aug 06 '18 at 06:55
  • @Paul have you checked that all of the versions were changed? In the visual studio 'Automatically update application and service versions' sometime can be unchecked and without it Visual Studio won't do cascade version update. – Oleg Karasik Aug 06 '18 at 07:19
  • Where is that option? – Paul Aug 06 '18 at 07:20
  • @Paul in the lower right corner of the dialog when clicking 'Edit Manifest Versions...' – Oleg Karasik Aug 06 '18 at 08:08
  • https://stackoverflow.com/questions/51797730/prevent-visual-studio-from-rebuilding-after-packaging-service-fabric-with-diff-p – Paul Aug 11 '18 at 08:34