-
-
Notifications
You must be signed in to change notification settings - Fork 38
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
getProjectInfo doesn't return framework references? #171
Comments
@baronfel From reading these docs it looks like we may need to add I'd imagine this means Ionide is resolving to default framework references when doing its analysis?? |
It seems to work in 6.0, this seems like a problem with 7.0 and different |
Could you send me an example? After adding a global.json for 6.0.400 I see this:
Same results for 6.0.302 |
I don't have any of the 7.0 installed. I've seen this kind of weird behavior when a new SDK on a different major version comes out (similar to when fsi wasn't working with different beta sdks if you recall that.)
|
Thanks, how did you execute the code, via 'fsi' or a new project? Maybe my use of fsi is causing drama. |
I did it via CLI and interactively, same results.
|
The curse of this entire project in a nutshell :) |
does this mean I have to uninstall vs2022 preview to get my neovim working?? |
We don't know what it means as of yet. Still in the hypothesis-generation and testing phase IMO. |
After adding net7.0 to the tfm for this project, I'm getting this error when running the tests for net 6.0
The toolpath I get for 6.0 and 7.0 is both:
Looking at older issues, i've come across dotnet/msbuild#5600 which feels oddly familiar to the problems that we're running into. |
I did end up building ProjInfo with FSAC. I got some "interesting" findings
|
Seems this may be related to a change in FSharp.Core. I posted an issue dotnet/fsharp#14250 for it. I'm unsure if we have to wait for an upstream fix or we there's anything we can do about it in the meantime. |
Well I just ended up following a thread dotnet/roslyn#19146 (comment) that talks about how to make sure that I'm gonna try to see how paired down a PR I can make for this. |
Such detective work, amazing! Resolving this will also allow us to get fsdocs support for F# 7 ready |
@TheAngryByrd you're talking about adding that target to the set of design time targets we evaluate, right? If so, I think this change should still (eventually) be made upstream as well - using 'normal' design time targets should be all that's required to invoke this target along the way. |
Ok, so thinking |
I'm not 100% sure, but we should be able to mimic the Roslyn Target dependencies here as much as possible when it comes to ref assemblies - I think doing so will help F# be similarly supported in all tooling that expects Roslyn-like behavior. |
For some reason I thought the results returned by
ProjectLoader.getProjectInfo
would include all the-r
references for all the .NET DLLs, e.g. in theOtherOptions
field. However I can't find these anywhere, and I don't know whyFor example consider this script
crackProject.fsx
:t.fsproj
:Results:
There are no
-r:
references to reference assemblies etc.@baronfel Do you know if this should be working? Is it the case that we're not actually evaluating the full set of referenced assemblies of something?
The text was updated successfully, but these errors were encountered: