search

dotnet / pinvoke

A library containing all P/Invoke code so you don't have to import it every time. Maintained and updated to support the latest Windows OS.
MIT License
2.12k stars 222 forks source link

Question about updating PublicApi.unshipped.txt #355

Closed ghost closed 6 years ago

ghost commented 6 years ago

I'm working on adding a few PInvokes from Ole32, and having trouble updating PublicApi.Unshipped.txt. Running the analyzer correctly gives warning RS0016, but the analyzer doesn't offer any hints for an automatic code fix. When I try to manually edit publicapi.unshipped.txt, it helps partially.

I'm using VS2017 v15.4.1.

PublicApi.Unshipped.txt has the following entries:

PInvoke.Ole32
static extern PInvoke.Ole32.CoEnableCallCancellation(System.IntPtr) -> PInvoke.HResult
static extern PInvoke.Ole32.CoDisableCallCancellation(System.IntPtr) -> PInvoke.HResult
static extern PInvoke.Ole32.CoCancelCall(uint, uint) -> PInvoke.HResult
static PInvoke.Ole32.CoEnableCallCancellation() -> PInvoke.HResult
static PInvoke.Ole32.CoDisableCallCancellation() -> PInvoke.HResult

Upon building, I see the following warnings:

Ole32.cs(22,38): warning RS0016: Symbol 'CoEnableCallCancellation' is not part of the declared API. [D:\src\repos\pinvoke\src\Ole32\Ole32.csproj]
Ole32.cs(45,38): warning RS0016: Symbol 'CoDisableCallCancellation' is not part of the declared API. [D:\src\repos\pinvoke\src\Ole32\Ole32.csproj]
Ole32.cs(80,38): warning RS0016: Symbol 'CoCancelCall' is not part of the declared API. [D:\src\repos\pinvoke\src\Ole32\Ole32.csproj]

I'd appreciate any hints on how to get these right. The relevant declarations in Ole32.cs look like this:

        [DllImport(nameof(Ole32))]
        public static extern HResult CoEnableCallCancellation(IntPtr pReserved);
        [DllImport(nameof(Ole32))]
        public static extern HResult CoDisableCallCancellation(IntPtr pReserved);
        [DllImport(nameof(Ole32))]
        public static extern HResult CoCancelCall(uint dwThreadId, uint ulTimeout);
AArnott commented 6 years ago

The analyzer's code fix provider can be a bit sketchy, I'm afraid. And writing it by hand can be very tedious to get right. It looks like you've already put forward a good effort. If you share the branch you're working on, I will try to take a look.

Thanks for contributing!

ghost commented 6 years ago

Thanks for the offer to help Andrew - I appreciate it!

I was able to solve it with a little more trial and error. The key, in my example, turned out to be the addition of the names of formal parameters. For e.g., static PInvoke.Foo(System.IntPtr pVoid) -> PInvoke.HResult works, but staticPInvoke.Foo(IntPtr) -> PInvoke.HResult doesn't. When I think about it, this makes a lot of sense given that named arguments require argument names exposed by libraries to remain reliably stable.

I've started a pull request for your consideration.

AArnott commented 6 years ago

Great. Thanks for getting back to us.