Type still loaded after unregistering XLL and clashing with new?

[tiaphatjf]

Hello,
We're running version 1.9, and we are seeing some weird exceptions when upgrading our addin by first unregistering the old DLL and registering the new DLL.

We get this when registering:

"Expression of type 'Pricing.Models.ExpiryKey' cannot be used for parameter of type 'Pricing.Models.ExpiryKey' (Parameter 'arguments[2]')"}
    Data: {System.Collections.ListDictionaryInternal}
    HResult: -2147024809
    HelpLink: null
    InnerException: null
    Message: "Expression of type 'Pricing.Models.ExpiryKey' cannot be used for parameter of type 'Pricing.Models.ExpiryKey' (Parameter 'arguments[2]')"
    ParamName: "arguments[2]"
    Source: "System.Linq.Expressions"
    StackTrace: "   
at System.Dynamic.Utils.ExpressionUtils.ValidateOneArgument(MethodBase method, ExpressionType nodeKind, Expression arguments, ParameterInfo pi, String methodParamName, String argumentParamName, Int32 index)\r\n   
at System.Dynamic.Utils.ExpressionUtils.ValidateArgumentTypes(MethodBase method, ExpressionType nodeKind, ReadOnlyCollection`1& arguments, String methodParamName)\r\n   
at System.Linq.Expressions.Expression.Invoke(Expression expression, IEnumerable`1 arguments)\r\n   
at ExcelDna.Registration.ParameterConversionRegistration.ApplyConversions(ExcelFunctionRegistration reg, List`1 paramsConversions, List`1 returnConversions)\r\n   
at Derivatives.Excel.Utilities.Addin.Register() in C:\\src\\excel-addin\\Derivatives.Excel.Utilities\\Addin.cs:line 55"
    TargetSite: {System.Linq.Expressions.Expression ValidateOneArgument(System.Reflection.MethodBase, System.Linq.Expressions.ExpressionType, System.Linq.Expressions.Expression, System.Reflection.ParameterInfo, System.String, System.String, Int32)

We have a ExpiryKey type with custom parameter converters.
We have Excel functions using this type.
For functions with less than 16 parameters, all good.

    [ExcelFunction(Name = "GetFwd")]
    public static object GetFwd(
        ExpiryKey expiry,
        IReadOnlyDictionary<string, object> priceDriver,
        object calendar,
        object valueDate)
    { }

For functions with more than 16 parameters, we get the exception above:

    [ExcelFunction(Name = "SearchStrikeWithDelta")]
    public static object SearchStrikeWithDelta(
        string callPut,
        ExpiryKey expiry,
        string underlying,
        string rateCurve,
        string mic,
        DateTime valueDate,
        object vols,
        object rates,
        object priceDriver,
        object calendar,
        double targetDelta,
        string deltaType,
        object borrowCurve,
        object dividends,
        object instrumentValuationParams,
        object instruments,
        object volEvents,
        object deliverableExpiry = null)
    { }

If I remove the ExpiryKey parameter, I still have a functions with more than 16 parameters but it gets registered successfully..
Strange.

Not sure if this has something to do with Expression.GetDelegateType which can only create delegate types with up to 16 parameters.

It seems like the old ExpiryKey type is still loaded and clashes with the new one... (although this type definition hasn't changed between old and new version).

We have hundreds of users so we can't change the signature of our functions unfortunately.

Thank you!

[govert]

I understand you're upgrading from v0.34 to v1.9, running under .NET Framework.
Are your problems only happening during the runtime upgrade, or are there also problems with the new v1.9 add-in from a fresh Excel start?

I can't recall the details of how the AppDomains are managed when reloading an add-in. If the reloaded (new) add-in gets loaded into the same AppDomain, you might well have the type clashes. That's one direction to investigate if the live reloading is the main problem.

If the problem is caused by the refactoring from ExcelDna.Registration to the extended registration approach that is in v1.9, then I'm not sure where the type conflict comes from. On the other hand, if the 16 parameter limitation is a new one that comes from the v1.9 registration rewriting code, then I'd consider it a bug we need to fix - it's certainly possible.

As a workaround to the 16 parameter story, and depending on how many functions you have that are affected, you could implement the parameter conversion yourself. So just change the signature of the ExcelFunction from ExpiryKey to string or object or whatever it is after the signature re-writing, and put in the type conversion in your function, maybe before calling the 'real' implementation.
From the Excel and user perspective, that would be 100% compatible, and lets you avoid the extended registration rewriting your function.

If you want to focus on understanding why the ExpiryKey is being loaded multiple times you might need to look at the .NET Fusion Logger "fuslogvw". It could be something like having a packed assembly with the type and having a loose assembly in the directory, so the same type (by name) is loaded from both.