|
MEF allows decoupling of TypeA's dependency on TypeB, but now TypeA and TypeB have an assembly-level dependency on the MEF assemblies. If I have a specific restriction on deployment of the assemblies required by TypeBsuch that they mustbe signed with a specific key, for example, using attributes is out of the question because I can't deploy the assemblies that contain the Attribute classes.
As well, if I have a type in an existing assembly with a property that I could "export", if that's a 3rd party assembly where I don't have the source to add an Export attribute, how can I wire up that type+member to be used as a component?
Please offer a way to define the logical relationships of types without having introduce new dependencies and modify existing source code. Ideally this would include both a way to do it with XML configuration and in code. This is very common for other IoC and DI containers.
Cheers -- Peter
http://www.peterRitchie.com/blog- Edited byPeter RitchieMVPThursday, June 05, 2008 3:19 PMdetail
-
| | Peter Ritchie | Peter, Welcome. ;) Using the [Import] and [Export] attributes to define your inputs and outputs is what we are calling the 'default' programming model. That is, if you were in a green field scenario, and were starting from scratch, then this is the model we would encourage most applications adopt. In fact this model is exactly what Visual Studio and a few other applications coming out of Microsoft will be using as the basis of their extensibility models going forward. The new dependency onComponentModel.dll is a point well taken, however, youshouldn't have too many problems deploying the assembly if it signed with the Microsoft key and already exists in the Framework. ;) Brown field scenarios, or where you just want to use Plain Old CLR Objects (POCO)and avoid 'dirtying' your types with attributes, is a scenario that we plan on supporting. We know that today, we are not exactly where we want to be in six months with regards to extensibility. However, in saying that, we doalready provide some hooks to support this today in the CompositionContainer. For example, customers can create their own custom resolver (by deriving ValueResolver), which probes a configuration file for available components, and feeds instances of a ComponentBinder (which provides the mechanism for providing exports and for setting imports) into the CompositionContainer. CompositionContainer has a constructor that takes a resolver as an argument- simply pass the custom resolver via that. We don't yet provide any samples that do this, but expect some to appear on the team members blogs in the coming weeks (see the Managed Extensibility Framework Blogs and Resourcesannouncement at the top of the forum for links). We're also looking at what scenarios we will support out of the box; we'vealready heard from the community a lot, that the external manifest (whether that be a configuration file, database, code or some other form) is something that they want to see supported, and as such, is something that isdefinitely on our radar. Regards David
Managed Extensibility Framework Team | My Blog: http://davesbox.com - Edited byDavid M. KeanMSFT, OwnerThursday, June 05, 2008 5:25 PMFixed up a couple of typos
- Proposed As Answer byDavid M. KeanMSFT, OwnerThursday, June 05, 2008 11:51 PM
- Marked As Answer byPeter RitchieMVPFriday, June 06, 2008 2:48 PM
- Edited byDavid M. KeanMSFT, OwnerThursday, June 05, 2008 8:49 PMclafication
-
| | David M. Kean | Peter, Welcome. ;) Using the [Import] and [Export] attributes to define your inputs and outputs is what we are calling the 'default' programming model. That is, if you were in a green field scenario, and were starting from scratch, then this is the model we would encourage most applications adopt. In fact this model is exactly what Visual Studio and a few other applications coming out of Microsoft will be using as the basis of their extensibility models going forward. The new dependency onComponentModel.dll is a point well taken, however, youshouldn't have too many problems deploying the assembly if it signed with the Microsoft key and already exists in the Framework. ;) Brown field scenarios, or where you just want to use Plain Old CLR Objects (POCO)and avoid 'dirtying' your types with attributes, is a scenario that we plan on supporting. We know that today, we are not exactly where we want to be in six months with regards to extensibility. However, in saying that, we doalready provide some hooks to support this today in the CompositionContainer. For example, customers can create their own custom resolver (by deriving ValueResolver), which probes a configuration file for available components, and feeds instances of a ComponentBinder (which provides the mechanism for providing exports and for setting imports) into the CompositionContainer. CompositionContainer has a constructor that takes a resolver as an argument- simply pass the custom resolver via that. We don't yet provide any samples that do this, but expect some to appear on the team members blogs in the coming weeks (see the Managed Extensibility Framework Blogs and Resourcesannouncement at the top of the forum for links). We're also looking at what scenarios we will support out of the box; we'vealready heard from the community a lot, that the external manifest (whether that be a configuration file, database, code or some other form) is something that they want to see supported, and as such, is something that isdefinitely on our radar. Regards David
Managed Extensibility Framework Team | My Blog: http://davesbox.com - Edited byDavid M. KeanMSFT, OwnerThursday, June 05, 2008 5:25 PMFixed up a couple of typos
- Proposed As Answer byDavid M. KeanMSFT, OwnerThursday, June 05, 2008 11:51 PM
- Marked As Answer byPeter RitchieMVPFriday, June 06, 2008 2:48 PM
- Edited byDavid M. KeanMSFT, OwnerThursday, June 05, 2008 8:49 PMclafication
-
| | David M. Kean | +1 for config based option
::Rajiv | | thothful |
Peter,
Welcome. ;)
Using the [Import] and [Export] attributes to define your inputs and outputs is what we are calling the 'default' programming model. That is, if you were in a green field scenario, and were starting from scratch, then this is the model we would encourage most applications adopt. In fact this model is exactly what Visual Studio and a few other applications coming out of Microsoft will be using as the basis of their extensibility models going forward.
The new dependency onComponentModel.dll is a point well taken, however, youshouldn't have too many problems deploying the assembly if it signed with the Microsoft key and already exists in the Framework. ;)
Brown field scenarios, or where you just want to use Plain Old CLR Objects (POCO)and avoid 'dirtying' your types with attributes, is a scenario that we plan on supporting. We know that today, we are not exactly where we want to be in six months with regards to extensibility. However, in saying that, we doalready provide some hooks to support this today in the CompositionContainer.
For example, customers can create their own custom resolver (by deriving ValueResolver), which probes a configuration file for available components, and feeds instances of a ComponentBinder (which provides the mechanism for providing exports and for setting imports) into the CompositionContainer. CompositionContainer has a constructor that takes a resolver as an argument- simply pass the custom resolver via that.
We don't yet provide any samples that do this, but expect some to appear on the team members blogs in the coming weeks (see the Managed Extensibility Framework Blogs and Resourcesannouncement at the top of the forum for links).
We're also looking at what scenarios we will support out of the box; we'vealready heard from the community a lot, that the external manifest (whether that be a configuration file, database, code or some other form) is something that they want to see supported, and as such, is something that isdefinitely on our radar.
Regards
David
Managed Extensibility Framework Team | My Blog: http://davesbox.com
That's what I wanted to hear:-). Looking forward to the updates.
http://www.peterRitchie.com/blog | | Peter Ritchie | Imho there should also be out of the box tooling support for these files like we have for enterprise library blocks (and not in unity). | | Sidar Ok | Hey Peter
Is that signing issue relevant if the attributes you are using ship as acore part of the framework itself?
Glenn
Glenn Block - Program Manager - MEF | | Glenn Block [MSFT] |
Hey Peter
Is that signing issue relevant if the attributes you are using ship as acore part of the framework itself?
Hi Glenn. If MEF is part of the Framework and deployment of it isn't a responsibility of the application, signing isn't an issue (assuming it uses the same key as the rest of the framework).
http://www.peterRitchie.com/blog | | Peter Ritchie |
|
index > Managed Extensibility Framework > No "hard dependancy" but a new dependancy is introduced.