A user reported a bug in Maperitive – it throws
Castle.MicroKernel.Resolvers.DependencyResolverException: Could not resolve non-optional dependency for ‘Karta.DataSources.OsmFileMapDataSource’ (Karta.DataSources.OsmFileMapDataSource). Parameter ‘fileName’ type ‘System.String’
I tried to reproduce this behavior using a simple unit test, but I couldn’t, so I’m posting the actual code. This is where the exception occurs:
return windsorContainer.Resolve<OsmFileMapDataSource>();
And this is how OsmFileMapDataSource constructors look like:
public OsmFileMapDataSource(
string fileName,
IFileSystem fileSystem,
IMapDataLayerFactory layerFactory)
{
...
}
public OsmFileMapDataSource(IMapDataLayerFactory layerFactory)
{
...
}
Needless to say, both IFileSystem and IMapDataLayerFactory are registered in the container (IMapDataLayerFactory is registered as a typed factory, by the way). OsmFileMapDataSource is also registered as an implementation of itself. And I’m using version 2.1.0.6655 of the library.
What’s strange about this is that if I move the second constructor in front of the first one, the component is resolved without problems. I’m not sure if this is intended behavior, but I doubt the order of constructors should be a determining factor on how components are resolved.
But as I said, I couldn’t reproduce this behavior using a simplified test code, so I guess I should start debugging it instead.
