Use file picker for publishManifest file

[onlyutkarsh]

• Uses file picker for manifest file, which will fix Publish Visual Studio Extension usability feedback: file picker vs. directory picker + file name input #118
• Added few additional utility files required for development (.vscode for debugging and script to patch the develop guid in task.json to upload task for testing)

[jessehouwing]

Can you pull this out of the pull request? This is what the "Update task Ids" feature of the tasks are for.

[onlyutkarsh]

This is for me to test my individual task by directly uploading it to my account from my machine. It helps me to see the task in the pipeline before commit. I don't always publish the full extension to test the task.

[jessehouwing]

I'd like to keep these out of the standard project files. I like the env and vs code sample files, but they get packaged up with the task as well and may need cleanup. I can live with a script the project root/scripts. And install it's dependencies there too. Even better would be that they live in your fork. Or that the scripts and extension it depends on are fully integrated in the build pipeline.

[onlyutkarsh]

Agree, but this script is similar to what is already there under root\scripts folder and it is in root\scripts folder. They don't get packaged with the task or the extension as that folder is not part of the manifest file. I just verified by running npm run package:tasks, the VSIX file just contains the necessary files (ideally we should not include .ts files in vsix but we do today). I regularly use these scripts and its a pain every time to create these. Even if I keep these in my fork, I dont think you can selectively exclude files in the PR - if its possible, I am not aware :-p

[jessehouwing]

Could we use the same uuidv5 trick instead of putting dev guids in the repo? Cause these are your guids, not usable by someone else etc. Which is why I rely on the tasks themselves to build and publish dev versions ;).

I recently learned a cool trick which puts the vss-extension.json distributed over the task folders that way you can easily publish partial extensions.

[onlyutkarsh]

Cause these are your guids, not usable by someone else etc

Because uploading the task does not publish it to marketplace, these guids will be usable by others as well as long as they test in their account.

To give you more context, main reason to have this script is to test the task before committing the code.
My workflow is as below.

1. Change task (fix issue, logic etc)
2. Patch the task with different guid and friendly name
3. Upload only the task to test account (not the extension).
4. Use the task in the test pipeline (i have a pipeline to publish the vs extension)
5. if everything is working as expected, commit the changes
6. Now the extension pipeline kicks in under almrangers, we can test the task now as part of the extension.

Without that script, I cannot do 1 through 4, my whole dev workflow slows down. I need to either setup a separate pipeline for my fork or wait for PR to be merged to test my task.

I would love to learn the trick you have, but to test just the task, publishing it as partial extension seems bit of overkill. After all I can just use tfx build tasks upload --task-path .

[jessehouwing]

Let's work on a way to service your needs.

[jessehouwing]

Maybe I can put a yaml file instead of the current build, that would make it much easier to setup the pipeline. I've been bitten by partial uploads in the past and do my testing by running the transpiled js file locally instead. Or by overwriting the task directly in the local agent's _tasks folder.