-
Notifications
You must be signed in to change notification settings - Fork 1.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
Support for external project collections linking. Add object model re… #4673
Support for external project collections linking. Add object model re… #4673
Conversation
…moting API for MSBuild
…alprojects_squashed' into dev/svetkere/externalprojects_squashed
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 haven't made it through the full review, but let me dump what I do have before I check out for the long weekend.
Meta-comments so far:
- What are the rules we should follow in the future regarding the link when adding to or altering the public API surface? Is it something like "all public APIs of an object that implements
ILinkableObject
should use theLink
member? - Would it be possible to write a Roslyn analyzer to enforce those rules? We don't necessarily have to do this now but it might be nice to have the backstop.
src/Build/ObjectModelRemoting/ConstructionObjectLinks/ProjectTaskElementLink.cs
Outdated
Show resolved
Hide resolved
src/Build/ObjectModelRemoting/ConstructionObjectLinks/ProjectTaskElementLink.cs
Outdated
Show resolved
Hide resolved
src/Build.OM.UnitTests/ObjectModelRemoting/RemoteProjectsProviderMock/ExporterMock.cs
Outdated
Show resolved
Hide resolved
src/Build.OM.UnitTests/ObjectModelRemoting/RemoteProjectsProviderMock/ExporterMock.cs
Outdated
Show resolved
Hide resolved
src/Build.OM.UnitTests/ObjectModelRemoting/RemoteProjectsProviderMock/ExporterMock.cs
Outdated
Show resolved
Hide resolved
src/Build.OM.UnitTests/ObjectModelRemoting/Helpers/ViewValidation.evaluation.cs
Outdated
Show resolved
Hide resolved
src/Build.OM.UnitTests/ObjectModelRemoting/LInkedProjectCollection_Tests.cs
Outdated
Show resolved
Hide resolved
First, regarding how to manage “Link” layer when changing the MSBuild API going forward. That’s depend on the type of change, but basically the way I see it is this:
This might require a new methods or properties added to corresponding “Link” class, not necessarily exactly the same, but whatever is needed for exported to facilitate the new feature. The rule would be to add a new “virtual” (not abstract) method with a default implementation on the Link class. It is ok Implementation to be “throw new NotImplementException()”.
I personally don’t see it as high importance to make new API surface a “remote”-enabled right away. We should highly discourage usage of “back-door” aka GlobalProject collection access in general, and for legitimate usage it would always require a change in our external projects provider anyway, so as I see that “remoting” capability could be added later and only when actually needed (basically on Demand). As for analyzer. I personally am not familiar with the extend of Roslyn analyzers capabilities so I don’t know the answer for that question. |
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 don't think I have any major objections.
We're hoping to minimize use of this over time, right? How can we make sure we have appropriate telemetry/complaining about this so that VS extension authors feel some pressure to move to the VS APIs you'd rather they use?
src/Build.OM.UnitTests/ObjectModelRemoting/LInkedProjectCollection_Tests.cs
Outdated
Show resolved
Hide resolved
src/Build.OM.UnitTests/ObjectModelRemoting/LinkedEvaluationReadOnly_Tests.cs
Outdated
Show resolved
Hide resolved
My opinion is that we don't need to do anything different here. A holistic approach to discourage usage of GlobalProjectCollection is certainly welcome. |
As for proliferating the use of "Link" mechanism as a means to support (or even worse - extend and encourage) "backdoor" GPC access in VS - totally agree, I don't see any effort to optimize that as a positive, and we do need to deter people of using GPC instead. We must start with the bunch of rogue (lazy hack) features that exist in our VS code first before we ask customer not to do what we have already done :). Now, on the other side, it is possible we find a legitimately useful cases for the MSBuild remoting feature. For example a good candidate is offloading CPS non-default config (platforms) evaluation OOP and use the "Link" to facilitate the integration of results into CPS API ecosystem (which is very MSBuild based). This will help remove huge Memory burden while allow us to scale (parallelizing) the work similarly to what we get in OOP evaluation for CSProj. Since the official CPS api include MSBUild types, it is no other easy way around than using Link mechanism there (it is not backdoor in this case). Anyway I would prefer not to speculate too much on future possibilities now to much and focus on what we need at this moment. It is hard to predict how we end up really ... |
…alprojects_squashed' into dev/svetkere/externalprojects_squashed
Putting two operational modes (link vs real) in every
|
There are downsides on the above proposal:
Currently we do have ~80 places (roughly 80 lines of code) affected by this same pattern. Note that these are all very stable (and generally simple) public API (typically get/set) that are rarely changed (if at all). (50% of this is in ProjectRootElement. ) So IMO that is not a good trade-off, but it is you guys call here. I'll open a mail thread on that since it can be a significant work associated ... |
I'd appreciate a bit of documentation, e.g. adding something to /documentation. |
No description provided.