locked
Windows Store App fails "Supported API test" on non-Win32 API

    Question

  • I have a "proof of concept" C# windows (8.1) store app that references a C# portable class library which in turn calls across (p/invoke) to an exported function called "xxxx" in a C++ dll containing legacy code. All the offending win32 APIs have been removed or changed to acceptable forms. The C++ dll is included as content in the store app package and the app runs fine when tested with VS2013. The problem is that the store app fails the certification check "supported API test" saying that the API "xxxx" is not supported for this application type. No other APIs are flagged. I was under the impression that p/invoke from a C# portable class library to a C++ dll is supported as long as no objectionable win32 apis are leveraged. Any ideas on why this certification failure is generated?  
    Thursday, March 27, 2014 6:16 PM

All replies

  • Thursday, March 27, 2014 6:35 PM
  • The dll is part of the Visual Studio project and is deployed with the app. If I run it from the Apps menu it runs just fine. The flow from app to C# portable class library to C++ dll (through p/invoke) works. It is the certification check that flags the one (and only one) exported C++ dll function that is used as the single point of communication to the C++ dll.

     
    Thursday, March 27, 2014 7:43 PM
  • Also from what I've seen you cannot add a reference to a C++ dll unless it is a runtime component compiled in the same solution (not possible here) or turned into an SDK (not practical). The certification test knows that the API belongs to a dll which is included as content in the app package and is the target of a p/invoke from a dependent C# portable class library so why is it "not supported"?

    Friday, March 28, 2014 4:00 PM
  • I tried asking this question on a different Forum to no avail so I'll try it here.

    I have a "proof of concept" C# windows (8.1) store app that references a C# portable class library which in turn calls across (p/invoke) to an exported function called "xxxx" in a C++ dll containing legacy code. All the offending win32 APIs have been removed or changed to acceptable forms. The C++ dll is included as content in the store app package and the app runs fine when tested with VS2013. The problem is that the store app fails the certification check "supported API test" saying that the API "xxxx" is not supported for this application type. No other APIs are flagged. I was under the impression that p/invoke from a C# portable class library to a C++ dll is supported as long as no objectionable win32 apis are leveraged. Any ideas on why this certification failure is generated?

    Thursday, April 3, 2014 3:45 PM
  • The basic steps you list sound correct. Does the DLL itself pass if you link it in a C++ app? Make sure it's built to target Windows Store and doesn't include any disallowed API, including base library and runtime calls.

    If you need more help we'll need more details. Can you repro with a minimal sample that you can share?

    --Rob

    Thursday, April 3, 2014 6:10 PM
    Owner
  • I believe the C++ dll to be clean. It did have a couple of disallowed API calls like MoveFileExA which were properly flagged during the certification test but I fixed those and the only thing being flagged now is the private exported API used for communication between the C# PCL and the C++ dll. I will attempt to recreate with a minimal sample that I can share. 

    Thank you for responding.

    Thursday, April 3, 2014 6:16 PM
  • Well the exercise of writing a minimal sample brought me to an epiphany if not a solution. The minimal sample passed the certification tests where the production code did not and I believe I now know why.

    The C# production PCL is compiled as "AnyCPU" but the legacy C++ code is either 32 or 64 bit and the dlls have different names because the 64 bit version has "64" appended to the name. Because of this the PCL has 2 DllImport statements for the same API only one of which is used depending on whether the C# PCL is running as part of a 32 bit application or a 64 bit application. The example store app which was the target of the certification test only had the appropriate legacy C++ dll included as content so the "other" unused api is flagged.

     
    Friday, April 4, 2014 4:19 PM