November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
That is not true, Episerver now supports abstraction of DI, and structuremap is just one implementation. You can use other DI frameworks but that would be more work for you.
Well that is great news, Quan Mai. I knew it was coming, but is it now officially supported?
I know that I can create a new ServiceLocator class (the reason I wrote that it can be done). But can you elaborate on how to remove StructureMap from the solution? Cause I see a hard dependency from Episerver NuGet's towards the Episerver.ServiceLocation.StructureMap package, and Visual Studio is complaining about those when I try to remove the abstraction package.
Alternatively, with StructureMap still being there, how can I make sure that the StructureMap resolver is not used at all? It seems that it is loaded quite early on startup.
It's a different thing actually. Some of the packages might have hard depedencies on Episerver.ServiceLocation.StructureMap because we need it to work right out of the box (and structuremap is the default implementation so it gets an unfair treatment).
However unless I'm mistaken there is nothing prevents you from writing an implementation for Castle windsor or AutoFac. The framework only cares about the abstraction, so as long as you provide an implementation for your DI framework of choice it should just work. (but leave structuremap there because that's how nuget packages work)
I was guessing it could not be entirely removed. One of those depending packages happen to be Episerver.CMS, which makes it impractial to fully remove.
You are not mistaken. What I was basically asking: can I tell Episerver to use whatever custom IServiceLocatorFactory
implementation I make? That is, if I would like the framework to ignore StructureMap and use mine. Otherwise, wouldn't it create and use the default StructureMapServiceLocator
implementation before it finds the custom implementation?
If you decorate your assembly with ServiceLocatorFactoryAttribute it should be enough for the framework to use your factory. Now this is a tricky part: you can't remove the nuget package because of dependency, but there is no dependency in code so if you make sure Episerver.ServiceLocation.StructureMap.dll does not copy to bin folder you should be.
Disclaimer: I haven't done it myself. The answers in this thread is based on my understanding of how things should work. I have high trust on my colleagues in CMS Core team (to have made things right), however.
Thank you for explaining this, Quan. Much appreciated.
I will not apply this to an existing project; only researching this for now. But it may be usable for a new project.
this is actually what (and how) it's happening - https://blog.tech-fellow.net/2018/12/01/episerver-init-infrastructure-under-the-hood/#servicelocatorprovider
Hello,
I want to use Castle Windsor dependency injection instead of Structure map. I want to do that because our organization has a common framework for all projects uses same cross-cutting pattern. is there any way I can replace structure map with Castle Windsor?