正在下载用于nuget.org的intellisense index-Downloading intellisense index for nuget.org

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

VSF_TYPE_MARKDOWNDownloading the IntelliSense index for nuget.org is running all the time, unable to debug the program, prompt to install the Android SDK when debugging the program

---

Original Comments

Visual Studio Feedback System on 5/22/2019, 00:45 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

冰尘 on 5/23/2019, 07:54 AM:

I has this problem too. This prolbem was found since VisualStudio2019 upgrade to v16.1.0

Visual Studio Feedback System on 5/24/2019, 11:30 AM:

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2017#faq . In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/ . We'll keep you posted on any updates to this feedback.

Eduardo Gasparoto Semprebon on 5/28/2019, 05:31 AM:

Same issue here, using 16.1.1.

Already tried to clear the solution, deleted the .vs folder... Nothing

jim liu on 6/2/2019, 00:02 AM:

I repair the installation solved this issue.

彬彬 廖 on 6/11/2019, 05:26 PM:

I repair the installation, and still can't solve this issue.

my computer works in offline mode.

Mayuresh Sawardekar on 6/18/2019, 08:40 AM:

Any update on the issue above ? Even repairing the installation did not help.

Cagri (Charlie) Aslan [MSFT] on 6/18/2019, 11:35 AM:

Thanks for the feedback. Is it possible for you to use the 'record' functionality in the 'send feedback' tool and capture VS when it is having the problem? It will get us perf traces that should let us figure out what's going on. Thanks!

Mayuresh Sawardekar on 6/18/2019, 01:27 PM:

Hopefully the video comes through. Thanks

David Roth on 6/18/2019, 00:33 PM:

After upgrading to 16.1.3 yesterday, I do not see this issue anymore

Mayuresh Sawardekar on 6/18/2019, 00:44 PM:

I am on VS 2019 v16.1.3 . I am not able to see "record functionality" in "send feedback". All I see is "Report a problem" and "Suggest a feature"

Cagri (Charlie) Aslan [MSFT] on 6/18/2019, 00:46 PM:

This might help: https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019

Mayuresh Sawardekar on 6/18/2019, 01:31 PM:

@Cagri (Charlie) Aslan [MSFT] : I did send over the VS capture via the "send feedback" tool. Hopefully it came through.

Cagri (Charlie) Aslan [MSFT] on 6/18/2019, 01:43 PM:

It says it is still uploading. I'll check again in a couple of hours. Thanks!

Mayuresh Sawardekar on 6/19/2019, 06:25 AM:

@Cagri (Charlie) Aslan [MSFT] Any update on it yet ?

419830883 on 6/26/2019, 08:30 PM:

In 16.1.4,this problem still exists.Is there any solution?

刘涛 on 6/26/2019, 08:37 PM:

我目前的解决办法是通过Android Studio 中Android Sdk tool 下载对应的SDK与工具 到C:\Program Files (x86)\Android\android-sdk暂时解决的,

关于Bug修复进度Allen在帮忙跟进

https://developercommunity.visualstudio.com/content/problem/600284/xamarinandroid-sdk-manager-offline-mode-after-upgr.html

Translated from Bing:

My current solution is to download the corresponding SDK and tools from Android Sdk tool in Android Studio to C:\Program Files (x86)\Android\android-sdk for temporary solution.

Allen is helping to follow up on the bug fix progress

Https://developercommunity.visualstudio.com/content/problem/600284/xamarinandroid-sdk-manager-offline-mode-after-upgr.html

Eduardo Gasparoto Semprebon on 6/27/2019, 01:07 AM:

Still same issue in 16.1.4. I don't have Android SDK in the machine.

Mayuresh Sawardekar on 6/27/2019, 04:50 AM:

I too dont have Android SDK in the machine. Help needed to resolve this issue.

John Burke on 6/28/2019, 11:40 AM:

I am having the issue as well. Upgraded to 16.1.4 and it still exists. Anything I can do to workaround?

419830883 on 7/9/2019, 08:44 PM:

This issue has been solved in 16.1.6,thanks for everyone!

John Burke on 7/11/2019, 10:56 AM:

I upgraded to 16.1.6 and it is not fixed. Still getting the message.

Ray on 8/23/2019, 01:55 AM:

It's now 16.2.3 and.... you guessed it: issue is still here!

Removed nuget.org from VS.NET setting and solution settings, restarted several times, reinstalled VS.NET, told my mum about it... and it just refuses to move on like a bad date.

Thankfully I don't have OCD otherwise this would drive me crazy

zebal on 9/13/2019, 05:23 AM:

I have the same issue, VS 16.2.5

Fresh installed system and VS.

"Downloading intellisense index for nuget.org"

Firewall is open.

This should be fixed, what information do you need?

Rob Relyea [MSFT] on 9/13/2019, 03:42 PM:

No idea which component is trying to download some intellisense index from nuget.org.
I strongly believe this is not the NuGet team trying to do this.

It would be interesting to figure out who might be downloading an intellisense index via nuget.org.
Which component of VS? Which workload are you running?

Does this only happen when you have a solution loaded?
Etc…

-Rob Relyea
NuGet Team.

Ge Ge on 9/13/2019, 11:08 PM:

@Rob Relyea [MSFT] "Downloading intellisense index for nuget.org" will only show in the Background Task button (in the bottom left of the screen). And yes, it seems only happen when having a solution loaded.

My solution:

1. Use VPN to finish the download.

2. If it doesn't work, go to Options > NuGet Package Manager > Package Sources, and delete "nuget.org" item (back up the info if you want). Restart VS 2019, problem solved. And then you can add the "nuget.org" back.

At least works for me :P

zebal on 9/14/2019, 05:20 AM:

@Rob Relyea [MSFT]

It's a background task in VS usually starting together with intellisense (that is when intellisense is doing parsing job on load of solution). and so far only when loading Unreal Engine 4 project.

It happens randomly, sometime yes sometimes not, I usually restart VS to get rid of it thanks to to its randomness.

I tried to reproduce the issue why recording my system with perfview but the problem didn't occur :(

I also tried the suggestion to remove and re-add nuget.org link in options, but can't tell if that solved the issue, it's too early to conclude, I'm sure this background task will come back once, and if so I'll record system and send you pefview logs.

Visual Studio Feedback System on 9/14/2019, 01:35 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

Ge Ge solved on 7/25/2019, 09:04 PM, 0 votes:

Use VPN to finish the download.

If it doesn't work, go to Options > NuGet Package Manager > Package Sources, and delete "nuget.org" item (make a screen shot if you want). Restart VS 2019, problem solved. And then it won't start donwloading any more if you add the "nuget.org" back.

419830883 solved on 7/9/2019, 08:43 PM, -3 votes:

This issue has been solved in 16.1.6,thanks for everyone!

[sharwell]

📝 The investigation for this issue was limited to only the case of the "Downloading IntelliSense Index" message. Debugging scenarios are not related to this message, and are not being covered by this issue. If you are experiencing a debugging problem, please file a new feedback with the details even if you are seeing the "Downloading IntelliSense Index" message.

[CyrusNajmabadi]

@sharwell "Downloading IntelliSense index" is only ever reported in this single place:

                    var title = string.Format(EditorFeaturesWpfResources.Downloading_IntelliSense_index_for_0, _source);
                    await _service._progressService.OnDownloadFullDatabaseStartedAsync(title).ConfigureAwait(false);

This is specifically in the following try/catch:

                try
                {
                    var title = string.Format(EditorFeaturesWpfResources.Downloading_IntelliSense_index_for_0, _source);
                    await _service._progressService.OnDownloadFullDatabaseStartedAsync(title).ConfigureAwait(false);

                    var (succeeded, delay) = await DownloadFullDatabaseWorkerAsync().ConfigureAwait(false);
                    if (succeeded)
                    {
                        await _service._progressService.OnDownloadFullDatabaseSucceededAsync().ConfigureAwait(false);
                    }
                    else
                    {
                        await _service._progressService.OnDownloadFullDatabaseFailedAsync(
                            EditorFeaturesWpfResources.Downloading_index_failed).ConfigureAwait(false);
                    }

                    return delay;
                }
                catch (OperationCanceledException)
                {
                    await _service._progressService.OnDownloadFullDatabaseCanceledAsync().ConfigureAwait(false);
                    throw;
                }
                catch (Exception e)
                {
                    var message = string.Format(
                        EditorFeaturesWpfResources.Downloading_index_failed_0,
                        "\r\n" + e.ToString());
                    await _service._progressService.OnDownloadFullDatabaseFailedAsync(message).ConfigureAwait(false);
                    throw;
                }

So, regardless of what happens (completion/cancellation/error) we should always be getting a message to one of:

OnDownloadFullDatabaseSucceededAsync, OnDownloadFullDatabaseFailedAsync, OnDownloadFullDatabaseCanceledAsync

These then bottom out in https://github.com/dotnet/roslyn/blob/master/src/VisualStudio/Core/Def/Implementation/SymbolSearch/VisualStudioSymbolSearchService.ProgressService.cs#L82 where we should always be setting the TaskCompletionSource for the task-center task appropriately.

The only thing i can think of that would ever keep "Downloading_IntelliSense_index_for_0" in the task-center UI perpetually would be if we literally were making no progress downloading hte index. i.e. if the call to Microsoft.VisualStudio.RemoteControl.RemoteControlClient.ReadFileAsync literally was just taking forever.

[JohnyL]

VS 2019 16.4.0 Preview - the problem still exists.

[sharwell]

It looks like the background notification shows even when the download operation is waiting for future retry. Perhaps we should only show the message during the actual download operation?

Also, I'm wondering if a workaround would be disabling completion suggestions from NuGet packages:

[WrongBit]

@sharwell : good point, but didn't help. In VS team settings are living separate life from real code - nobody care. And yes, PROBLEM STILL EXIST! I'm tired of that girlish animation with the one useless task "download hell knows what I don't use".

[CyrusNajmabadi]

It's likely something has crashed somewhere. So the task is never completing. More data will need to be collected to determine what is happening here.

[asymmetricblue]

I encountered this today in 16.3.1, I could not open a specific solution without it going into a non-responsive state. Opening VS without opening a project was fine.

I normally operate disconnected from the Internet with a local nuget source configured.

I was able to work around it by setting Enabled=0 in HKCU\SOFTWARE\Microsoft\VisualStudio\16.0_hhhhhhhh\Roslyn\Features\SymbolSearch as suggested by one of the users in the original dev community ticket.

[JohnyL]

VS 16.4.0 - the problem still exists. None of suggestions did work.

[LuohuaRain]

I have the same problem too, vs 16.4.0

[mkamoski]

FYI, in Vs Pro 16.4.2 the problem persists.

-- Mark Kamoski

[imKnect]

16.4.5 Still.

[meesii]

16.5.2 Still.

[ghost]

I had the same thing too. Keeps trying, never finishes or takes really long ... it keeps the background activity icon to animate and because it never ends it breaks the purpose of that as well. Will try the latest versions later (in the middle of work)

[Eli-Black-Work]

I've disabled the "Suggest usings for types in NuGet packages" setting and also removed nuget.org from the Package Sources list, but I'm still seeing this message.

Should VS still be trying to reach out to nuget.org even if it's not in the Package Sources list? That is, can the IntelliSense index be downloaded from places other than nuget.org?

[sharwell]

@Bosch-Eli-Black It turns out the "Suggest usings for types in .NET Framework assemblies" feature also uses this index. Can you try disabling both of these options and see if it resolves the message?

[Eli-Black-Work]

@sharwell Ah, I see! I've now tried turning off both the "Suggest usings for types in NuGet packages" and "Suggest usings for types in .NET Framework assemblies" settings, and that seems to have fixed the issue!

Is there anything information that I can provide that might help with fixing this issue? I'm thinking that in my case, the problem is probably being caused by the fact that I'm behind a proxy.

[Otiel]

It seems that there are two existing workarounds:

• Set the registry key Enabled = 0 in HKCU\SOFTWARE\Microsoft\VisualStudio\16.0_xxxxxxxx\Roslyn\Features\SymbolSearch (and create if it doesn't exist).
• Or, disable the following in VS settings:
  • Suggest usings for types in .NET Framework assemblies
  • Suggest usings for types in NuGet packages

The question is: do both methods accomplish the same thing? What is really disabled when modifying the registry key?

[CyrusNajmabadi]

The question is: do both methods accomplish the same thing?

THey do not. While they both download and use the same index, the option determines which features the index powers. The first will offer to add reference to well known MS .net framework assemblies. The second will offer to add nuget references to popular nuget packages.

[Otiel]

@CyrusNajmabadi My question wasn't regarding the difference between both settings, but between the registry edit and unchecking both settings.

[CyrusNajmabadi]

The registry setting is undocumented and unsupported. I can't comment it as i do not want to convey any sort of contract or belief about what that key is or what impact it would have to change it at all.

[Eli-Black-Work]

Do we have a path forward to fix this?

[CyrusNajmabadi]

We'd need a repro to be able to investigate what is going on.

[Eli-Black-Work]

Okay. What kind of logs should I send you?

[jmarolf]

@Bosch-Eli-Black If you file a feedback ticket as per the directions here we will be able to see logs of what is happening.

[sharwell]

@CyrusNajmabadi I believe this is fairly easy to reproduce if you either work offline or block access to the site containing the database via a firewall.

[CyrusNajmabadi]

Ah yes. I imagine that if the connection is blocked. We will simply keep retrying indefinitely. One thing we coudl do it have some sort of decay on retry when that happens.

[sharwell]

@CyrusNajmabadi We do have a long delay between retries, but the status message remains visible during the delay. The status message essentially says "we don't have the necessary information to provide a requested feature", which is a permanent situation for some users. Ideally we'd have a way to allow users to disable the feature (either for the current session or permanently) directly from the status message.

[CyrusNajmabadi]

@CyrusNajmabadi We do have a long delay between retries, but the status message remains visible during the delay. The status message essentially says "we don't have the necessary information to provide a requested feature",

interesting. that seems unfortunate. we could have this dismiss more aggressively.

Ideally we'd have a way to allow users to disable the feature (either for the current session or permanently) directly from the status message.

That's an interesting idea. I wonder how possible that is. I'm worried about users not having visibility/understanding on what they're disabling.

--

Aside: this progress was added at the request of a partner team that said they really wanted to publicize that a nuget index was there to power IDE features. I'm highly skeptical that the progress bar actually adds any value. I would personally be ok with just removing it entirely (we would still keep our internal log in the logging system). I can check with the current members of the partner team to know if they still want this.

[Eli-Black-Work]

I see value in the progress indicator, because it signals to me that not all of VS's features are ready, so if something such as autocomplete doesn't work properly, I have an indication as to why.

If downloading the index fails, though, it would be nice if the progress indicator went away and instead there was just a message saying that the download had failed, with a little "See more" link going to an article saying why the download might have failed (e.g. firewall issues, proxy, etc.).

After the backoff period is over and VS tries to download the index again, I'd like to see the progress indicator again. Then when the download fails again, the error message should come back, etc.. This would be somewhat annoying for the user, but I think it would provide a more clear indication of what's going on, and it would still be less annoying than what happens currently :)

[sharwell]

Design review conclusion: the progress indicator is not providing value that outweighs the clear drawbacks. For now, disable this indicator altogether but do not otherwise change the behavior of the indexing/options system.

[zahirtezcan]

I have inspected the symbol search code of Roslyn myself and I found out that it downloads the index file from https://az700632.vo.msecnd.net/pub/RoslynNuGetSearch/Elfie_V1/Latest.xml which is a single element XML file where the element contains an attribute named "content"

"content" attribute contains the (1) deflated and (2) base-64 encoded of the so-called index as a string. I have added some pointers to the code for the resolution here.

Here is a sample code to download the xml and extract the index file for offline storage.

var element = XElement.Load(@"https://az700632.vo.msecnd.net/pub/RoslynNuGetSearch/Elfie_V1/Latest.xml");
var attribute = element.Attribute("content");
string base64 = attribute.Value;
byte[] deflated = Convert.FromBase64String(base64);
string localAppData = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);

using (var inmem = new MemoryStream(deflated))
using (var inflater = new DeflateStream(inmem, CompressionMode.Decompress))
//using (var outFile = File.Create(@$"{localAppData}\Microsoft\VisualStudio\16.0_eb78fb52\PackageCache\Format1\nuget.org.txt"))
using (var outFile = File.Create(@"nuget.org.txt"))
{
    inflater.CopyTo(outFile);
}

As a workaround I have copied the nuget.org.txt file into VisualStudio local settings directory under PackageCache\Format1 folder. VS local settings directory is under %LocalAppData%\Microsoft\VisualStudio\ and looks like 16.0_eb78fb52 with possibly different alphanumeric characters after 16.0_