Month: February 2025

When GitHub Copilot completions (or “gray text”) pop up on your screen, have you ever wondered where does the completions come from and worried about if it matches with public code leading to license issues? If you have, we are introducing code referencing to support you and provide more transparency!

We are excited to announce that code referencing is available now for GitHub Copilot Completions in Visual Studio 2022 17.13, a feature previously introduced in Copilot Chat (see previous blog post). So you can feel more confident when accepting the completions!

Learn about Completions Public Code Match

When you accept a completion that matches code in a public GitHub repository for the first time in your solution, a toast notification will appear on the bottom right of your editor.

From the toast, you can view code matches in the GitHub Copilot Output Window, where includes more detailed information about the license type and a link to GitHub.com, where the original public code file lives. You can click on the link to read more about the original file and make informed decisions, such as including code attribution or removing the code from your project.

From the toast, you can also learn more information about public code match and how to manage it as an individual subscriber here: Managing Copilot policies as an individual subscriber.

In your future coding workflow, you can always check for any public code match by opening the Output Window (Ctrl+Alt+O) and searching for “Completions Public Code Match Information.”

Note:

• Code referencing for completions only occurs for accepted Copilot completions. Any code you have written, as well as completions you have modified or dismissed, are not checked for public code matches.
• Typically, matches to public code occur in less than one percent of Copilot completions, so you should not expect to see code references for many completions. This estimation is higher if you work in open-source repositories.

Configure Code Referencing

Note: If you are a member of an organization on GitHub Enterprise Cloud and have been assigned a GitHub Copilot seat through your organization, you may not be able to configure suggestions matching public code in your personal account settings. Your settings will be inherited from your organization or enterprise.

If you are an individual subscriber, your personal settings for GitHub Copilot include an option to either allow or block code suggestions that match publicly available code:

• Block suggestions matching public code: GitHub Copilot checks code suggestions with their surrounding code against public code on GitHub. If there’s a match or near match, the suggestion is not shown.
• Allow suggestions matching public code: When Copilot suggests matching code, you can view details of the matches and navigate to the relevant repositories on GitHub.

To adjust your settings:

1. In the upper-right corner of any page on GitHub, click your profile photo, then click Your Copilot.
2. Next to Suggestions matching public code, use the dropdown menu to select Allow or Block.

For more information, see Managing Copilot policies as an individual subscriber.

Code with More Confidence and Transparency

This new functionality offers developers greater transparency on their code completions (or “gray text”) by providing detailed information on any public code matches found. Prior to this change, Copilot completions with public code match were automatically blocked. Now, developers have the choice to access more code completions and receive sufficient information about any public code matches, enabling them to make informed decisions.

Try It Out Today

We believe this new code referencing feature in Copilot Completions improves your development experience with more transparency and informed choices. Give it a try in Visual Studio 17.13 or later, and share your feedback with us.

We appreciate the time you’ve spent reporting issues/suggestions and hope you continue to give us feedback when using Visual Studio on what you like and what we can improve. Your feedback is critical to help us make Visual Studio the best tool it can be! You can share feedback with us via Developer Community: report any bugs or issues via report a problem and share your suggestions for new features or improvements to existing ones.

Stay connected with the Visual Studio team by following us on YouTube, Twitter, LinkedIn, Twitch and on Microsoft Learn.

I have an Azure Function app and have a kafka trigger which works on other environments. I get this error when trying to to use a new cluster locally in a docker container. The cluster id is FaMgNL3ASkmp-GvfewNOxw. Where or how is it caching that older cluster id?

[2025-02-19T17:43:07.579Z] Libkafka: [thrd:main]: Broker GroupCoordinator/1 reports different ClusterId "bfU02MJ8Sz24p3v5pUAukQ" than previously known "JbosiV5OSVqk1UuvSu8IlA": a client must not be simultaneously connected to multiple clusters
[2025-02-19T17:43:07.591Z] Libkafka: [thrd:main]: Broker localhost:9092/bootstrap reports different ClusterId "JbosiV5OSVqk1UuvSu8IlA" than previously known "bfU02MJ8Sz24p3v5pUAukQ": a client must not be simultaneously connected to multiple clusters

We continue to invest in the VisualStudio.Extensibility SDK to allow users like you to create extensions that run faster and smoother than ever before! VisualStudio.Extensibility helps you build extensions that run outside the main Visual Studio IDE process for improved performance, reliability, and installation without restarting Visual Studio. Additional benefits include a sleek and intuitive .NET 8-based API and comprehensive, well-maintained documentation to help you develop amazing extensions faster than ever before.

For the latest up-to-date docs and installation instructions, visit https://aka.ms/VisualStudio.Extensibility. We encourage you to report bugs and suggest features via the issue tracker on our GitHub repo, where you can also find extension samples to help you get started.

Our 17.13 release of VisualStudio.Extensibility includes the following features:

• Enhanced editor extensibility through tagger support
• Expanded settings API to allow for observation of changed settings values

Both sets of APIs are marked as experimental, which means that they are subject to change as we iterate on the design based on customer feedback. A core principle of VisualStudio.Extensibility is to provide intuitive APIs. As hard as we work to shape the API to be intuitive from inception, we understand that there are likely gaps we’re missing or assumptions we’re making that could be addressed over time. We therefore mark new APIs as experimental to allow customers to report such gaps so we can address them. To read more about our experimental API and breaking changes policy, please see here.

Taggers – the foundation of custom text decoration

A powerful editor is foundational to a developer’s daily workflow, providing the essential tools and features needed to write, debug, and maintain code efficiently. In Visual Studio, text decorators are one of the key differentiators that enhance this experience. These decorators, such as text colorization and CodeLens, offer contextual information to help developers understand and navigate their code more effectively. At the heart of these decorative features is the concept of taggers. Taggers are the mechanism to mark the text in the editor with hidden information, enabling the editor to adopt various text decorations later.

For example, to provide a custom CodeLens, first we need to define where the CodeLens should show up. Is it CodeLens for a method or a class? Different languages have different syntax for how methods are defined, and some languages may not have classes at all. To know where the blocks of code that make sense for your custom CodeLens to show up, we first need to “tag” the text in the editor with additional information. In 17.12, we talked about how CodeLens can only be created for languages supported by default in Visual Studio, like .NET or C++. This is because the text is already tagged by our own language services to contain the metadata needed for CodeLens. In 17.13, we are providing the API to provide your own tags, so that you can add CodeLens to languages not supported by Visual Studio. The following example shows a snippet of how to define CodeLens tags for a markdown file.

[VisualStudioContribution]
internal class MarkdownCodeLensTaggerProvider : ExtensionPart, ITextViewTaggerProvider<CodeLensTag>, ITextViewChangedListener
{
    private readonly object lockObject = new();
    private readonly Dictionary<Uri, List<MarkdownCodeLensTagger>> taggers = new();

    public TextViewExtensionConfiguration TextViewExtensionConfiguration => new()
    {
        AppliesTo = [DocumentFilter.FromDocumentType("vs-markdown")],
    };

    public Task<TextViewTagger<CodeLensTag>> CreateTaggerAsync(ITextViewSnapshot textView, CancellationToken cancellationToken)
    {
        var tagger = new MarkdownCodeLensTagger(this, textView.Document.Uri);
        lock (this.lockObject)
        {
            if (!this.taggers.TryGetValue(textView.Document.Uri, out var taggers))
            {
                taggers = new();
                this.taggers[textView.Document.Uri] = taggers;
            }

            taggers.Add(tagger);
        }

        return Task.FromResult<TextViewTagger<CodeLensTag>>(tagger);
    }
}

Of course, there’s a lot more that goes into creating taggers for markdown files, so to view the whole code sample, please see here, or you can refer to our documentation for more details. Try it out and customize the CodeLens experience in your extension even more!

Observing changes to settings values

Another addition we introduced in 17.13 is an enhancement to our settings API which allows extenders to get notified of changes to their settings values. Extenders can now generate settings observers to monitor changes and read their settings value snapshot.

public MyToolWindow(MyCategoryObserver settingsObserver)
{
    settingsObserver.Changed += this.SettingsObserver_ChangedAsync;
}

private async Task SettingsObserver_ChangedAsync(MyCategorySnapshot settingsSnapshot)
{
    this.MySetting = settingsSnapshot.MySetting.ValueOrDefault(defaultValue: true);
    ...
}

Please read our documentation for more detailed information and walk through our sample code for full context.

The time and effort you’ve spent reporting issues and sharing suggestions so far has been instrumental in shaping VisualStudio.Extensibility. We need your help as we continue to develop VisualStudio.Extensibility! Please try out the features and APIs announced and let us know what you think. Check out the docs, browse the code samples, and build your first extension. You can send feedback and report issues through our issue tracker.

To request features, look at Developer Community to see if someone else made a similar request first. Create a new one if you can’t find a similar request. By checking for similar requests and upvoting and commenting on them, you help us better prioritize requests. Give VisualStudio.Extensibility a try today and share your thoughts with us!

We appreciate the time you’ve spent reporting issues/suggestions and hope you continue to give us feedback when using Visual Studio on what you like and what we can improve. Your feedback is critical to help us make Visual Studio the best tool it can be! You can share feedback with us via Developer Community: report any bugs or issues via report a problem and share your suggestions for new features or improvements to existing ones.

Stay connected with the Visual Studio team by following us on YouTube, Twitter, LinkedIn, Twitch and on Microsoft Learn.