Skip to content
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

Build is working in VS 2019, but failing using VS 2017 / .NET CLI / Rider #36282

Closed
vsfeedback opened this issue Jun 10, 2019 · 4 comments
Closed
Assignees
Labels
Area-Compilers Bug Developer Community The issue was originally reported on https://developercommunity.visualstudio.com Resolution-By Design The behavior reported in the issue matches the current design
Milestone

Comments

@vsfeedback
Copy link

VSF_TYPE_MARKDOWNI'm aware what kind of compiler is used in VS 2019. We have a situation, where build is failing on VS 2017 / .NET CLI / Rider, but is working fine on VS 2019. I have prepared a simple solution for "easy to reproduce" problem.

  1. Download Test.7z
  2. Unpack
  3. Build using:
    a) VS 2019 - will work
    b) VS 2017 - will fail
    c) Rider - will fail
    d) .NET CLI (dotnet build Test.sln)- will fail

With following errors:
>Build FAILED.
>Class1.cs(22,18): error CS0121: The call is ambiguous between the following methods or properties: 'AsyncResultExtensionsRightOperand.Ensure(Result, Func<Task<bool>>, string)' and 'ResultExtensions.Ensure(Result, Func<bool>, string)' [Test\ Test.csproj]
> 0 Warning(s)
> 1 Error(s)
>Time Elapsed 00:00:01.08

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/599156/build-is-working-in-vs-2019-but-failing-using-vs-2.html
VSTS ticketId: 911332

These are the original issue comments:

sygnowski.p on 6/7/2019, 05:29 AM (3 days ago): I've created a repository with example code in GitHub: https://github.com/sygnowskip/build-problem
Jeff Schwartz [MSFT] on 6/7/2019, 03:36 PM (2 days ago):

Thank you @sygnowski.p for the feedback and repro. I have a few additional questions... Are you seeing these all fail on the same machine or different machines? What version of the SDK are you using? (dotnet --list-sdks)

I gave your repro a try on 2.1.601 and the issue did not repro, but on 2.1.202 it did. Have you tried updating to the latest 2.1, or 2.2 version?

https://dotnet.microsoft.com/download/dotnet-core/2.1

Pawel Sygnowski on 6/7/2019, 11:28 PM (2 days ago):

I've tested it on two machines:

  • Windows 10 with following SDKs installed:
    2.1.300
    2.1.403
    2.1.500
    2.1.505
    2.1.700
    2.2.100
  • Mojave macOS with following SDKs installed:
    1.0.0-preview2-1-003177
    1.0.1
    2.0.0
    2.1.403
    2.1.505
    2.2.101
    2.2.107
And the same issue is on both of them (also, I've asked few of my friends to build this and they have the same issue, but I don't know which SDK's they have on their machines).

As you suggest, I've installed the newest available .NET Core SDK - 2.2.300.

I've tested it again using the newest SDK and the results are:

  • VS 2019 16.1.2 - build is working fine
  • Rider 2019.1.2 - build is working fine
  • .NET CLI - build is working fine
  • VS 2017 15.9.12 - build is still not working, with the same issue as above

Visual Studio Feedback System on 6/9/2019, 08:19 PM (17 hours ago):

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.

Jeff Schwartz [MSFT] on 6/10/2019, 09:01 AM (4 hours ago):

@Pawel Sygnowski thank you for all the details. I am glad to hear the latest SDK is working in all but VS 2017. This question may be better answered on https://github.com/dotnet/sdk. I am going to also move it to my colleague on the SDK team.

These are the original issue solutions:
(no solutions)

@agocke agocke added this to the 16.2 milestone Jun 10, 2019
@agocke
Copy link
Member

agocke commented Jun 10, 2019

@gafter It looks like the code at https://github.com/sygnowskip/build-problem produces an overload resolution ambiguity in C# 7.0, but succeeds in C# 7.3. I can't remember, did we intentionally improve betterness between 7.0/7.3? And should there be an error about language version requirements if a new tie-breaker is used?

@gafter
Copy link
Member

gafter commented Jun 12, 2019

See dotnet/csharplang#98. This looks like the one about the delegate return type. Since it is done in semantic analysis, it is not easy to produce a language version error. It would have to rebind the invocation under the new rules to know that it would work (not be ambiguous) that way. We didn't do that, so we don't give a language version error.

@jcouv jcouv added the Resolution-By Design The behavior reported in the issue matches the current design label Jun 19, 2019
@jcouv
Copy link
Member

jcouv commented Jun 19, 2019

@gafter It sounds like the observed behavior is by design. Good to close this issue then?

@jcouv jcouv modified the milestones: 16.2, 16.3 Jun 25, 2019
@jcouv jcouv assigned jcouv and gafter and unassigned jcouv Jul 12, 2019
@jcouv
Copy link
Member

jcouv commented Jul 12, 2019

@gafter It sounds like the observed behavior is by design. Good to close this issue then?

@gafter gafter closed this as completed Jul 12, 2019
@sharwell sharwell added the Developer Community The issue was originally reported on https://developercommunity.visualstudio.com label Nov 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Bug Developer Community The issue was originally reported on https://developercommunity.visualstudio.com Resolution-By Design The behavior reported in the issue matches the current design
Projects
None yet
Development

No branches or pull requests

5 participants