I was using VSMarketplace badges but they stopped to work:
https://img.shields.io/vscode-marketplace/d/thiagoguaru.DapperCrudGenerator.svg
Extension:
https://marketplace.visualstudio.com/items?itemName=thiagoguaru.DapperCrudGenerator
Edit: fix image link - RedSparr0w
I can reproduce this issue, but I think the issue may be with the upstream API.
Making a POST to https://marketplace.visualstudio.com/_apis/public/gallery/extensionquery/ with {"filters":[{"criteria":[{"filterType":7,"value":"thiagoguaru.DapperCrudGenerator"}]}],"flags":914} returns
{
"results": [
{
"extensions": [
],
"pagingToken": null,
"resultMetadata": [
{
"metadataType": "ResultCount",
"metadataItems": [
{
"name": "TotalCount",
"count": 0
}
]
}
]
}
]
}
The tested repos are returning badges as normal.
It seems to be all the vs extensions that are showing invalid
all the vscode extensions seem to be working as expected.
They may have seperate API's?
Extension | Category | Badge
:-- | :-- | :--
PowerShellToolsforVisualStudio2015 | Visual Studio→Tools |
python | Visual Studio Code→Programming Languages |
Oh yes - good spot. Not sure if this is expected behaviour then. It is hard to tell as we don't seem to be relying on a documented API behaviour :(
@calebcartwright Can this be closed?
I can still reproduce this, even with the latest changes to our Marketplace Services so I think we should keep it open.
I'll take a look at it though
Issue is the version validation. The DapperCrudGenerator extension referenced here is using a Major.Minor (2.8 specifically) version which doesn't match our schema validation on versions (which are expecting the Major.Minor.Patch with support for optional suffix).
Our schema validation is based on Microsoft's documentation for the manifest schemas for VS Code, Azure DevOps, and Visual Studio extensions, the latter of which here lists Version as being:
- Defines the version of this package and its contents. This attribute follows the CLR assembly versioning format: Major.Minor.Build.Revision (1.2.40308.00)
We could consider relaxing our schema validation to accept Major.Minor (not sure I'm a fan of that), or alternatively, @thiagoloureiro if you publish an updated version of your extension with version 2.8.0 then the badges should start working for you
I spent some time perusing various VS extensions on the Marketplace and they all followed the Major.Minor.Build.Revision version pattern, and I was able to render badges for all of them.
As such I'm even more inclined to leave our schema validation as-is, curious what others think
Ahh thanks for sorting that out!
I'm fine with that. Ideally we could throw a better error message, though documenting the limitation and referencing the Microsoft documentation may be sufficient.
Do we have a mechanism in the service definition to define a different error message for schema validation failures? It's a super useful approach for us developing the services but I agree that the invalid response data message users see isn't always ideal.
If not, then the only way I see to provide a better error message would be to relax the Joi schema validation for accepted version values, and then re-validate it after we get the response.
Something like #2632? Not yet 馃槈
@calebcartwright I will try to use 2.8.0
fixed! with 2.8.x version.
Thanks a lot guys.
Most helpful comment
It seems to be all the
vsextensions that are showinginvalidall the
vscodeextensions seem to be working as expected.They may have seperate API's?
Extension | Category | Badge

:-- | :-- | :--
PowerShellToolsforVisualStudio2015 |
Visual Studio→Tools|python |
Visual Studio Code→Programming Languages|