Library Manager tool does not work on Visual Studio 2022

[LLIAMAH]

Is your feature request related to a problem? Please describe.

1. Create default Asp.NET CORE solution in Visual Studio 2022
2. Cleanup wwwroot/lib folders
3. Right-click -> Add-> Client-Side Library…
4. Selected package:

• “cdnjs”- you could type any values - like ‘jquery’ - they COULD be in the autocomplete list, but when you choose it - in text box shows value with version “jquery@3.6.1” but none files are possible to select don’t matter what you check “Include all library files” or “Choose specific files” - the - is empty. (tryied for “jquery”, “jquery-validation”, “bootstrap”, “twitter-bootstrap”. If you press “Install” instead - you’ll receive: “the name@version library could not be resolved by the “cdfnjs” provider”
  UPDATE: autocomplete has been lost - don't work since today (14.Sep.2022)
• “jsdelivr” - you could type any values - like ‘jquery’, and select from the list. In the content will be visible tree of folders/files, BUT, if you try to install them process will start to download files, but will not succeeded - see an attachment
• “unpkg” - same behavior as “cdnjs”

So it is impossible to Add-Client Libs via visual studio - cdnjs is not available at all, jsdelivr - cannot download full set of files - continuously fails.

Found this problem in last 2-3 weeks.

Errors tab shows the Code of Error: LIB010
I’ve checked the official reference: https://github.com/aspnet/LibraryManager/wiki/Error-codes
LibraryManager error codes final code number - LIB007

During search of solution tried to update:

• Microsoft.Web.LibraryManager.Build to 2.1.175 - successful
• Microsoft.Web.LibraryManager.Cli to 2.1.175 - FAILED, caus it is not compatible with net6.0

Describe the solution you'd like

Add-Client lib must add libs in "wwwroot" folder of the Asp.NET Core projects

Additional context

Tried solution described here
dotnet tool install -g Microsoft.Web.LibraryManager.Cli
Then go to the folder where libman.json is located and run:
libman cache clean
libman restore
It does not help!

Problem could be visible here in developer community

[jimmylewis]

Are you behind a proxy server by chance? If so, can you determine if the proxy server is blocking your requests?

[LLIAMAH]

Are you behind a proxy server by chance? If so, can you determine if the proxy server is blocking your requests?

I'm on the standalone PC without proxies.

[LLIAMAH]

Problem still existing on VS2022

Sequence of the commands and result

libman.json (left only one lib for test)

[V4A001]

RESOLVED it with changing project file to newer version:

I have same issue. I have a project of 2020 which I need to debug. I have errors on build:
1>Restore operation started...
1>libman.json : error LIB002: The "jquery@3.5.1" library could not be resolved by the "cdnjs" provider
1>libman.json : error LIB002: The "jquery-validation-unobtrusive@3.2.11" library could not be resolved by the "cdnjs" provider
1>libman.json : error LIB002: The "jquery-validate@1.19.2" library could not be resolved by the "cdnjs" provider
1>libman.json : error LIB002: The "datatables@1.10.21" library could not be resolved by the "cdnjs" provider

I did remove the libraries from www\lib and did install libman 2.1.175+29a28921bd.RR

My solution has multiple projects and to use libman clean/ restore I needed to move one directory folder up where my libman.json is located. Maybe that is the problem?

[LLIAMAH]

RESOLVED it with changing project file to newer version

What do you mean under this?

I did remove the libraries from www\lib and did install libman 2.1.175+29a28921bd.RR

• Removed libs from www\lib
• version of the libman just reinstalled: 2.1.175+29a28921bd.RR

Problem still exists.
SUrprise that even in GUI - I've no intellisense for the libraries as on screenshot. All files are empty.

[LLIAMAH]

Problem still existing on my base PC and not even raised on my laptop (same network configuration), even after VS updated to 17.4.0 version.
Any help?

[V4A001]

In the project file there are also dependencies. Those are pointing to the old version. Right click your project so that it is editable, and then change the versions. That helped for me.

[LLIAMAH]

Same version. Tried to change and restore back - still no results.

Problem is that it even does not show any libs in the list, when you typing project start letters....

[LLIAMAH]

Is it possible to get a guide "how to run this extension in debug?" somehow? To try to debug and understand what is going wrong?

[jimmylewis]

For debugging the VS extension, the steps should be:

1. git clone the repo
2. Open the LibraryManager.sln in VS (VS may prompt you to install any workloads or components if they're missing)
3. Set the startup project to the Microsoft.Web.LibraryManager.Vsix project
4. F5, or if you have multiple instances of VS installed, use the debugger dropdown to target a different instance of VS

This will launch the experimental instance of VS (intended for testing extensions, won't affect your main VS install).
If you get a build error that the VSIX version must be greater than what is currently installed (I forget the exact wording), you need to add an additional commit to increment the version.
git commit -m "version bump" --allow-empty should work, but please remove that empty commit if submitting a PR.

For the dotnet tool, you can also build from VS and set it as the startup project to F5, or launch it on the command line using dotnet libman.dll ... from the build output directory.

For the MSBuild tasks, you need to build them, then create a project that references your private build of the nuget package. To ease debugging, insert System.Diagnostics.Debugger.Launch(); in the task you want to debug.

There's a build.cmd script in the repo root that will build everything (.cmd implies it's for Windows only, but it's just a wrapper to call msbuild LibraryManager.sln with some other flags set by default).

This is lacking from the README but it's a good idea to put there. Feel free to submit a PR, or I'll add this to my todo list as soon as I have time.

[LLIAMAH]

Hi,
on this weekends I decide to investigate and have some results:

1. During process of debug I received an Exception on the: WebRequestHandler->GetStreamAsync(...): and InternalException shown me the reason of the problem -> The request was aborted: Could not create SSL/TLS secure channel.
2. I've checked Internet options (on PC, which HAS problem) and define that all TLS are switched on:
   
   on my laptop (on which LibMan working fine) TLS settings looks like:
   
3. Started to dig and found changes with which LibraryManager started to work. Please see the differences (4.) and code which required to "fix" problem (5.):
4. These changes allow LibMan to work even with "Use TLS 1.3 (experimental)" checked on (see details below)
   

private HttpClient CreateHttpClient(string url)
{
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AllwaysGoodCertificate);

#pragma warning disable CA2000 // Dispose objects before losing scope
    var httpMessageHandler = new HttpClientHandler();
#pragma warning restore CA2000 // Dispose objects before losing scope
    httpMessageHandler.Proxy = _proxySettings.GetProxy(new Uri(url));
    var httpClient = new HttpClient(httpMessageHandler);
    httpClient.DefaultRequestHeaders.UserAgent.ParseAdd($"LibraryManager/{ThisAssembly.AssemblyFileVersion}");

    return httpClient;
}

private static bool AllwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors)
{
    return true;
}

Results:

1. I understand that these security changes are "fast-fix" and they could harm general process - so it is up to you to add them or not, but I guess it helps you to investigate more and apply more adequate changes (and BTW - logs, cause logs are not containing info about SSL/TLS problems)
2. For fast solution w/o code changes: is required to open "Internet Options -> Advanced tab" and uncheck "Use TLS 1.3 (experimental)" - exactly this checkbox prevent the HttpClient working process (all others TLS checkboxes - could be switched on).
3. You could close this ticket with your comment. Hope my investigations was useful.

[jimmylewis]

@LLIAMAH Thanks for the write-up! Can you clarify a couple details?

1. If you change your settings on your PC to disable TLS 1.3 (experimental), does libman work without your modifications?
2. What version of Windows are you running? On mine (Win11 22H2), TLS 1.3 is not labeled as experimental, so I'm wondering if this issue only reproduces on an older version (which may have a bad implementation)

[LLIAMAH]

1. If you change your settings on your PC to disable TLS 1.3 (experimental), does libman work without your modifications?

Results - Nr.2 answer on this ;).
Yes, if you switch OFF only this checkbox "TLS 1.3 experimental" - all work fine without any code changes. Other TLS versions are not affect.

2. What version of Windows are you running? On mine (Win11 22H2), TLS 1.3 is not labeled as experimental, so I'm wondering if this issue only reproduces on an older version (which may have a bad implementation)

I don't have Win11 to check this :\

[LLIAMAH]

Found additional problem:
If "TLS 1.3 (Experimental)" unchecked - a lot of site certificates became "unsecured", which prevent general functionality.

So it is required to be fixed somehow.

[LLIAMAH]

Sorry for accidental closing - but it is required to resolve problem.

[LLIAMAH]

BTW it could be catched exception 'The request was aborted: Could not create SSL/TLS secure channel." (don't forget that it is Internal Exception) and applied retry with something like:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; // redefinition of the protocol to get data
var client = new HttpClient(new HttpClientHandler() { });
var res = AsyncHelper.RunSync(() => client.GetAsync("https://api.cdnjs.com/libraries"));
ServicePointManager.SecurityProtocol = SecurityProtocolType.SystemDefault; // restoring SystemDefault value

[LLIAMAH]

It it possible to know approximate date when will be some fix?

[jimmylewis]

I set up a VM with Windows 10, same build as yours, but I can't reproduce this issue yet after trying for several hours. I've tried every combination of TLS settings available in the Internet Options, but they all work fine for me with any libman provider. It's quite vexing that I can't reproduce the problems you're experiencing, whether with TLS 1.3, 1.2, or with older deprecated versions, so I'm having a hard time validating any potential solutions.

I'm wary of making a change to hard-code a TLS version, as everything older than TLS 1.2 is already deprecated for security issues - I'm sure it's only a matter of time before 1.2 is broken as well, which is why it's best to use the OS defaults, as those will be updated by OS security patches as needed. I'd recommend disabling the older versions off on your desktop as well, unless you frequent sites that don't support TLS 1.2.

[LLIAMAH]

I'm agree with you that it is bad decision to hardcode this thing, but isn't better to set try...catch block for AuthenticationFailed error?
I mean: try with high-level security cert, if failed - decrease on one step, then again. and only if TLS 1.1 or SSL 3.0 failed - return at last some log info - please contact admin cause your security system configured awful.

Cause info about problem - I didn't find in any log at all: BTW did some experiments with HttpClient and found that default (without properly configured handler) behavior return 4-levels Exception:
Exception: System.Net.Http.HttpRequestException: An error occurred while sending the request.
InnerException: System.IO.IOException: The read operation failed, see inner exception.
InnerException: System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
InnerException: System.ComponentModel.Win32Exception (0x80090326): The message received was unexpected or badly formatted.

But all this respond surrounded by the first one: An error occurred while sending the request - that's all.

[jimmylewis]

I don't think doing a manual backoff (reducing TLS versions) is useful outside of debugging. It can lead to other error states (for example, JSDelivr doesn't support anything below TLS 1.2, so a request with only 1.1 will fail to negotiate), and it's a security step I'm not willing to make at this time, not until we have a larger number of reports with this as a consistent issue.

Improving the logging is important and has come up a number of other times (such as in #601 and #697).

For now, I'd recommend that you uncheck the TLS 1.3 on your desktop since that was verified to work around the problem. I don't know why it causes problems for you but not for me on a similar machine.