extend tfx extension publish to allow overriding baseUri

[jessehouwing]

Many people, including the ALM Rangers, use the CI/CD tasks for Extensions to manage their extension workflow. Part of that includes changing the base-uri of the extension to point to a dev, test or prod environment.

A common request I receive from extension developers is to be able to change the baseuri when publishing from vsix.

The proposed syntax would be similar to --publisher:

tfx extension publish --vsix .\ext.vsix --base-uri https://localhost/debug

An even better solution would be to allow --override or --override-json to work with --vsix.

[T-Hugs]

This is tricky because we have to crack open the vsix and make the necessary changes. Supporting only --base-uri is practically the same amount of work to support --override or similar options.

Furthermore, even if we do crack the vsix, there isn't an elegant way to know how to edit the files inside. TFX always generates an extension.vsixmanifest, and in the case of vsts/tfs extensions, also an extension.vsomanifest. TFX only knows how to create these files based on the target from the original manifest.

I'm thinking the best way to implement this is to include the original manifest in the vsix. It shouldn't add much to the package size since it will compress well - most of the data is included in other files. I'm thinking maybe we could add a restriction to --override when running against an existing package that says you cannot use it to change the files that are included in the package.

At this point, we know how to re-generate the manifest files and then it's just a matter of replacing them in the vsix.

[jessehouwing]

We have a bunch of thus functionality implemented in the ci/cd extensions, where we indeed extract the extension and run a bunch of patches over the xml and json inside. We've had a few issues in the past, but most of them are solved, we provide a limited set of overrideable fields. But that said, I love the direction you've posed here, including the original manifest and laying out the files again.

…

On Tue, 20 Mar 2018, 20:27 Trevor Gau, ***@***.***> wrote: This is tricky because we have to crack open the vsix and make the necessary changes. Supporting only --base-uri is practically the same amount of work to support --override or similar options. Furthermore, even if we do crack the vsix, there isn't an elegant way to know how to edit the files inside. TFX always generates an *extension.vsixmanifest*, and in the case of vsts/tfs extensions, also an *extension.vsomanifest*. TFX only knows how to create these files based on the target from the original manifest. I'm thinking the best way to implement this is to include the original manifest in the vsix. It shouldn't add much to the package size since it will compress well - most of the data is included in other files. I'm thinking maybe we could add a restriction to --override when running against an existing package that says you cannot use it to change the files that are included in the package. At this point, we know how to re-generate the manifest files and then it's just a matter of replacing them in the vsix. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#263 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD-uS_YT2zD38Ql-DaGotZjLJ0Tnn2Arks5tgVgigaJpZM4Stub_> .

[bworline]

@jessehouwing does #342 cover your scenario?

[jessehouwing]

Looks like this will work when building from source, but not when republishing a vsix with overrides.