Why have mono-6.4.0/msbuild-16.3.0 become a hard requirement? I am trying to use Omnisharp on a platform having mono6.8 available, but not having a readily available build of msbuild >= 16.3.0 (the only available version is msbuild15).

Since the task of upgrading the msbuild port does not appear to be trivial, as an alternative I am trying to assess the impact of patching Omnisharp to remove the hard requirement on msbuild 16.3.0 (and if this would be possible at all).

It is not a hard requirement, OmniSharp ships with its own bundled MSBuild as well, however if global Mono is available, it is attempted to be used because it will have reference assemblies for desktop .NET, which the bundled one doesn't.

The reason why lowest version of Mono MSBuild is what it is, is because of requirements in .NET Core - e.g. 3.1 requires MSBuiild 16.3 and 5.0 requires 16.8.

You can disable the discovery of global Mono and global MSBuild by adding an omnisharp.json file to the root of your project with the content

{
   "msbuild": {
       "useBundledOnly": true
   }
}

This will work for loading .NET Core projects, for loading desktop .NET the reference assemblies from global Mono are required so you will need to upgrade global Mono.

Why have mono-6.4.0/msbuild-16.3.0 become a hard requirement? I am trying to use Omnisharp on a platform having mono6.8 available, but not having a readily available build of msbuild >= 16.3.0 (the only available version is msbuild15).

Since the task of upgrading the msbuild port does not appear to be trivial, as an alternative I am trying to assess the impact of patching Omnisharp to remove the hard requirement on msbuild 16.3.0 (and if this would be possible at all).

Yes, it contains omnisharp server timeout only. Maybe I send the log later.

@peter7764 Does the OmniSharp log only contain a timeout or is there information before that? Without a log there is very little we can do to help.

It starts with time out. I extended the time but no hope.

VS Code commands are limited to only being able to have a single output. We will handle having an empty processId and show the dialog for ProcessPicker in resolveDebugConfigurationWithSubstitutedVariables. We need multiple outputs to handle the latest macOS on Apple M1.

For Apple Silicon M1 (ARM64), we need to determine if we need to use the x86_64 or arm64 debugger. We are able to detect if the process is using S_TRANSLATED using the ps commandline with 'flags', if it is set with 0x20000, it is emulated.

@ferenczy I agree we need to improve this dialog. The Restore button runs a restore for the entire solution, so we only need to display at most one popup.

@peter7764 Can you provide the OmniSharp log from the VS Code output pane?

Bumps System.Text.Encodings.Web from 4.7.1 to 4.7.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dotnet/corefx/releases">System.Text.Encodings.Web's releases</a>.</em></p> <blockquote> <h2>.NET Core 2.1.0 RC1</h2> <ul> <li><a href="https://github.com/dotnet/core/blob/master/release-notes/2.1/Preview/2.1.0-rc1.md">Release Notes</a></li> <li><a href="https://github.com/dotnet/core/blob/master/release-notes/2.1/Preview/2.1.0-rc1-known-issues.md">Known Issues</a></li> <li><a href="https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.1.0-rc1-download.md">Download and Install</a></li> </ul> <h2>Repos</h2> <ul> <li><a href="https://github.com/dotnet/coreclr/releases/tag/v2.1-rc1">CoreCLR</a></li> <li><a href="https://github.com/dotnet/corefx/releases/tag/v2.1-rc1">CoreFX</a></li> <li><a href="https://github.com/dotnet/core-setup/releases/tag/v2.1-rc1">Core-Setup</a></li> <li><a href="https://github.com/dotnet/cli/releases/tag/v2.1.300-rc1-008673">CLI</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/dotnet/corefx/commits">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

This worked for me but a couple of gotchas:

• After enabling the Roslyn Analyzers you have to restart vsc or restart Omnisharp
• The "Add missing cases" only shows up for me if my ticker is just before the s in switch and default: is within the brackets already. If the switch is empty { } it wont work.

Issue Description

When I open a .NET solution that doesn't have restored dependencies yet, the C# extension sometimes generates multiple identical notifications with the text "There are unresolved dependencies. Please execute the restore command to continue." and the Restore button, see below:

I'm guessing that it happens when there're multiple projects and each notification references one of those projects, but there's no way how to recognize that and how to identify what notification references what project.

It would be great if the notification contains some identifier (a project name) to help with that.

Steps to Reproduce

1. Open a .NET solution containing multiple projects with dependencies you don't have already downloaded (restored)
2. The C# extension generates multiple identical notifications

Expected Behavior

There's some identifier to recognize what project notification references.

Actual Behavior

The notification contains just generic text.

Environment information

VSCode version: 1.55.1 C# Extension: 1.23.11

<details><summary>Dotnet Information</summary> .NET SDK (reflecting any global.json): Version: 5.0.201 Commit: a09bd5c86c

Runtime Environment: OS Name: Windows OS Version: 10.0.19042 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\5.0.201\

Host (useful for support): Version: 5.0.4 Commit: f27d337295

.NET SDKs installed: 2.1.811 [C:\Program Files\dotnet\sdk] 3.1.404 [C:\Program Files\dotnet\sdk] 5.0.100 [C:\Program Files\dotnet\sdk] 5.0.201 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.All 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs: https://aka.ms/dotnet-download </details> <details><summary>Visual Studio Code Extensions</summary>

</details>

<!-- This issue template is for use in opening issues that document breaking changes. This template should be used to create an issue by Microsoft product team members who are documenting a breaking change.

Bracketed text is a placeholder; replace the text with the requested information and remove the brackets before submitting the issue. Also, remove this comment before submitting the issue.

-->

[New Use middleware overload, can cause compiler errors if you don't call next]

A new overload of app.Use has been introduced. If you were previously using app.Use but never calling the next middleware, you will now get a compiler error (CS0121). If that's the case you should use app.Run instead of app.Use.

Version introduced

ASP.NET Core 6.0-preview4

Old behavior

app.Use(async (context, next) =>
{
    await next();
});

or

app.Use(async (context, next) =>
{
    await SomeAsyncWork();
    // next never called
});

New behavior

app.Use(async (context, next) =>
{
    await next(context);
});

Notice that you can now pass context to the next delegate.

app.Run(async (context) =>
{
    await SomeAsyncWork();
    // next never called
});

Use app.Run when your middleware never calls next, otherwise you will get a compile error: CS0121 The call is ambiguous between the following methods or properties: 'UseExtensions.Use(IApplicationBuilder, Func<HttpContext, Func, Task>)' and 'UseExtensions.Use(IApplicationBuilder, Func<HttpContext, RequestDelegate, Task>)'

Reason for change

The previous Use method would allocate 2 objects per request. The new overload avoids these allocations with a small change to how you invoke the next middleware.

Recommended action

If you get a compile error, it means you are calling app.Use without using the next delegate. Switch to app.Run to fix the error.

Category

ASP.NET

Affected APIs

Not detectable via API analysis

<!-- Do not modify anything below this line -->

Issue metadata

• Issue type: breaking-change

Environment data

dotnet --info output:

.NET SDK (reflecting any global.json):
 Version:   5.0.202
 Commit:    db7cc87d51

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.202/

Host (useful for support):
  Version: 5.0.5
  Commit:  561d6ea60d

.NET SDKs installed:
  5.0.202 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

VS Code version:

Version: 1.55.2
Commit: 3c4e3df9e89829dce27b7b5c24508306b151f30d
Date: 2021-04-13T09:37:02.931Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Linux x64 5.10.31-1-lts

C# Extension version:

Name: C#
Id: ms-dotnettools.csharp
Description: C# for Visual Studio Code (powered by OmniSharp).
Version: 1.23.11
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp

Steps to reproduce

1. Create .NET5 API project
2. Go to WeatherForecastController.cs
3. Press F12 on WeatherForecast
4. No reference shown & no reference suggestion

Sure, but that seems rare, and if you want to do it, seems like processName would make more sense than processId. The only reason I can think to of using processId is if you are on an image without ps (or with a ps that acts differently than we expect).

I believe this will be addressed by https://github.com/OmniSharp/omnisharp-vscode/pull/4509

I also had the same thought, if users wanted to override it themselves then they would most likely investigate the options in launch.json and set it themselves.

"processId": ""

What do you think about removing it entirely instead?

Tested: