How can I use APIs not allowed under an UWP app in a runtime component that needs to work in both UWP and desktop apps? #858
-
|
I have a Windows Runtime Component which needs to work under both Win32 and UWP and since some UWP APIs can't be used from desktop apps, I have replaced them to use Win32 API when those methods are called from a desktop app. (I detect whether it's UWP or not by checking CoreWindow however that doesn't work in a UWP console app). Although I'm sure those banned APIs won't be called at runtime from a UWP app when using my Windows Runtime Component, the app certification kit seems to detect it and the UWP app doesn't pass verification. What should I do? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
There are a few of ways this has been handled traditionally. Some apply at build time, so there need not be any conditional choice at run time, for a smaller code footprint and more understandability. One might satisfy app certification. I imagine you know these cases. But, for the record: In C/C++ there is the use of conditional pre-processor selections and build options. That Unix tradition is probably worth avoiding. This means you have to build different releases for the different dependency cases but confirmation of cases gets messy. Another way is to create an abstracted interface of what you want and then implementing it two (or more) different ways. The build configuration causes one or another to be depended on. This still means different binaries, but it might satisfy app certification. There is a hybrid case tied to object lifecycle management. Dynamically choose a constructor depending on the situation. That way the decision is moved above where the customized implementation is relied upon. I don't know how that endures app certification though. Maybe you are already doing this? I suspect you do need different builds for your two cases. I thought the store handled such selective deliveries. What have you tried? |
Beta Was this translation helpful? Give feedback.
-
Yes, that's what I'm doing. There's a separate implementation that gets used in a Win32 app which is still in the same binary and the certification kit detects when used that DLL is used by a UWP app even if that banned Win32 API call won't get called ever. |
Beta Was this translation helpful? Give feedback.
-
Yes, it is completely plausible that the app certification kit is not doing code coverage and conditional use analysis. It looks like you need to use a single constructor but have different implementations for different-target builds. Early-adopter pain :). That seems to be as clean as it gets, pending further prospects for Reunion. 1.0 |
Beta Was this translation helpful? Give feedback.
There are a few of ways this has been handled traditionally. Some apply at build time, so there need not be any conditional choice at run time, for a smaller code footprint and more understandability. One might satisfy app certification. I imagine you know these cases. But, for the record:
In C/C++ there is the use of conditional pre-processor selections and build options. That Unix tradition is probably worth avoiding. This means you have to build different releases for the different dependency cases but confirmation of cases gets messy.
Another way is to create an abstracted interface of what you want and then implementing it two (or more) different ways. The build configuration causes …