-
Notifications
You must be signed in to change notification settings - Fork 685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why do you always fail to donwload with new version 2.0 #6004
Comments
Hi @heartacker can I assume based on the dialog you are in mainland China region? See microsoft/vscode-dotnettools#186 where we had one other report. We’ve been unable to reproduce this. |
i have install the runtime,why do you always try to down load again and again why not use the installed version |
@heartacker as a temporary workaround, would you be able to try setting the |
re @dibarbet 's comment: |
@dibarbet Your suggestion did not work for me, but it did lead me to a solution. In whichever settings file is appropriate for you "dotnetAcquisitionExtension.existingDotnetPath": [
{
"extensionId": "ms-dotnettools.csharp",
"path": "C:\\Program Files\\dotnet\\dotnet.exe"
}
] |
Hi @heartacker we've been checking with our edge delivery teams and we're just not seeing widespread indicators here. I know it's asking a lot but can you help provide us with more information so our network partners can troubleshoot some more? I appreciate it. Instructions:
We've additionally included steps on how to obtain a HAR/MTR below should the end user require assistance to the ask above. This information would help our team greatly towards our efforts in investigating the report. Below are the steps for collecting HAR/MTR HAR file : MTR: |
I have tried this "dotnetAcquisitionExtension.existingDotnetPath": [ |
The problem I'm having is that the installation is not completing due to group policy limiting PS1 file execution but even installing 7.0.9 runtime manually resolve the issue, it still attempts to install. Setting the path manually in the settings file causes the extension to basically disable. The omnisharp status and selected project do not appear in the status bar after setting the path. |
@cmargroff I wouldn't expect you to see specific OmniSharp status unless you've followed this: https://github.com/dotnet/vscode-csharp#how-to-use-omnisharp? |
Same problem here, I am having problem acquiring the .net version 7.0.9 in a proxied environment in a client, as I can not do anything besides opening a ticket to solve the proxy issue, I was trying to disable the Downloading of this new .Net Runtime version and use one of the versions I already have. But, setting the version using the latest one I have when I set in my "dotnetAcquisitionExtension.existingDotnetPath": [
{
"extensionId": "ms-dotnettools.csharp",
"path": "/home/user/.dotnet/dotnet"
}
] I receive the following output from the .Net Runtime:
And nothing happens, the extension stop to works. |
Can you share the output of the C# log (with the |
Thanks for the reply @dibarbet. Unfortunately, even with the following options in my "dotnetAcquisitionExtension.existingDotnetPath": [
{
"extensionId": "ms-dotnettools.csharp",
"path": "/home/user/.dotnet/dotnet"
}
]
"razor.trace": "Verbose",
"dotnet.server.trace": "Trace" I do not see any changes on the .Net runtime output:
|
@coderade Please attach the log that @dibarbet had suggested. The output is telling you that it is using your custom path, so it did change the behavior and output. The output you showed is not trying to acquire dotnet anymore. What is the problem you are experiencing? I'm guessing it may be an issue of the C# Extension to pick up this configured dotnet path if you are still experiencing an issue. |
@dibarbet #6029 (comment) |
@dibarbet even installing 7.0.9 runtime manually resolve the issue, it still attempts to download everytime. |
The server is currently fixed on the .net7 runtime. It is likely we'll eventually update it to the .net 8 runtime, but not on every preview release for example. Generally we will continue to (slowly) update the server runtime to pick up important bug fixes, perf improvements and security fixes. |
So the result is that if I don't choose to upgrade, this error will pop up every time I load cs project. |
I got rid of this by setting the "dotnet.dotnetPath": "/usr/local/share/dotnet", |
For me checking the logs it is working after setting: "dotnetAcquisitionExtension.existingDotnetPath": [
{
"extensionId": "ms-dotnettools.csharp",
"path": "/home/user/.dotnet/dotnet"
}
] Checking the |
@mi1890 (and anyone else who is interested) - we recently released a prerelease version of the extension that will attempt to use the dotnet version on your path (if it matches) instead of delegating to the runtime installer. You can get to it via the 'switch to pre-release' button here |
and i have tryed this as same result |
@mi1890 please also post the C# output window log (please set |
2023-08-16 01:31:29.265 [info] ExtensionService#_doActivateExtension ms-dotnettools.vscode-dotnet-runtime, startup: true, activationEvent: 'workspaceContains:/*.csproj', root cause: ms-dotnettools.csdevkit 2023-08-16 01:32:30.263 [info] ExtensionService#_doActivateExtension ms-dotnettools.vscode-dotnet-runtime, startup: true, activationEvent: 'workspaceContains:/.{csproj,sln,slnf,csx,cake}', root cause: ms-dotnettools.csharp only these logs are related |
dotnet runtime log: c# log: Dotnet path: /usr/local/share/dotnet/dotnet [Info - 01:32:32] [Program]Language server initialized c# devkit log: c# lsp trace log: [Trace - 01:32:32] Sending request 'workspace/diagnostic - (1)'. [Trace - 01:32:32] Received notification 'window/logMessage'. [Trace - 01:32:32] Received notification 'window/logMessage'. [Trace - 01:32:32] Received request 'client/registerCapability - (2)'. [Trace - 01:32:32] Sending response 'client/registerCapability - (2)'. Processing request took 0ms [Trace - 01:32:32] Received request 'workspace/configuration - (3)'. [Trace - 01:32:32] Sending response 'workspace/configuration - (3)'. Processing request took 2ms [Trace - 01:32:33] Received notification 'window/logMessage'. [Trace - 01:32:33] Received notification 'window/logMessage'. [Trace - 01:32:33] Received notification 'window/logMessage'. [Trace - 01:32:33] Received notification 'window/logMessage'. [Trace - 01:32:33] Received notification 'window/logMessage'. |
Thanks for the logs - they're helpful. So it looks like the C# extension is actually successfully using the I'm not sure why though the |
thanks for your reply and for the guys who cannot donwload success, |
Why not remove auto download feature and use the installed one? Maybe keep the install tool extension as a stand alone optional one for users who want auto download feature. |
Workaround described above doesn't work C# Output still shows:
but .NET Runtime is using correct version of dotnet
|
I think perhaps the SDK version and the Runtime versions are getting conflated... In my logs I have the following...
|
The workaround also does not work for me. I am on an 2019 Intel Macbook Pro. I have two sdks installed with the below
|
Thanks - this is #6167 and should be fixed in the next version we release. |
@coreyperkins
shows the server successfully finding a valid dotnet and starting - so we likely have a different problem here. Would you be able to file a new issue with some additional information? Particularly:
Particularly looking for the C# logs, Projects log, etc. because based on your symptoms it sounds like there was an issue loading the project. |
For those who are developing Unity games, you need to add local path to all Unity related extensions. For me they are :
then restart vscode |
I finally solved the downloading dotnet problem by this:
the three extensionId represent three extensions in vscode who depends on the .net install tool, the path is your .net sdk excutable file location, you can use |
for those who have no need for .NET Runtime? |
My mistake was exactly the same as yours, until the usr/local/bin/dotnet was removed and the unity extension worked fine. (This is a shortcut that is no longer valid) |
Closing - we've made a number of improvements to both the dotnet resolution and runtime download of dotnet since this was filed. If you're still having issues on the latest version of the extension, please file a new issue (with C# logs and general reproduction steps). |
Thank you dude. this is correct answer . |
The text was updated successfully, but these errors were encountered: