No Upgrade Scenario when Certificate Expires

%3CLINGO-SUB%20id%3D%22lingo-sub-1543936%22%20slang%3D%22en-US%22%3ENo%20Upgrade%20Scenario%20when%20Certificate%20Expires%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1543936%22%20slang%3D%22en-US%22%3E%3CP%3ELet's%20say%20you%20create%20a%20package%20(1.0.0.0)%2C%20sign%20it%2C%20and%20deploy%20it.%26nbsp%3B%206%20months%20later%20you%20create%20an%20update%20(2.0.0.0)%2C%20keep%20the%20package%20name%20the%20same%20and%20use%20the%20same%20cert%20to%20sign%20it.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThen%20prior%20to%20the%20next%20release%20of%20your%20software%20your%20certificate%20expires%2C%20so%20you%20go%20out%20and%20purchase%20a%20new%20one%2C%20keeping%20the%20same%20%22Subject%2FPublisher%22.%20And%20now%20you%20want%20to%20release%20a%20new%20version%20of%20your%20package.%26nbsp%3B%20You%20can%20keep%20the%20package%20name%20the%20same%2C%20up%20the%20version%20string%2C%20and%20create%20version%203.0.0.0.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EOn%20a%20system%20with%20version%201%20installed%2C%20if%20you%20install%20version%202%20it%26nbsp%3B%20updates%20version%201.%20If%20you%20then%20install%20version%202%2C%20it%20does%20not%20work%20as%20an%20upgrade%3B%20the%20app%20is%20installed%20side%20by%20side.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThis%20is%20not%20a%20desired%20outcome%2C%20and%20should%20be%20addressed.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1834532%22%20slang%3D%22en-US%22%3ERe%3A%20No%20Upgrade%20Scenario%20when%20Certificate%20Expires%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1834532%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F146612%22%20target%3D%22_blank%22%3E%40TIMOTHY%20MANGAN%3C%2FA%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ELineage%20will%20continue%20if%20the%20publisher%20name%20is%20the%20same.%26nbsp%3B%20I%20suspect%20that%20in%20your%20scenario%20the%20publisher%20field%20in%20the%20manifest%20might%20be%20different%2C%20causing%20an%20issue%20and%20change%20to%20identity.%26nbsp%3B%20I%20think%20your%20feedback%20is%20there%20a%20way%20to%20keep%20continuity%20with%20my%20app%20in%20these%20situations%3F%26nbsp%3B%20If%20so%20that%20is%20great%20feedback%20and%20recommend%20that%20it%20be%20added%20to%20the%20ideas%20section.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EJohn%20Vintzel%20(%40jvintzel)%3CBR%20%2F%3EProgram%20Manager%20Lead%2C%20MSIX%3C%2FP%3E%3C%2FLINGO-BODY%3E
MVP

Let's say you create a package (1.0.0.0), sign it, and deploy it.  6 months later you create an update (2.0.0.0), keep the package name the same and use the same cert to sign it.

 

Then prior to the next release of your software your certificate expires, so you go out and purchase a new one, keeping the same "Subject/Publisher". And now you want to release a new version of your package.  You can keep the package name the same, up the version string, and create version 3.0.0.0.

 

On a system with version 1 installed, if you install version 2 it  updates version 1. If you then install version 2, it does not work as an upgrade; the app is installed side by side. 

 

This is not a desired outcome, and should be addressed.

1 Reply

@TIMOTHY MANGAN

 

Lineage will continue if the publisher name is the same.  I suspect that in your scenario the publisher field in the manifest might be different, causing an issue and change to identity.  I think your feedback is there a way to keep continuity with my app in these situations?  If so that is great feedback and recommend that it be added to the ideas section.

 

John Vintzel (@jvintzel)
Program Manager Lead, MSIX