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

Refactoring not visible in other projects of the solution until rebuild #586

Open
nkosi23 opened this issue Dec 14, 2023 · 2 comments
Open

Comments

@nkosi23
Copy link

nkosi23 commented Dec 14, 2023

Hello,

I have noticed that when working on a solution having multiple projects with - for example - the following dependency graph:

  • Project A has no dependency
  • Project B references project A
  • Project C references project A

Two annoying things happen:

  • If a type is refactored within project A, the changes are not visible in the other projects until project A is rebuilt. This means that intellisense does not reflect the changes which is quite annoying in terms of development workflow. I'd expect this behaviour if a compiled dll was referenced, not when a project (part of the solution with its source code) is referenced.
  • The refactoring is not applied to the other projects! For example, if a property name is modified in project A, the name is not updated in the other projects (therefore after project A is rebuilt to deal with the first issue, the builds of the other projects is broken)

This is definitely not what the development experience that solutions are supposed to offer (and as a matter of fact C#-based solutions do not have this issue).

I am running the following version of JetBrains Rider:

JetBrains Rider 2023.3
Build #RD-233.11799.261, built on December 4, 2023
Subscription is active until January 10, 2024.
Runtime version: 17.0.9+7-b1087.7 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 6.6.3-1-default
.NET Core v7.0.10 x64
GC: G1 Young Generation, G1 Old Generation
Memory: 4096M
Cores: 12
Registry:
editor.config.csharp.support=true
ide.experimental.ui=true
Current Desktop: KDE

@auduchinok
Copy link
Member

auduchinok commented Dec 26, 2023

@nkosi23 Thank you for writing about it and really sorry for the late reply!

This is definitely not expected behaviour in the most of the cases. Unfortunately, we don't see such behaviour in solutions that we use our F# support on, so it's likely something specific to your solution. Could you please share more info about these projects?

  1. Are all these projects F# ones?
  2. Are there any type providers used in project A? If yes, it may be this issue in F# compiler service that we use for parts of the analysis
  3. Does the issue exist for all symbols in project A, or only for some?
  4. Are there any signature files in the project A?

If there's a chance you could show a simplified repro solution (and if that's not the issue with type providers above), that could also help a lot.

@nkosi23
Copy link
Author

nkosi23 commented Apr 29, 2024

Sorry for the delay in my reply,

  1. Yes all projects are F# projects
  2. Mmh, yes this may be the case, I use the library SQLHydra which uses type providers behind he scenes if I am not mistaken :/ Thank you for the pointer.
  3. The issue affects all symbols that are not in the built binary. So if I have types T1, T2 at time H2, then build then add types T3 to my source code without building again, the other projects will only see types T1 and T2
  4. No I do not use any signature file

I will look into creating a repro !

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

No branches or pull requests

2 participants