Import Resolution on static/Shared Fields

Mar 16, 2009 at 5:18 PM
What are the rules regarding import resolutionon static/shared fields?

When is it done?
Are there reasons to avoid this technique? (which seems to work)

I know its a bit against the grain of immutable objects with singletons, but I want my MEF composition container avaialble to an object created via reflection. Currently I'm sticking the imported composition container somewhat randomly into a discovered class and then accessing this. That feels like a hack and I'm exploring using a static field in a "utility" static class instead.

Mar 17, 2009 at 3:52 AM
Do not rely on it - it's going away in future versions. Imports on static/shared fields and properties have a lot of problems (what if two containers have the static import - who wins?)

Can you provide more information on the 'object' created via reflection? Who's creating this guy, another Framework?
Mar 17, 2009 at 1:53 PM

First, I want to applaud the team for the ongoing openness on these issues. I can use other techniques.

The object is created via T4. T4 uses a rather arcane approach to managing directives, which is the most common mechanism for establishing a link between the outside world and the template (which is itself compiled/emitted code).  I would be quite happy to help get T4 natively work in a more practical manner. I’m releasing a free tool (AppVenture Community Generation Harness) to shield normal people from having to write a hundred lines of ugly code. In the short term, I need to make this work, but in the long term, I’ll be happy to help convince someone that it’s worth the time to MEF-ify the T4 engine. Unfortunately, the T4 engine is in the DSL team which has other things on its mind.