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

Port FxCop rule CA1405: ComVisibleTypeBaseTypesShouldBeComVisible #421

Open
Tracked by #61964
ghost opened this issue Nov 21, 2015 · 3 comments
Open
Tracked by #61964

Port FxCop rule CA1405: ComVisibleTypeBaseTypesShouldBeComVisible #421

ghost opened this issue Nov 21, 2015 · 3 comments
Labels
Approved-Rule Indicates if the new proposed rule has been approved to move to implementation phase FxCop-Port help wanted The issue is up-for-grabs, and can be claimed by commenting Priority:3 Nice to have (suitable for disabled by default rules and ported FxCop rules)
Milestone

Comments

@ghost
Copy link

ghost commented Nov 21, 2015

Title: COM visible type base types should be ComVisible

Description:

When a COM visible type adds members in a new version, it must abide by strict guidelines to avoid breaking COM clients that bind to the current version. A type that is invisible to COM presumes it does not need to adhere to these COM versioning rules when it adds new members. However, if a COM visible type derives from the COM invisible type and exposes a class interface of ClassInterfaceType.AutoDual or AutoDispatch (the default), all public members of the base type (unless they are specifically marked as COM invisible, which would be redundant) are exposed to COM. If the base type adds new members in a subsequent version, any COM clients that bind to the class interface of the derived type might break. COM visible types should derive only from COM visible types to reduce the possibility of breaking COM clients.

Dependency: None

Notes:

@Evangelink
Copy link
Member

@lgolding @mavasani Would it be possible to give some more details about the rule (maybe the test cases) so that anyone from the community could implement it?

@Evangelink Evangelink added Approved-Rule Indicates if the new proposed rule has been approved to move to implementation phase help wanted The issue is up-for-grabs, and can be claimed by commenting labels Jan 7, 2022
@Evangelink
Copy link
Member

@AaronRobinsonMSFT Could you please provide the details about this rule to help people being able to pick this up (description, maybe use cases etc).

@AaronRobinsonMSFT
Copy link
Member

AaronRobinsonMSFT commented Jan 9, 2022

The rules here are related to vtable layout and order. Additionally, the built-in COM interop imposes other non-obvious constraints. This results in two rules:

  1. The declared order of methods/properties must remain the same as in the IDL/header file for the COM type.

Example:

MIDL_INTERFACE("67C36A28-6B25-4845-B313-38CC80CA5E56")
IExample : IUnknown
{
public:
    virtual HRESULT STDMETHODCALLTYPE Method1() = 0;
    virtual HRESULT STDMETHODCALLTYPE Method2() = 0;
};

Should be declared as:

[ComImport]
[Guid("67C36A28-6B25-4845-B313-38CC80CA5E56")]
interface IExample
{
    void Method1();
    void Method2();
}
  1. Inheriting from types requires redeclaring the types in the subclassed/sub-implemented interface.

Example:

MIDL_INTERFACE("2CC4B208-631C-48B3-89BD-D5CC5BE06AAA")
IExample2 : IExample
{
public:
    virtual HRESULT STDMETHODCALLTYPE Method3() = 0;
    virtual HRESULT STDMETHODCALLTYPE Method4() = 0;
};

Should be declared as:

[ComImport]
[Guid("2CC4B208-631C-48B3-89BD-D5CC5BE06AAA")]
interface IExample2 : IExample
{
    new void Method1();
    new void Method2();
    void Method3();
    void Method4();
}

/cc @dotnet/interop-contrib

@jeffhandley jeffhandley added the Priority:3 Nice to have (suitable for disabled by default rules and ported FxCop rules) label Jan 22, 2022
@jeffhandley jeffhandley modified the milestones: Unknown, .NET 7.x Jan 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Approved-Rule Indicates if the new proposed rule has been approved to move to implementation phase FxCop-Port help wanted The issue is up-for-grabs, and can be claimed by commenting Priority:3 Nice to have (suitable for disabled by default rules and ported FxCop rules)
Projects
None yet
Development

No branches or pull requests

6 participants