none
Different interpretation of interop type library member signature in OLE/COM-view and Visual Studio metadata-reflection - or else? RRS feed

  • Question

  • Background of the problem
    =========================
    We have a class and an enumerator in a type library, used for a while now. The relevant class/interface definitions - from OLE/COM ITypeLib viewer are
    coclass MyClass {
        [default] interface IMyClass;
        [default, source] dispinterface _IMyClassEvents;
    };

    interface IEnumMyClass : IUnknown {
        [id(0x60010000)]
        HRESULT Next(
                        [in] unsigned long n,
                        [out] IMyClass** ppMyClass,
                        [out, retval] unsigned long* pnFetched);
        [id(0x60010001)]
        HRESULT Skip([in] unsigned long nMyClass);
        [id(0x60010002)]
        HRESULT Reset();
        [id(0x60010003)]
        HRESULT Clone([out, retval] IEnumMyClass** ppEnum);
    };

    Now if we include this into our project and try to use the Next method then this is what we get from metadata discovery ("Go to definition")
        [TypeLibType(64)]
        [InterfaceType(1)]
        public interface IEnumMyClass
        {
            [DispId(1610678275)]
            IEnumMyClass Clone();
            [DispId(1610678272)]
            uint Next(uint n, out MyClass ppMyCLass);
            [DispId(1610678274)]
            void Reset();
            [DispId(1610678273)]
            void Skip(uint nMyCLass);
        }
    Note that the only difference is in the Next method, the metadata discovered in VS 2008/2010 is wrong, parameter type became MyClass instead of IMyClass at it was originally.
    OK, we can fix this by using MyClass variable and not IMyClass, so there is (actually was) a solution.
    [Actually I don't know which one is wrong - OLE/COM viewer or metadata discovery]

    Now a new interface was added to MyClass, called IMyClass2 and the new class/interface definitions are (only differences)
    coclass MyClass {
        interface IMyClass;
        [default] interface IMyClass2;
        [default, source] dispinterface _IMyClassEvents;
    };
    and exactly the same IEnumMyClass interface as it was.

    But, and here comes the real issue, the metadata definition is now right,
        [TypeLibType(64)]
        [InterfaceType(1)]
        public interface IEnumMyClass
        {
            [DispId(1610678275)]
            IEnumMyClass Clone();
            [DispId(1610678272)]
            uint Next(uint n, out IMyClass ppMyCLass);
            [DispId(1610678274)]
            void Reset();
            [DispId(1610678273)]
            void Skip(uint nMyCLass);
        }
    This means that our existing code (to fix the wrong metadata with using a class variable and not an interface variable) is broken, it will fail to compile.

    So there are a few questions here:
    1. Is the first - badly generated metadata for C# - is a bug or "feature"? If feature please explain why it is :)
    2. If it is a bug there is not much we can do -> goto 4.
    3. If it is a feature can it be fixed somehow force to generate the proper declaration for Next?
    4. What else can we do - apart from using reflection - to not break parallel integration of the type library and where it is used?
    [On parallel integration I mean that new typelib cannot be released because it will break the compilation of where it is used and
    using component cannot be released for the new IMyClass-use because it breaks compilation with the currently released typelib.]

    In a desparate attempt I already tried to use Object and dymamic (does not even compile) and faking the new (good) definition to be used when importing the reference to the type library, it throws an exception with the existing implementation.

    Worst case is that I implement it now with reflection and dynamic procedure call and later (when it is safe) I will remove this unnecessarily complex/confusing/etc code.

    All help is welcome! 

    Friday, July 13, 2012 3:22 PM

All replies

  • Hi Psel,

    Welcome to the MSDN Forum.

    This is a quick note to let you know, we are performing research on this thread, and we will update this thread as soon as possible when we get any update.

    Thank you for your patience.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, July 16, 2012 7:36 AM
    Moderator
  • I kind of solved the issue dynamic procedure call and extension method but I am still waiting for some good explanation on why the type-discovery went wrong (or why it is a feature)

    Monday, July 23, 2012 7:56 AM
  • Dear Customer,

    Your question falls into the paid support category which requires a more in-depth level of support.  
    Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone 

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Regards,
    Eric Yang
    Microsoft Online Community Support

    Tuesday, July 31, 2012 2:44 AM
  • I am completely puzzled on this answer. So we have to pay £200 to get a call-back and someone might read this post and might come up with some explanation. I had a bit different view on Microsoft support but if this question will not be investigated for free than it won't be. That's life!

    Tuesday, August 7, 2012 1:57 PM