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

Fsharp projects change tracking #72

Merged
merged 7 commits into from
Oct 28, 2019

Conversation

IgorFedchenko
Copy link
Contributor

Close #69

This PR is based on currently waiting for merge #71 PR, so better to merge that one first.

Creating in draft state because test is added, but implementation is missing

@IgorFedchenko
Copy link
Contributor Author

@Aaronontheweb The issue here is that when Roslyn is loading solution with _workspace.OpenSolutionAsync(slnName, _progress, CancellationToken) it does not see .fsproj as a project in solution. In my test there are two projects, but after solution loading it is reporting only one project.
Will try to figure out why is that.

@IgorFedchenko
Copy link
Contributor Author

IgorFedchenko commented Oct 26, 2019

All right, so, at least on my machine, I am getting _workspace.Services.IsSupported(LanguageNames.FSharp) == false. But I am able to load F# projects in IDE of course.

Looking at some answers at StackOverflow it seems like Roslyn does not fully support F# - at least this is a possible reason of errors we have. I have added logging of solution loading errors (_workspace.WorkspaceFailed event), and initially it was saying that .fsproj is not assigned to any known language, and after explicit assigning to LanguageNames.FSharp it started giving F# is not supported error. With debugging of external sources, I can see that it is because there is no workspace.Services that are assigned to F#.

With that said, in this project we actually do not need to manipulate with F# itself - we only need to keep track of project graph and be able to detect project directories/imports.
That is why I used a small hack - assigned fsproj project extension to LanguageNames.CSharp. With this, it is loading project with no issues. This will also allow to assign .fs F# source code file changed to the right project - because now F# project will be recognized and source code files will be assigned to the project.

@Aaronontheweb what do you think about that? I have also tried to update Microsoft.CodeAnalysis.Workspaces.MSBuild nuget package version from 3.0.0 to 3.3.1 but it did not help. Neither I could find a way to register F# as a supported service (and link to SO answer above might explain that).

@IgorFedchenko IgorFedchenko marked this pull request as ready for review October 26, 2019 11:35
@Aaronontheweb
Copy link
Member

Looking at some answers at StackOverflow it seems like Roslyn does not fully support F# - at least this is a possible reason of errors we have. I have added logging of solution loading errors (_workspace.WorkspaceFailed event), and initially it was saying that .fsproj is not assigned to any known language, and after explicit assigning to LanguageNames.FSharp it started giving F# is not supported error. With debugging of external sources, I can see that it is because there is no workspace.Services that are assigned to F#.

That's annoying :( - not much we can do about the Roslyn tooling itself though.

With that said, in this project we actually do not need to manipulate with F# itself - we only need to keep track of project graph and be able to detect project directories/imports.
That is why I used a small hack - assigned fsproj project extension to LanguageNames.CSharp. With this, it is loading project with no issues. This will also allow to assign .fs F# source code file changed to the right project - because now F# project will be recognized and source code files will be assigned to the project.

I think your hack is fine for the time being - better than what we have today. But could you open an issue to do this the "right" way, registering F# as a service with Roslyn?

@Aaronontheweb
Copy link
Member

Also, looks like my merge conflict resolution may have broken the build here... Let me look at that

@Aaronontheweb Aaronontheweb force-pushed the fsharp-projects-tracking branch from ccce374 to 2ccc48b Compare October 28, 2019 17:10
@Aaronontheweb
Copy link
Member

Should have that fixed now - just rebased everything and tested it locally.

@Aaronontheweb Aaronontheweb merged commit 0cd8f96 into petabridge:dev Oct 28, 2019
@IgorFedchenko IgorFedchenko deleted the fsharp-projects-tracking branch October 28, 2019 19:11
@IgorFedchenko
Copy link
Contributor Author

But could you open an issue to do this the "right" way, registering F# as a service with Roslyn?

Sure, created issue for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Need to be able to detect changes in F# projects
2 participants