-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Proposal: Components as micro-projects #8391
Comments
I chose to add this suggestion here even though this is not strictly a language design or Roslyn issue, and would require CLR changes. But a key purpose of this feature is to enhance the semantics of |
Enhancement Consideration 1Reduce the need to explicitly reference certain components The main project component automatically references its components without the need to explicitly reference them. (This, in turn, would make it impossible for internal components to reference back to the main project component.) Alternative: The main project component is automatically referenced by all its components without the need for explicit references. (This, in turn, would make it impossible for the main project component to reference any internal components.) |
Enhancement Consideration 2Remove the need to explicitly reference external project components Component references are only required for the same project. Any component from project A automatically references all components in project B. |
Enhancement Consideration 3Remove explicit references altogether No explicit referencing is needed. The compiler finds any dependency cycles between components, and creates an error condition when a dependency cycle is detected. Users are forced to fix the cycle before the project will compile. |
So this is some kind of IDE feature? That is what "micro-project" implies. Also, could you give some example and how this differs from #8302? |
The feature includes IDE updates, but goes beyond that by incorporating components as sub-level containers within the project file. This proposal is similar to #8302 except it does not contain any direct syntax changes for any language. It is meant to address some of the ideas provided in that thread. Here's an example. Say you have this existing project structure:
Now say you want to ensure that there is no circular dependencies between the pets and the pet store. Also, say that you don't want the Under this proposal we solve the problem while eliminating that overhead by using components. The compiler creates a single assembly. The existing folder/namespace structure could serve to delineate two new components:
There we go. Now PetStore can reference Cat, Dog, and Turtle but the opposite isn't true. And PetStore can't see the internals of the pets. |
Rather than explicit components and references, I would like to see top-down dependency of folders (like F#) but it'll be more of an IDE feature for C#, and I'm not sure how it will be better than something like #8302. Also, I don't like to change the meaning of |
This isn't changing the meaning of Folder dependency sounds like a potential solution (this proposal is a similar concept, and could be nearly identical given Enhancement Consideration 3) but wouldn't that break existing code? You would need to be explicit about separating components, which is what this issue proposes. |
We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages. |
This proposal is an alternative to the "module" design proposed in #8302.
Proposal
Implement the concept of a Component in the form a micro-project.
Background
I use the definition of "component" which is the same as that used in NDepend literature:
Also:
Components have some of the same guarantees as assemblies. Components may not form circular references with other components. Anything that is
internal
to a component may not be viewed from outside the component. Breaking down large assemblies into many small components is good practice for dependency management and encapsulation at a level higher than classes.Today, components are only conceptual. The assembly is the only level at which a component may be defined and enforced, short of using third-party products. If your goal is to have 1000 tiny, lean components then separating them into projects (assemblies) can make the build process orders of magnitude slower than building a large monolithic assembly. Plus managing all those projects and their configuration options can be overwhelming.
Solution
Components become realized as micro-projects which exist within regular projects. These micro-projects would appear in Visual Studio Solution Explorer inside (underneath) the projects containing them.
Component micro-projects have their own set of "Component References" which are conceptually identical to "Project References" today. Code within one component may only reference members of another component if the first component references the second. This eliminates dependency cycles between components.
Component micro-projects otherwise are no different from folders. They do not have project properties (other than, perhaps, denoting a default namespace). All project properties are defined in the main project.
The main project is also a component. Any code inside the main project is considered part of the main project component. The main project component would need to specify any components it references, including components inside the main project. Components within project A may only reference components in project B if A has a project reference to B.
Component micro-projects cannot be built separately and do not produce a separate assembly.
The text was updated successfully, but these errors were encountered: