Roslyn: Solution containing F# and C# projects break some C# tooling, even if projects are not referencing each other
Version Used: 15.6, 15.7.4, 15.8 preview 4
Steps to Reproduce:
- Create new solution
- Create a C# project and a F# project
- Try to perform a rename operation in C# and watch it not work
Expected Behavior:
Rename should properly rename when pressing Enter.
Actual Behavior:
Nothing happens when pressing Enter on rename.
--
This isn't specific to rename, there are other issues when trying to do F12 navigation.
This is directly related to this: https://github.com/Microsoft/visualfsharp/issues/4796#issuecomment-404344061
Quoting from the issue here:
After investigation in the case of using rename for a type in C#, Roslyn will iterate over all projects to try to find that type. When it hits a F# project, it will throw because it is trying to get a ISyntaxFactsService from our language service which we don't have and never will. https://github.com/dotnet/roslyn/blob/master/src/Workspaces/Core/Portable/FindSymbols/FindReferences/DependentTypeFinder_ProjectIndex.cs#L55
When that throws, it will cancel C#'s rename task and nothing works.
I don't think this is a regression, or at least a very recent one. Most of the code paths to get to this point haven't changed from 11 months to 2 years.
This also occurs even if the C# project isn't referenced or is referencing a F# project.
TIHan
All 40 comments
Seems like this could have been introduced in the following commit:
https://github.com/dotnet/roslyn/commit/95a2444883741b61d44385d9bb7040ba33778ca3#diff-cae35fdca4a58c14603b4de0661109bbR606
and the previous default behaviour was to ignore case:
https://github.com/dotnet/roslyn/commit/95a2444883741b61d44385d9bb7040ba33778ca3#diff-cae35fdca4a58c14603b4de0661109bbL729
dgchurchill
on 13 Jul 2018
Indeed, that path does look bad. My attempts to reproduce this internally are currently being thrwarted by a worse bug that means creating a C# project prevents F# projects from being loaded.
jasonmalinowski
on 17 Jul 2018
Fixed by #28789 (tracing back to Rename refactor crashes)
davidagross
on 16 Aug 2018
@jasonmalinowski, @davidagross
Is this in 15.8.0? I'm still observing the issues.
- Activating Refactor Rename on a symbol does nothing.
- Ctrl+F12 Go To Implementation also doesn't work.
I can confirm that unloading the F# project from the solution fixes the problem. So it looks to be the same root issue.
On the upside, activating the commands hasn't crashed Visual Studio so far...
rlreis90
on 17 Aug 2018
@rlreis90 Which exact version are you running from Help > About? We did fix some of these, but there was also another bug we fixed which has the symptoms you're describing.
It's also possible there's still more bugs here, which wouldn't surprise me.
jasonmalinowski
on 17 Aug 2018
I am running
Microsoft Visual Studio Community 2017
Version 15.8.0
VisualStudio.15.Release/15.8.0+28010.0
Microsoft .NET Framework
Version 4.7.02558
Installed Version: Community
I am finding that Ctrl+. or Ctrl+R, Ctrl+R renames are successful now, without unloading my F# projects from the mixed C#/F# solutions, whereas in 15.7.3 a rename attempt would literally crash VS literally every time.
With Ctrl+F12 I do however still get this if my F# projects are loaded, and I don't get it if they are unloaded:
Activity log entry:
<entry>
<record>856</record>
<time>2018/08/18 09:15:39.386</time>
<type>Error</type>
<source>Editor or Editor Extension</source>
<description>System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> System.NullReferenceException: Object reference not set to an instance of an object.
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.ProjectIndex.<CreateIndexAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
 --- End of inner exception stack trace ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<AddSourceTypesInProjectAsync>d__29.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesInProjectAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<>c__DisplayClass9_0.<<FindTypesFromCacheOrComputeAsync>b__0>d.MoveNext()
 --- End of inner exception stack trace ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesFromCacheOrComputeAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.SymbolFinder.<FindOverridesAsync>d__39.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.SymbolFinder.<FindOverridesAsync>d__38.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.FindUsagesHelpers.<FindImplementationsWorkerAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.FindUsagesHelpers.<FindImplementationsAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.FindUsagesHelpers.<FindImplementationsAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.AbstractFindUsagesService.<FindImplementationsAsync>d__0.MoveNext()
 --- End of inner exception stack trace ---
 at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
 at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
 at Microsoft.CodeAnalysis.Editor.GoToImplementation.GoToImplementationCommandHandler.StreamingGoToImplementation(Document document, Int32 caretPosition, IFindUsagesService findUsagesService, IStreamingFindUsagesPresenter streamingPresenter, CancellationToken cancellationToken, String& messageToShow)
 at Microsoft.CodeAnalysis.Editor.GoToImplementation.GoToImplementationCommandHandler.ExecuteCommand(Document document, Int32 caretPosition, IFindUsagesService streamingService, CommandExecutionContext context)
 at Microsoft.CodeAnalysis.Editor.GoToImplementation.GoToImplementationCommandHandler.ExecuteCommand(GoToImplementationCommandArgs args, CommandExecutionContext context)
 at Microsoft.VisualStudio.Commanding.CommandHandlerExtensions.ExecuteCommand[T](ICommandHandler commandHandler, T args, Action nextCommandHandler, CommandExecutionContext executionContext)
 at Microsoft.VisualStudio.UI.Text.Commanding.Implementation.EditorCommandHandlerService.<>c__DisplayClass14_1`1.<Execute>b__1()
 at Microsoft.VisualStudio.Text.Utilities.GuardedOperations.CallExtensionPoint(Object errorSource, Action call, Predicate`1 exceptionFilter)
---> (Inner Exception #0) System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> System.NullReferenceException: Object reference not set to an instance of an object.
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.ProjectIndex.<CreateIndexAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
 --- End of inner exception stack trace ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<AddSourceTypesInProjectAsync>d__29.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesInProjectAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<>c__DisplayClass9_0.<<FindTypesFromCacheOrComputeAsync>b__0>d.MoveNext()
 --- End of inner exception stack trace ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesFromCacheOrComputeAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.SymbolFinder.<FindOverridesAsync>d__39.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.SymbolFinder.<FindOverridesAsync>d__38.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.FindUsagesHelpers.<FindImplementationsWorkerAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.FindUsagesHelpers.<FindImplementationsAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.FindUsagesHelpers.<FindImplementationsAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.Editor.FindUsages.AbstractFindUsagesService.<FindImplementationsAsync>d__0.MoveNext()
---> (Inner Exception #0) System.AggregateException: One or more errors occurred. ---> System.NullReferenceException: Object reference not set to an instance of an object.
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.ProjectIndex.<CreateIndexAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
 --- End of inner exception stack trace ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<AddSourceTypesInProjectAsync>d__29.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesInProjectAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<FindTypesAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.<>c__DisplayClass9_0.<<FindTypesFromCacheOrComputeAsync>b__0>d.MoveNext()
---> (Inner Exception #0) System.NullReferenceException: Object reference not set to an instance of an object.
 at Microsoft.CodeAnalysis.FindSymbols.DependentTypeFinder.ProjectIndex.<CreateIndexAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)<---
<---
<---
</description>
</entry>
Ach, I just ran into a Ctrl+R, Ctrl+R rename that hangs (it's search doesn't complete) but executes just fine after unloading the F# project in the mixed solution. I wonder why it was different from the other renames that worked...
davidagross
on 18 Aug 2018
@jasonmalinowski I'm running 15.8.1 atm, same status.
I did get the same "This may be caused by an extension" popup as @davidagross.
Rename hasn't made the UI hang or crash for me so far (it did previously), but it simply does nothing; it doesn't highlight the text in green, nothing.
rlreis90
on 19 Aug 2018
@rlreis90, words mean things and I should have been precise: VS doesn't hang but the search window in Ctrl+R, Ctrl+R doesn't find any of the instances, as if its search process hangs, though VS is otherwise still responsive.
davidagross
on 19 Aug 2018
@davidagross renaming local variables or private members always worked, just public renaming had/has issues.
@rlreis90 it crashed only if you try to rename a public member which is used by the F# binary.
JanWosnitza
on 20 Aug 2018
I have had the same problems mentioned is this issue with the latest versions of Visual Studio. My solution contains both C# and F# projects, and Rename and "Find all references" on public members are not working. I have rolled my Visual Studio back to version 15.4.5, which is the latest version of VS that does not have these problems. So I guess the issue has been introduced with the release of version 15.5.
epsen
on 21 Aug 2018
Just updated to latest version and now some symbols aren't even loading anymore (editor time). F12 doesn't work on them & Error List marks them as errors.
rlreis90
on 20 Sep 2018
@TIHan Are we still getting reports of issues like this?
jasonmalinowski
on 26 Nov 2018
@jasonmalinowski, I have just testet my Solution in Visual Studio 2017 15.9.2, and it is still the same problem: My solution contains both C# and F# projects, and Rename and "Find all references" on public members are not working. I have rolled my Visual Studio back to version 15.4.5, which is the latest version of VS that does not have these problems. So I guess the issue has been introduced with the release of version 15.5.
epsen
on 27 Nov 2018
Yes, it's still broken. Here is a (maybe not complete) list, both for Rename and Find All References:
What | Private | Public
--- | --- | ---
Type | ✔️ | ✔️
Field | ✔️ | ✔️
Property | ✔️ | ❌
Event | ✔️ | ❌
Function | ✔️ | ❌
Microsoft Visual Studio Professional 2017
Version 15.9.2
Installed Extension | Version
--- | ---
Visual F# Tools | 15.8.20181029.1
Visual F# Templates | 15.8.20181029.1
Visual Studio 2017 Tools for Unity | 3.9.0.2
Microsoft Visual Studio Test Platform | 15.9.0.2018100802
Roslyn Expression Evaluators | 2.10.0.6350103
Roslyn Interactive Components | 2.10.0.6350103
Roslyn Language Services | 2.10.0.6350103
Productivity Power Tools 2017/2019 | 16.0
CodeMaid | 10.5.119
Dotnet Extensions for Test Explorer | 15.3.0.10
ProjectConfigurationmanager | 1.7.1099
PS: But VS doesn't crash any more 👍
JanWosnitza
on 4 Dec 2018
@JanWosnitza Can you clarify whwat you mean by 'broken' here? Thanks!
CyrusNajmabadi
on 4 Dec 2018
Hi @CyrusNajmabadi, with broken I mean the following:
Rename
When renaming a public property/event/function using Visual Studio's refactoring tools: It starts the renaming process. I can change the name. But when hitting RETURN to accept the new name it's not renaming.
_(here was a gif to showcase the problem, but it's not available anymore)_
Find All References
_Find All References_ opens the Find All References window but does not show any references except the one where you started the search for and the progress-bar never finishes.
_(here was a gif to showcase the problem, but it's not available anymore)_
Repoduction
I also noticed, that indeed it works when the C# project is not referenced by any F# project now. Thus I tried to reproduce the bug in a small solution:
- Create a C# library project
- Create an F# console project
- add C# library to references of F# console
- Rename or find references
You can download my test solution here: Test.zip
JanWosnitza
on 5 Dec 2018
I've also encounter a problem with the rename dialogue which may have bearing on the others reported here.
_I end up here as this is other issues reported to do with Rename are closed off as duplicates of this issue. Though this one does seem to be a more specific case._
This is for Visual Studio 2017 15.9.3
Problem
- Buttons on Rename Dialog failed to respond including shutting it down using Title Bar buttons.
- Dialog appearance became corrupted if resized.
Reproducing Problem (maybe)
- I selected an Enum field and renamed then also selected to rename any strings, comments, and preview changes (I wanted to know where the strings and comments where changed.)
- While examining what renames would be done in the Rename Dialog I clicked inside the preview window. (No real reason for doing this.)
- After this the problem described above occurred.
- I shutdown Visual Studio by killing the process in Task Manager.
- Once restarted the rename operation had been completed.
_Screen shot of corrupted Rename Dialog_
AlanCarlyle
on 9 Dec 2018
If you can't reproduce or require more information, don't hesitate to ask :)
JanWosnitza
on 18 Dec 2018
Open mixed solution in VS 15.9.4
Rebuild All succeeds
Position cursor on interface name in .cs file (single implementation is in some .fs file)
Right click - Go to Implementation
An exception has been encountered. This may be caused by an extension.
You can get more information by examining the file '.....ActivityLog.xml'.
petarrepac
on 20 Dec 2018
I started VS with devenv /Log, tried to rename the property, but in the file ActivityLog.xml are no errors reported.
JanWosnitza
on 24 Dec 2018
Is this issue still alive? I'm waiting for the bugfix for one and a half year now. 😀
JanWosnitza
on 17 Jun 2019
you are lucky. We are waiting for fix more than 2 years. Looks like F# is no longer evolving ...
Droni
on 17 Jun 2019
@jasonmalinowski, I see this getting pushed again and again. Is it too big of a task or is it just not important enough? It sure is a big pain for my team and probably many others. Really looking forward to see this resolved! 🙂
veloek
on 24 Sep 2019
I see this getting pushed again and again. Is it too big of a task or is it just not important enough
Can you clarify. Is the issue that there are legitimate bugs where the product just breaks when you try to do things? i.e. you try to do a rename, and simply nothing happens (probably because something crashed internally), as opposed to just C# or just F# performing the rename.
Or is the issue that there are feature requests for C# and F# to work better? For example, that you'd like to be able to more easily jump between languages, or have a rename in one language reflected in the other.
I'm a bit lost as to what the current state is here. Thanks!
Note: if hte issue is that things are broken, it's likely the case that F# should drive investigations into finding out what's up there and pushing for the relevant fixes. If the issue is better feature support between the languages, that is certainly being looked into (for example: https://github.com/dotnet/roslyn/pull/33723) but it is a large and complex space, and Roslyn is a project with thousands of issues and hundreds of PRs for the team to get through. If you'd like to help contribute time/PRs here, that would likely be super helpful.
CyrusNajmabadi
on 24 Sep 2019
@CyrusNajmabadi, the IDE is throwing an exception when I'm trying to jump to implementation (ctrl+f12) in a mixed C#/F# solution. I don't have the stack trace/log file in front of me, but I can provide it tomorrow if that would help solve the issue.
It's not a feature request, but an annoying bug that has been around for years now. I was excited when I first search around for this bug and noticed it was assigned to a milestone, but seeing how it's just pushed forward, I've almost lost hope.
Let me know if I can be of further assistance. I don't think I would have the spear time to dig deep enough into this issue to solve it and make a PR myself, so I'm hoping I can somehow bump it up the list of prioritized tasks.
veloek
on 24 Sep 2019
@CyrusNajmabadi, the IDE is throwing an exception when I'm trying to jump to implementation (ctrl+f12) in a mixed C#/F# solution. I don't have the stack trace/log file in front of me, but I can provide it tomorrow if that would help solve the issue.
Would definitely be helpful. Note: the original post says this:
After investigation in the case of using rename for a type in C#, Roslyn will iterate over all projects to try to find that type. When it hits a F# project, it will throw because it is trying to get a ISyntaxFactsService from our language service which we don't have and never will.
People def seem to care deeply about this. My recommendation would be to just open a PR that fixes this.
CyrusNajmabadi
on 24 Sep 2019
I have a fix for the rename crash.
CyrusNajmabadi
on 25 Sep 2019
@CyrusNajmabadi
it looks strange. I have reported the issue with steps to reproduce:
VS Community
GitHub
But my issue has marked as duplicated. Now we see that this issue maked as fixed, but my the initial problem still reproducible. Looks like the nature of the problem was not researched by the man which mark issues as duplicate.
Droni
on 25 Sep 2019
@CyrusNajmabadi, the stack trace I'm seeing is the same as in @davidagross's comment. There's a nullref exception being thrown somewhere. I'm working on putting together a minimal solution that can be used to reproduce the issue.
veloek
on 25 Sep 2019
@CyrusNajmabadi, there is a zip attached to https://github.com/dotnet/roslyn/issues/28474#issuecomment-444447681 with a VS solution already setup and if follow the repro steps at that same comment, you should see that e.g. renaming doesn't work.
JanWosnitza
on 26 Sep 2019
@veloek @JanWosnitza Yes. I opened a fix for this a couple of days ago: https://github.com/dotnet/roslyn/pull/38841
Cheers!
CyrusNajmabadi
on 26 Sep 2019
🎈 Is this real life? 🎉 #MadeMyYear 👌
(even though it might be too early:) Thanks a lot!
JanWosnitza
on 27 Sep 2019
Fix is merged, and should be in 16.4 Preview 3.
jasonmalinowski
on 3 Oct 2019
And @veloek my apologies for punting the bug a few times from one release to the next. This bug was on my plate as the "we should get to it" and the invariably some last minute things always resulted in it getting punted. Asking about it was absolutely 100% the right thing to do since "customers are complaining" is always the easiest way to prioritize something higher!
jasonmalinowski
on 3 Oct 2019
@jasonmalinowski, yeah I was hoping a friendly nudge would bump it up the list of prioritized tasks :slightly_smiling_face:
veloek
on 3 Oct 2019
VS 16.4 Preview 3 is out and I can confirm that "go to implementation" now works! A day of celebration! 🎉
veloek
on 5 Nov 2019
Hmm.... It is interesting solution. Now the project reference to F# project looks like a reference to assembly. As result you can not rename members which are using in both projects.
Find all references feature show code from the F# project as metadata. Good work! It looks like F# buried by Microsoft.
Droni
on 5 Nov 2019
@Droni can you file a new issue about this. I don't believe any of my changes shoudl have had that sort of effect. Thanks!
CyrusNajmabadi
on 5 Nov 2019
@CyrusNajmabadi Sure. The project reference to F# project looks as assembly reference 16.4.0 Preview 3.0
Droni
on 6 Nov 2019
Related issues
binki
·
3Comments
marler8997
·
3Comments
orthoxerox
·
3Comments
glennblock
·
3Comments
MadsTorgersen
·
3Comments
Most helpful comment
@jasonmalinowski, I see this getting pushed again and again. Is it too big of a task or is it just not important enough? It sure is a big pain for my team and probably many others. Really looking forward to see this resolved! 🙂