Haven't come across that issue myself - for the sake of my sanity I tend to incubate new views, component views etc. in the filesystem of the web project, and once happy, then move them into the appropriate plugin's assembly as an embedded resource (so I can easily hack away at them without recompiling while they're in flux) - regardless of their location they "just work".
Are you able to supply a full stack trace for the exception you're receiving... might give us some hints. On Tue, Mar 9, 2010 at 2:48 PM, Jan Limpens <[email protected]> wrote: > Very cool, that brought me quite a bit forward! > > I am just still having problems when my assembly loaded view references a > component that is in the filesystem of the project. > I am getting a view exception concerning ComponentDict and if i comment out > all component usages, the page renders. > > Any ideas? > > Muchas gracias, > Jan > > > > On Mon, Mar 8, 2010 at 7:02 PM, Alex Henderson <[email protected]>wrote: > >> Hi Jan, >> >> We have an application with plugins containing controllers, views as >> embedded resources etc. So I can say this all does work :) >> >> I believe you are using the wrong container - IViewSourceLoader is >> available from the Monorail container, rather then windsor... >> >> I would suggest implementing IMonoRailContainerEvents for your >> HttpApplication (Global.asax) - and then do something like: >> >> public void Initialized(IMonoRailContainer monorailContainer) >> { >> >> windsorContainer.Register(Component.For<IViewSourceLoader>().Instance(monorailContainer.ViewSourceLoader)) >> >> } >> >> so the service is available in your IoC container as well... >> >> BTW - If you need to support removing/disabling plugins at runtime as well >> (and removing their views) - you can do this by casting IViewSourceLoader >> to FileAssemblyViewSourceLoader, and then remove entries from the >> instance's AssemblySources collection. Bit of a hack, but it does the trick >> if you need that kind of functionality (like we did) - at some point I might >> submit a patch to expose a real "Remove" method on the IViewSourceLoader's >> interface. >> >> Also in your code you might wan't to check to see if a >> ControllerDetailsAttribute is associated with the controller type, in case >> it's name is different to it's type name. >> >> Cheers, >> >> - Alex >> >> >> On Sat, Mar 6, 2010 at 9:21 AM, Jan Limpens <[email protected]>wrote: >> >>> I want to be able to register controllers in a plug in fashion - so they >>> need to have their view files as embedded resources. >>> >>> Like hammett suggested it (in 2007) in this blog entry, I try to get to >>> the IViewSourceLoader(s) on first request (hackety-hack). >>> But my container always return null for that service, so I wonder if >>> things might have changed - for the better maybe... >>> >>> My code: >>> >>> private static void >>> addConfiguredControllersFromWebConfig(IWindsorContainer container) >>> { >>> >>> var config = ConfigurationManager.GetSection("adminConfig") >>> as AdminConfigSection; >>> if (config == null) >>> return; >>> >>> var tree = container.GetService<IControllerTree>(); >>> var loaders = container.ResolveAll<IViewSourceLoader>(); // >>> getting null here >>> >>> if (tree==null || loaders==null) >>> return; >>> >>> foreach (TypeConfigElement elm in config.Controllers) >>> { >>> var controllerName = elm.Type.Name.Replace("Controller", >>> string.Empty); >>> tree.AddController(string.Empty, controllerName, >>> elm.Type); >>> container >>> .Register(Component.For(elm.Type) >>> .Named(controllerName) >>> .LifeStyle.Transient); >>> >>> foreach (var loader in loaders) >>> { >>> var ns = elm.Type.Namespace.Replace(".Controllers", >>> ".Views"); >>> var info = new AssemblySourceInfo(elm.Type.Assembly, >>> ns); >>> loader.AddAssemblySource(info); >>> } >>> } >>> } >>> >>> any idea. also hint of how to do this with less code would be welcome :) >>> -- >>> Jan >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Castle Project Users" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<castle-project-users%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-users?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Users" group. >> To post to this group, send email to >> [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<castle-project-users%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/castle-project-users?hl=en. >> > > > > -- > Jan > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]<castle-project-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
