-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Implement #:ref directive for file-based apps
#53480
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
Merged
jjonescz
merged 21 commits into
dotnet:release/10.0.3xx
from
jjonescz:52532-ref-directive-2
Apr 15, 2026
Merged
Changes from all commits
Commits
Show all changes
21 commits
Select commit
Hold shift + click to select a range
5cd1676
Implement `#:ref` directive for file-based apps
jjonescz eb9f15e
Convert referenced projects too
jjonescz 35adfeb
Extend tests
jjonescz 23a7acb
Add experimental opt-in feature flag
jjonescz e598825
Document the feature in the spec
jjonescz fcd188d
Fixup API file
jjonescz b53cb29
Improve code
jjonescz c3195fc
Fail if target directory already exists
jjonescz 1f432b8
Convert all into subfolder and check duplicate target dirs
jjonescz 6cced48
Clarify docs
jjonescz 78aef61
Convert included items of referenced file-based libraries
jjonescz a0f6731
Merge branch 'release/10.0.3xx' into 52532-ref-directive-2
jjonescz 61485ca
Update incremental skill
jjonescz a881f53
Test combination of `#:ref` and `#:include`
jjonescz 4ac58e9
Keep OutputType default to Exe
jjonescz 459f033
Improve code
jjonescz 8cd613d
Extend a test
jjonescz a1b635c
Merge branch 'release/10.0.3xx' into 52532-ref-directive-2
jjonescz a6f0839
Fixup after merge
jjonescz 5b9635f
Avoid GC'ing referenced projects
jjonescz 2a40de3
Fixup tests after merge
jjonescz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
10 changes: 10 additions & 0 deletions
10
src/Cli/Microsoft.DotNet.FileBasedPrograms/xlf/FileBasedProgramsResources.cs.xlf
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
10 changes: 10 additions & 0 deletions
10
src/Cli/Microsoft.DotNet.FileBasedPrograms/xlf/FileBasedProgramsResources.de.xlf
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
10 changes: 10 additions & 0 deletions
10
src/Cli/Microsoft.DotNet.FileBasedPrograms/xlf/FileBasedProgramsResources.es.xlf
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While a "library FBA" might not have an "entry point", I think it should have a "main file".
We should be able to look at a file in isolation and realize it is specifically something which would be valid to reference via
#:ref.Otherwise, the editor is going to have to identify the closure of projects to load, by actually going ahead and loading every FBA it is able to discover, then examining all the targets of
#:refs within all those FBAs, and loading those recursively until we reach a stable state. I think this will be more costly to implement on the editor side.Also, I think this ambiguity would end up being passed on to users, who may struggled to determine whether something is the "main file" of a file-based library, when the file doesn't have a clear marker indicating that's what it is, rather than being some helper file which is meant to be
#:included in something.I would honestly consider requiring that "files referenced by
#:ref, start with either#!(to indicate they're also executable), or for example#:library(to say they're just libraries), and using that to ensure that "automatic discovery" finds them. This should make it so that the editor "just works" with such reference graphs.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we require they start with either
#!or have#:property OutputType=Librarysomewhere among the directives of the entry point file?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I lean a bit against this as it seems surprising for the directive to have different semantics here than in a props file, and for this property name in particular to have this effect.
I think while we are behind an experimental flag, we can ship command line support without a "main file marker". I think we'll have to have a separate conversation about how to cost/schedule editor support also, and possibly make a change to add/require this marker later.
Does that seem reasonable? Adding @phil-allen-msft for visibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think the core dotnet CLI part of the
#:refis given (it's just a way to specify<ProjectReference Include="file.cs"/>), so no reason to block that. But we may need some add-ons to improve the IDE experience (since we don't have solution files like normal projects do) - but that feels independent and we have the feature flag to avoid breaking changes.