Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constructor arguments vary by alphabetical order #230

Closed
sebastienros opened this issue Jan 27, 2017 · 3 comments · Fixed by #269
Closed

Constructor arguments vary by alphabetical order #230

sebastienros opened this issue Jan 27, 2017 · 3 comments · Fixed by #269
Labels
Milestone

Comments

@sebastienros
Copy link
Contributor

When creating a proxy from two instances, the constructor that will be called with the two instances and the IInterceptor[] parameters will have its arguments vary alphabetically on the implemented interfaces, and won't match the expected order hence throwing a "couldn't find parameterless constructor" error.

Here is the repro:

using System;
using Castle.DynamicProxy;

namespace ConsoleApp4
{
    public class Program
    {
        private static readonly ProxyGenerator _proxyGenerator = new ProxyGenerator();

        public static void Main(string[] args)
        {
            var options = new ProxyGenerationOptions();
            options.AddMixinInstance(new Foo());
            options.AddMixinInstance(new Bar());
            var proxy = _proxyGenerator.CreateClassProxy(typeof(Foo), options);

            Console.WriteLine(proxy);
        }
    }

    public interface IFoo1
    {
    }

    public class Foo : IFoo1
    {
    }
    
    public interface IFoo2
    {
    }
    
    public class Bar : IFoo2
    {
    }
}

This will throw an exception. Now if you rename IFoo1 to IFoo3 which is alphabetically after IFoo2 the constructor won't be found (the order of the constructorArguments and the actual ctor method don't match anymore)

Environment: .NET Core 1.1 with Castle.Core 4.0.0

Maybe related to: #112

@jonorossi
Copy link
Member

Thanks @sebastienros for a detailed report and a pull request.

I don't think this is related to #112 as that incomplete issue makes no mention of using mixins which this defect is in.

@jonorossi
Copy link
Member

Thanks @sebastienros for the pull request, I've made my review comments and merged to master, this will be released in v4.1.

@sebastienros
Copy link
Contributor Author

OMG sorry, I completely lost track on it. Thanks for fixing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants