Resolve caches object[] args values

[kirodge]

Hi,

I'm not sure if this is a issue or by design.
I am trying to create a ViewModel-factory

public class ViewModelFactory
{
        private readonly IResolver _resolver;
        public ViewModelFactory(IResolver resolver)
        {
            _resolver = resolver;
        }

        public T CreateViewModel<T>(params object[] args)
        {
            return (T)_resolver.Resolve(typeof(T), args);
        }
}

On the first call to CreateViewModel with a System.Guid as parameter

var editViewModel = _viewModelFactory.CreateViewModel<IEditViewModel>(guidId);

everything works as expected. The constructor of the registered EditViewModel is run with the provided guidId, and other parameters injected. However on a second call

var editViewModel = _viewModelFactory.CreateViewModel<IEditViewModel>(anotherGuidId);

the guid-value from the first call is injected to the constructor again.

It seems to me that DryIoc's Resolve caches object[] args values.
Is this intended?

I'm aware that I can use

var getter = _resolver.Resolve<Func<Guid,T>>();
getter(guidId)

but not all of my viewmodels require a guid as parameter. Some require no guid, some require two, and some might require other values only known at runtime.

Thanks for any advice

[dadhi]

@kirodge, Thanks for posting.

Yes, it is probably a cache, but it should not be there because of arguments. I will check.

[kirodge]

Thanks, I created a PR for testing the issue

[dadhi]

The fix is available in DryIoc v3.1.0-preview-03

[kirodge]

Thanks a lot for the quick fix @dadhi.
The issue is resolved in DryIoc v3.1.0-preview-03

[kirodge]

@dadhi Set milestone 3.1.0?

[dadhi]

yep.

[kirodge]

I would set milestone myself, if I was able to.

Any due date for 3.1?

[dadhi]

It will be a v4. Currently in a preview. Soonish I hope.

[Leszek-Kowalski]

This issue is a show stopper for my project as well.
Any timelines for v4 ?
Maybe it could be back-ported to 3.1 in the mean time ?
Thanks.

[dadhi]

V4 will be here soon. If you are watching the repo, you see that I am closing the last bugs.

Regarding back ports, I am open for PRs.

[rdeago]

EDIT: Actually, it appears to be another issue. Please see #105.

---

It appears that the issue is still there in v4.0.1.

I've prepared the tiniest use case I could come up with and placed it in a .NET fiddle.

Here's the code, for completeness:

// @nuget: DryIoc.dll -Version 4.0.1

using System;
using DryIoc;

public class Program
{
	public static void Main()
	{
		using (var container = new Container(ConfigureContainer))
		{
			container.Register<IAlpha, Alpha>();
			container.Register<IBravo, Bravo>();
			
			using (var scope = container.OpenScope())
			{
				Console.WriteLine("--- Scope #1");
				scope.ResolveNamed<IAlpha>("Alice");
				scope.ResolveNamed<IBravo>("Bob");
			}
			
			using (var scope = container.OpenScope())
			{
				Console.WriteLine("--- Scope #2");
				// I would expect the Container to throw on the following line,
				// because it doesn't know how to create an instance of Alpha.
				// Instead, it happily creates an Alpha named Bob!
				scope.ResolveNamed<IBravo>("Bob");
			}
		}
	}
	
	static Rules ConfigureContainer(Rules rules)
	{
		return rules
            .With(FactoryMethod.ConstructorWithResolvableArguments)
            .WithDefaultReuse(Reuse.ScopedOrSingleton);
	}
}

public static class ResolverExtensions
{
	public static TService ResolveNamed<TService>(this IResolver @this, string name)
	{
		return @this.Resolve<TService>(args: new object[] { name });
	}
}

public abstract class Service
{
	protected Service(string name)
	{
		Console.WriteLine("This is an instance of {0} called {1}.", GetType().Name, name);
	}
}

public interface IAlpha { }

public interface IBravo { }

public sealed class Alpha : Service, IAlpha
{
	public Alpha(string name)
		: base(name) { }
}

public sealed class Bravo : Service, IBravo
{
	public Bravo(string name, IAlpha alpha)
		: base(name) { }
}