There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

1. HSCAN may return all the hash elements if hash size is small enough (<100).

   As mentioned in the Redis docs:

   When iterating Sets encoded as intsets (small sets composed of just integers), or Hashes and Sorted Sets encoded as ziplists (small hashes and sets composed of small individual values), usually all the elements are returned in the first SCAN call regardless of the COUNT value.

   To avoid this, add way to internally control the number of elements to be shown after clicking "Load More..."

2. When doing a filtered scan, sometimes only one result is returned after the first SCAN, although there may be many more matches

   We should continue scanning until we have loaded say max of 10 elements.

It's currently required because the images on the current Marketplace page reference the master branch.

I installed this extension, when I connect I have only 1 key, e007 which I don't know where it comes from but no the others (almost around 100 items) as you can notice in the 2nd snapshot

here is a napshot when I query Azure redis

When the key filter expression changes inside a cluster tree item, it refreshes the AzureCacheItem node, which will get a new ParsedRedisResource, disconnect, and reconnect to the cache.

In the non-clustered cache case, the key filter item is inside a DB tree item so a full refresh doesn't happen.

I was thinking in the case of a clustered cache, when the key filter changes, instead of calling refresh() on the entire cache tree item, just notify its children (the shard tree nodes) that the filter has changed.

Additional information to include in the Cache Properties view:

• VNET configuration
• Firewall rules
• Persistence type
• Advanced settings like:
  • maxmemory policy
  • maxmemory-reserved
  • maxfragmentationmemory-reserved
  • notify-keyspace-events

👋 Hi there, Martin here, from the VS Code team.

Recently we've announced the Remote Repository feature that lets you browse and edit files and folders directly on GitHub.

Open Remote Repository... opens VSCode on a folder or workspace located on a virtual file system. We call this a virtual workspace. We observed that not all extension support this well, either because they can not, or they haven't thought about it.

It would be fantastic if you could test whether your extension can handle virtual workspaces:

Check out the Virtual Workspaces Extension Author Guide on how to do that.

When done, set the new virtualWorkspaces capability in your 'package.json'.

{
  "capabilities": {
    "virtualWorkspaces": true | false
  }
}

• Use "virtualWorkspaces": true if your extension is prepared for virtual workspaces
• Use "virtualWorkspaces": false if your extension should be disabled when a virtual workspace is opened

For questions and comments please use the Virtual Workspaces Tracking Issue.

Thanks for the support and the great work! ❤️

VS Code extensions typically use vscode-nls to support externalization/localization.

The vscode-nls-dev is a tool that automates the extraction of strings to be externalized from TS and JS code

Related to microsoft/vscode-vsce#468

A better workaround than duplicating master would be to use the vsce flags --baseImagesUrl when running vsce package.

Does this occur consistently? No
Repro steps:

1. Let VS Code sit idle

Action: azureCache.refresh
Error type: ENOTFOUND
Error Message: getaddrinfo ENOTFOUND management.azure.com

Version: 0.1.0
OS: darwin
OS Release: 22.1.0
Product: Visual Studio Code
Product Version: 1.76.0
Language: en

Hi,

I recently installed the extension and was able to use it for very basic concepts. I even faced an issue, but was unable to file it under the right repository (see microsoft/azcode#38 for reference).

Looking at the issues, they don't have much activity nor answers and I wondered whether it would be worth for me to file the problem I had or not. The last commits date from August 2020 (notably @JeffreyCA and @kelzha as contributors) and the extension is technically in preview.

Thank you for your time. 😄

Subscription1
|-- Cache1 <=> webview1
|-- Cache2 <=> webview2

Currently, webviews are associated with a particular instance of a Cache tree item. But when you refresh the parent node of a Cache tree item (i.e. Subscription tree item), it discards all of its current child items and re-creates new ones.

Say for instance the user has the cache properties webview open for Cache1 and then refreshes the subscription tree node. If they click on the cache tree node again, instead of focusing the existing webview it opens another webview, resulting in two cache properties webviews for the same cache.

Demo:

Getting an SSL connection to console (especially from windows) is not a straight forward task.

• https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-how-to-redis-cli-tool#enable-access-for-redis-cliexe

There is a bug in ioredis (redis/ioredis#1149) that prevents it from connecting to a clustered Azure cache over SSL, so the extension always connects over non-SSL for clustered caches.

This is not ideal and users cannot connect to clustered caches that are SSL-only.

We show a "Cache is empty" tree item for non-clustered caches but not for clustered caches.

Screen recording:

Currently we only show the primary key info.

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

Your extension is incredibly popular with VS Code users! We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

Workspace Trust will remain disabled for the month of May, but we are planning on enabling this by default in the future. To prepare for that day, we would love for you to try it out and provide feedback.

We'd love your feedback

Since this issue was created in an automated fashion, we won't be monitoring the responses in this issue (our notifications would explode!). Instead we ask you to drop questions, and feedback in issue #120251 as we've mentioned above.

We're excited to see what you do with workspace trust!

To reproduce:

1. Change VS Code Color Theme to Dark
2. Navigate to a cache's Properties page

The labels are unreadable and the text fields don't match the theme.

It would be a separate view from the Cache Properties where the user can see the results of the INFO Redis command in an organized way.

We could first focus on getting the results of INFO to display in a plain text document, and then consider rendering it in a webview. Supporting multiple webviews will need bigger refactoring.

If you click on the box, it shows the whole box though

The minimum version is currently set to 1.47.0, which is the latest release minor version. Should lower it so it can reach more users.

When you sign out of your Azure account, existing Redis connections still continue to be alive, pinging away every 60 seconds.

Need a way to listen for sign out events to disconnect those connections. See microsoft/vscode-azuretools#772

VS Code connects to the Azure Redis instance, but with errors. Error: Cannot read access keys

Note that connecting with redis-cli over SSL requires stunnel and the stunnel configuration set for the cache.

See documentation: https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-how-to-redis-cli-tool#enable-access-for-redis-cliexe

This involves a fairly significant architectural change so it will be broken down into the following stages:

• Collection key children (lists, hashes, sets, zsets) (PR: #25)
• String keys (PR: #30)
• All keys in a single view in webview

Syntax highlighting works fine, but pretty-print with carriage returns and spacing does not work (Alt+Shift+F). It would be helpful to have JSON formatted in a way that is more readable directly in the pane showing the field values for each redis db.