TFX publish expects "-major.minor.patch.gen" at end of name

[jdshkolnik]

Hi,

My build definition packages the extension as "publisherid.extensionid.vsix" but the release definition attempts to publish it as "publisherid.extensionid-major.minor.patch.gen.vsix". Are you assuming I will always somehow pass the version as a variable and append it along with that ".gen"?

[bfcamara]

Hi,

in theory, if you are not overriding anything (extension id, name, version, visibility) while publishing your vsix, then the publish task should use directly your vsix input file. It is only when there are params to override that the task generates a new vsix with the name "publisherid.extensionid-major.minor.patch.gen.vsix" reflecting the new overriden values, and then uses this new vsix to publish it. Are you overriding any value in the publish task?

[jdshkolnik]

@bfcamara One of the override checkboxes was selected but I uncovered other errors after deselecting it.

1. The "Select File Or Folder" dialog won't let me choose the artifact folder as the working directory.

1. If I manually set the working directory to $(System.DefaultWorkingDirectory)/TFS-Build-Extensions-CI/vsix the task will fail with a vague error: "Error running task: Invalid filename"
2. It does work if I put the whole path into the VSIX file input but then it won't work if I try to use a variable within the file name. The problem is that I'm generating a vsix which looks like this "jdshkolnik.solvas-devops-utility-1.6.3.vsix" but those numbers will change.

[jdshkolnik]

@bfcamara I was wrong, it's still adding the ".gen" despite no overrides being selected.

[command]I:\Agent\VSTS_work\r2\a\node_modules.bin\tfx.cmd extension publish --json --token ******** --service-url https://marketplace.visualstudio.com/ --proxy http://x.x.x.x:yyyy --vsix jdshkolnik.solvas-devops-utility-1.6.3.gen.vsix

[bfcamara]

The reason why the task is generating a new vsix file (with .gen in its name) is because it is being specified the Publisher Id and the Extension Id fields. As soon as these fields have non empty values, the task is assuming that you're overriding the original values and then it will generate a new vsix file with the new values, even if the new values are equal to the ones inside the original vsix,

The field VSIX file should have the VSIX file path (unlike the option Extension Manifest file where you can use glob patterns for the JSON manifest file). You can use $ variables in its value. It seems that in your Build you are generating a vsix file that has the Major/Minor/Patch parts in its name. Unless you have these values defined as variables in your Release that you could use to specify the full VSIX file path, you probably want to have a fixed vsix file name produced by your build.

[jdshkolnik]

Thanks. I removed all of those and it still appended .gen because I had a value in extension visibility. Once I got rid of that it went away. I'm not sure what would be the most intuitive way to warn someone who might stumble on this same problem. A warning in the tooltip?

[bfcamara]

That's correct - the visibility field also needs the generation process (in fact any field that needs to be modified in the original VSIX). I think the user doesn't need to know the internals - I think what is missing is a way to have the generated VSIX file in a output variable to be able to know what file was just published. I can't remember why when specifying a VSIX file the task doesn't allow to specify the output variable name as in the Manifest option, even though the code to determine the value is there for both options but only set in the Manifest option. If you could have the generated VSIX file in a output variable, would it solve your problem?

[jessehouwing]

The output variable is something that was ported over from my powershell extension. The work from me and Wouter (who wrote the code to patch the vsix) probably crossed eachother here. Being able to override the output file name wouldn't be bad either. There is no real reason why it can't write to a specific file name.