El truco consiste en implementar un componente de infraestructura que llame al DependencyResolver.Current
de MVC, para que pueda registrar el ResourceProviderFactory
real usando su contenedor DI favorito.
Aquí es una clase tal que hará el truco:
public class MvcResourceProviderFactory : ResourceProviderFactory
{
public override IResourceProvider CreateGlobalResourceProvider(
string classKey)
{
return GetFactory().CreateGlobalResourceProvider(classKey);
}
public override IResourceProvider CreateLocalResourceProvider(
string virtualPath)
{
return GetFactory().CreateLocalResourceProvider(virtualPath);
}
private static ResourceProviderFactory GetFactory()
{
var resolver = DependencyResolver.Current;
var factory = resolver.GetService<ResourceProviderFactory>();
if (factory != null)
{
return factory;
}
throw new InvalidOperationException(string.Format(
"No {0} has been registered in the {1}.",
typeof(ResourceProviderFactory).FullName,
DependencyResolver.Current.GetType().FullName));
}
}
Esta clase puede ser configurado de la siguiente manera:
<globalization
resourceProviderFactoryType="MyApp.MvcResourceProviderFactory, MyApp"
enableClientBasedCulture="true" uiCulture="auto" culture="auto"
/>
Te di la respuesta correcta en esto, ya que responde a la pregunta. Estaba al tanto de este método de implementar lo que estaba buscando, pero estaba más interesado en si había un método alternativo para manejar la inyección de dependencia en lugar de utilizar lo anterior que estoy usando actualmente. – Trotts
He estado luchando con esto por un tiempo y el mejor enfoque que he encontrado, bueno o malo ... – retslig