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

Add "Install package" code fix #2873

Closed
Tracked by #15408
vasily-kirichenko opened this issue Apr 18, 2017 · 12 comments
Closed
Tracked by #15408

Add "Install package" code fix #2873

vasily-kirichenko opened this issue Apr 18, 2017 · 12 comments

Comments

@vasily-kirichenko
Copy link
Contributor

image

We could steal / use packages indexing logic from Roslyn sources.

@forki
Copy link
Contributor

forki commented Apr 18, 2017

Noooo. Please please please please let's not repeat that epic mistake. It will make dependency management even harder

@vasily-kirichenko
Copy link
Contributor Author

Why? It would use Paket of course, respect paket.references for the current project, etc. What's the problem?..

@forki
Copy link
Contributor

forki commented Apr 18, 2017 via email

@vasily-kirichenko
Copy link
Contributor Author

vasily-kirichenko commented Apr 18, 2017

Ah, no. If we will implement it, we implement it so that you and Paket are happy :)

@cartermp
Copy link
Contributor

cartermp commented Apr 18, 2017

cc @CyrusNajmabadi, who built this feature in VS 2017 (not to be confused with the feature in vs2015 for xproj only which was coupled to NuGet and wasn't very flexible)

There were some reasons why this was turned off by default for C#, part of which came down to needing to drop a new typeforwarding .dll. If this were to be built, and the C# feature turned on, then we'd have two on-launch downloads of a compressed database of symbols, two typeforwarding .dlls, and two mechanisms by which packages get added this way. Not ideal, and may end up suffering the scrutiny of VS shiproom.

I believe what was built depends on ISymbol based on quickly browsing the source. That may mean it's very difficult for us to use, if not impossible. Perhaps work could be contributed in Roslyn to make it usable by F#? I think the best approach is the following:

  1. Work to make the existing feature usable by F#
  2. Work to allow the existing feature to use Paket instead of NuGet if that's what the user would prefer

I don't know what either of those looks like, but I would guess it's a fair bit of work. Would love to see this in the IDE for F#, though.

@CyrusNajmabadi
Copy link
Member

@cartermp

There were some reasons why this was turned off by default for C#, part of which came down to needing to drop a new typeforwarding .dll.

I don't know what you're referring to.

--

Roslyn could certainly expose the API to get at the index information. Currently that exists in: https://github.com/dotnet/roslyn/blob/master/src/Workspaces/Core/Portable/SymbolSearch/ISymbolSearchService.cs

Making that avialable to F# definitely seems doable. It will still be up to you guys to hook it up to a lightbulb and to do whatever necessary when you actually invoke the lightbulb.

@vasily-kirichenko
Copy link
Contributor Author

@CyrusNajmabadi Yes, we need the index only. So we can import ISymbolSearchService and use it?

@CyrusNajmabadi
Copy link
Member

right now it's internal. do you have IVT? Note: we reserve the right to change this interface at any time. :)

@vasily-kirichenko
Copy link
Contributor Author

@CyrusNajmabadi we don't http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/GeneratedInternalsVisibleTo.cs :(((

We want to :) Is it possible to add FSharp.Editor assembly there?

@CyrusNajmabadi
Copy link
Member

I currently doubt it :) IVTs are a super high burden for us. They effectively open the door for any change becoming one that can break you.

Better would be a request for us to expose the ISymbolSearchService.

@forki
Copy link
Contributor

forki commented Apr 18, 2017 via email

@vasily-kirichenko
Copy link
Contributor Author

@forki what's wrong with it?

@psfinaki psfinaki added the Area-LangService-CodeFixes Code fixes associated with diagnostics label Jun 15, 2023
@psfinaki psfinaki mentioned this issue Jun 15, 2023
85 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants