Codeactions with options/ui.

[savpek]

Resolves #1220

List:

• ChangeSignatureCodeAction
  • Todo: blacklist this, i don't think this is possible to impelement without UI...
• ExtractInterfaceCodeAction
• GenerateConstructorWithDialogCodeAction
• GenerateOverridesWithDialogCodeAction
• GenerateEqualsAndGetHashCodeWithDialogCodeAction
• GenerateTypeCodeActionWithOption
  • Blacklist. This don't give extra value over GenerateType (without options) which we have already. With default ui this ends up nearly identical class.
• PullMemberUpWithDialogCodeAction
  • This is bit trickier, may work OK if select first available parent interface as target.
  • Blacklist: Theres existing pull members up without dialog. Use that one and blacklist this, this is identical when used without UI.

There are some parts that are internal that are reguired to implement this feature. Pending issue on dotnet/roslyn#33277. This is written with reflection/proxy combination which should be replaced once roslyn issue is addressed.

GenerateConstructorWithDialogCodeAction, GenerateOverridesWithDialogCodeAction, GenerateEqualsAndGetHashCodeWithDialogCodeAction:

Extract interface:

However extract interface isn't available before this code is merged with #1076 since it's action for one of analysis.

[david-driscoll]

I'm going to focus on getting this and the related analyzers in right away.

[bjorkstromm]

Thanks for the PR. We probably want to avoid a dependency on Castle.Core. Take a look at MetadataHelper on how it's done there.

[bjorkstromm]

We probably want to avoid a dependency for Castle.Core?

[bjorkstromm]

To avoid a dependency on Castle.Core, you can have a look in MetadataHelper on how this could be done.

[savpek]

In metadata helper concrete internal type is created (if i am not missing something completly 😄) but this is bit trickier since concrete implementation of internal interface is created without existing concrete implementation. Implementation for IPickMembersService for is in visual studio libraries and not available.

However it think i can write solution based on https://stackoverflow.com/questions/8606412/create-type-that-implements-internal-interface which looks something like example there:

public class InterfaceImplementer : RealProxy, IRemotingTypeInfo
{
    readonly Type _type;
    readonly Func<MethodInfo, object> _callback;

    public InterfaceImplementer(Type type, Func<MethodInfo, object> callback) : base(type)
    {
        _callback = callback;
        _type = type;
    }

    public override IMessage Invoke(IMessage msg)
    {
        var call = msg as IMethodCallMessage;

        if (call == null)
            throw new NotSupportedException();

        var method = (MethodInfo)call.MethodBase;

        return new ReturnMessage(_callback(method), null, 0, call.LogicalCallContext, call);
    }

    public bool CanCastTo(Type fromType, object o) => fromType == _type;

    public string TypeName { get; set; }
}

Which doesn't look too bad to write and should remove requirement for castle.core depency.

[bjorkstromm]

@david-driscoll @filipw and @rchande, any opions on the above suggestion by @savpek? One problem is that neither RealProxy nor IRemotingTypeInfo is part of netstandard (according to https://apisof.net/)

[savpek]

I will try with DispatchProxy which seems to be part of net standard.

[david-driscoll]

One minor nit, otherwise we're good to go.

[savpek]

@david-driscoll can you point me to that minor nit, i don't find any comment or anything for it 🙂

[david-driscoll]

Looks like you fixed it 🎉

Review concerns were met

[filipw]

LGTM

[savpek]

@filipw @david-driscoll is anything holding this PR back at this point? Its bit burder to maintain PRs for extended period of time 🙂

[filipw]

sorry for the delay - this is good to go - thanks a lot for your hard work 👍