Open henryju opened 6 years ago
T-Hugs
commented
6 years ago You can specify the content type of any asset in your manifest. e.g.
"files": [
{
"path": "yourScript.bat",
"addressable": true,
"contentType": "application/bat"
}, { etc }
],Unfortunately there's no good consistent way to generate these cross platform without hardcoding all the extensions. We have a few hard-coded, but perhaps the list could be longer.
bryanmacfarlane
commented
6 years ago @trevorsg - The build task needs to carry all files for all platforms (we have one task stored that all platform agents download). there should be nothing dynamic here.
T-Hugs
commented
6 years ago @bryanmacfarlane What do you suggest? Only thing I can think of is make the hard-coded list longer, but at some point people are going to upload files with extensions that aren't on the list. Do we generate an error if the mime type is not specified and not on our list? That's a breaking change, and could be problematic for extensions with lots of files.
nschonni
commented
6 years ago It's pretty long, but I believe that this is the "official" list https://www.iana.org/assignments/media-types/media-types.xhtml
Also seems to have NPM package https://www.npmjs.com/package/mime to query that info
henryju
commented
6 years ago The offending file(s) are shell scripts without extension so adding more hardcoded mime types will not help. Also, the file is not addressable. We only need to have it unzipped on the agent so that our task can call it.. I can understand why addressable files need to have a content type, but I don't understand why you have this constraint when extracting the task resources on the agent. Still I will try to force the content type (by chance we only have a few files), thanks for the trick. May I suggest to document the ability to override the content type, for example here: https://docs.microsoft.com/en-us/vsts/extend/develop/manifest
evertonmc
commented
5 years ago You can specify the content type of any asset in your manifest. e.g.
"files": [ { "path": "yourScript.bat", "addressable": true, "contentType": "application/bat" }, { etc } ],Unfortunately there's no good consistent way to generate these cross platform without hardcoding all the extensions. We have a few hard-coded, but perhaps the list could be longer.
Hello there. I'm having this problem with the hub.html file not being recognized as text/html and defaulting to application/octet-stream which forces the browser to download it. Since the hub file is not addressed in the files array of the manifest but in the contributions.properties.uri object, I see no possible way to override the ContentType here. Any thoughts?
PS: this only happens if I build it in an agent. Packaging locally sets the correct contentType to the html file
evertonmc
commented
5 years ago T-Hugs
commented
5 years ago @evertonmc Unless I'm mistaken, the file won't be included in the VSIX at all if it is only referenced in contributions.properties.uri. It is true that some files are auto-added to the package, but even in that case, the entry given in the files array should override the one that is auto-added. Therefore if you include an entry in the files array and give a contentType, it should pick that up.
evertonmc
commented
5 years ago T-Hugs
commented
5 years ago @evertonmc Got it. As a workaround, you should be able to list that individual file and give it a content type. It should play nicely with the directory entry.
mickael-caro-sonarsource
commented
5 years ago Hi,
In our latest tests, we saw that the files are not yet on the ContentType.xml file (version 0.7.8 of tfx-cli), but that the problem seems gone as the files seems correctly unzipped.
Could you confirm that something has been done on your side on this topic ?
Thanks.
VAllens
commented
4 years ago I noticed that it use winreg to try to get the Content Type value from the windows registry, fill the value of the ContentType property of the Default element.
https://www.cnblogs.com/VAllen/p/azure-devops-extensions-content-types-warning-fix.html
(Might be related to #177, but I will try to give more details.)
tfx-cli0.5.5In our VSTS extension, we are embedding a command line tool that will be run by the task. Our command line tool has different executables according to the operation system:
bin/sonar-scanner.baton Windows,bin/sonar-scanner(shell script) on Linux/MacOSX.We discovered that our extension is broken when packaged from a Windows computer. The issue is that shell scripts are missing on the agent.
Logs on VSTS when extension is packaged from Linux:
Logs when extension is packaged from Windows:
That's how we discovered that the 3 shell scripts without extensions (
sonar-runner,sonar-scannerandsonar-scanner-debug) are missing on the agent when the extension is originally packaged on Windows.I was first suspecting a bug in our packaging process so I looked at the vsix content to see if the files were actually inside: but the files are effectively present even when the extension is packaged on Windows.
Then I used a tool to compute the diff of the two vsix, to finally discover that the issue seems to come from
[Content_Types].xml. The content is totally different depending on the build platform.On Windows:
On Linux:
As you can see, on Windows we don't have any entry for the 3 shell scripts. Do you confirm this is the reason why files are not available on the build agent? If yes, since the content of
[Content_Types].xmlhave a strong impact on the runtime of the extension, I find it really dangerous that its content depends so heavily on the build platform.Can't you find a way to generate it in a more consistent way? Is it possible to configure
tfx-cliin order to force some entries, so that at short term we can fix the build on Windows?