Skip to content

Support generic imports.#717

Draft
weltkante wants to merge 3 commits into
microsoft:mainfrom
weltkante:work
Draft

Support generic imports.#717
weltkante wants to merge 3 commits into
microsoft:mainfrom
weltkante:work

Conversation

@weltkante

Copy link
Copy Markdown

Fixes #457

As mentioned, mostly AI generated. The approach makes sense to me. I left the original generated comments intact during cleanup since they might help understanding during review, if further cleanup or other refactoring is desired let me know and I'll work on that. If the approach isn't desireable thats fine too, I just wanted to get this is out of my backlog ;)

@weltkante

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree

@AArnott AArnott left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sharing this. I think it's shaping up.

Comment thread test/Microsoft.VisualStudio.Composition.Tests/GenericImportTests.cs
Comment thread src/Microsoft.VisualStudio.Composition/ReflectionHelpers.cs Outdated
Comment on lines +34 to +38
export such as `[Export(typeof(IOptionsFactory<>))]`. VS MEF supports this for the direct import and
for the `Lazy<T>`, `ExportFactory<T>`, and `ImportMany` (`IEnumerable<T>` / `T[]`) forms.

Importing a type parameter *directly* — where the import type is the bare parameter itself, e.g.
`[Import] T` — is honored by .NET MEF and NuGet MEF but **not** by VS MEF. Those runtimes resolve

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the doc a little confusing.

VS MEF supports this for the direct import and for the Lazy<T>

This makes it sound like importing T ("direct import") and Lazy<T> is allowed. But then in the next paragraph you say T can't be directly imported.
And then you say nothing about Lazy<T> not being importable, but I strongly suspect Lazy<T> cannot be imported, since that would have the same ambiguous graph impact as importing T, right?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I double checked (to make sure there's no bug hidden) but this just was confusing wording that slipped through my review. Lazy/ExportFactory/IEnumerable/Array are just the expected special-cased variants in addition over the direct import, but of course with the same constraints as the direct import. I'd probably just drop the explicit enumeration of alternatives and leave it with the initial example?

Suggested change
export such as `[Export(typeof(IOptionsFactory<>))]`. VS MEF supports this for the direct import and
for the `Lazy<T>`, `ExportFactory<T>`, and `ImportMany` (`IEnumerable<T>` / `T[]`) forms.
Importing a type parameter *directly* — where the import type is the bare parameter itself, e.g.
`[Import] T` — is honored by .NET MEF and NuGet MEF but **not** by VS MEF. Those runtimes resolve
export such as `[Export(typeof(IOptionsFactory<>))]`.
Importing a type parameter *directly* — where the import type is the bare parameter itself, e.g.
`[Import] T` — is honored by .NET MEF and NuGet MEF but **not** by VS MEF. Those runtimes resolve

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

Successfully merging this pull request may close these issues.

Support generic imports (GenericHost/Options DI)

2 participants