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

Violates Windows Store App Certification #129

Closed
deanchalk opened this issue Aug 7, 2016 · 13 comments
Closed

Violates Windows Store App Certification #129

deanchalk opened this issue Aug 7, 2016 · 13 comments
Assignees
Labels
Milestone

Comments

@deanchalk
Copy link

running a UWP app through windows store certification kit and I get

API getenv in api-ms-win-crt-environment-l1-1-0.dll is not supported for this application type. libSkiaSharp.dll calls this API.

So we cant publish UWP apps with SkiaSharp.

@migueldeicaza
Copy link
Contributor

I suspect the problem is this code from:

skia/src/utils/SkRTConf.cpp

There is some code surrounded by SK_BUILD_FOR_WINRT and we are bringing this in.

@bholmes
Copy link
Contributor

bholmes commented Aug 9, 2016

The SkRTConf.cpp preprocessor check appears to do the right thing. It should be excluded.

I believe it is coming from libjpeg-turbo in the third party section.

https://skia.googlesource.com/third_party/libjpeg-turbo/+/debddedc75850bcdeb8a57258572f48b802a4bb3/simd/jsimd_x86_64.c#52

Trying to think of a clean way to patch those files. @mattleibow have we patched any other third party work?

@mattleibow
Copy link
Contributor

mattleibow commented Aug 10, 2016

Fixed in commit c185f5c

SkiaSharpCert.xml.txt

@mattleibow
Copy link
Contributor

Inject an empty method using defines. I am not sure how this compiled since the code in SkRTConf.cpp throws a compiler error, but the code in jsimd_x86_64.c does not...

@mattleibow mattleibow self-assigned this Aug 10, 2016
@mattleibow
Copy link
Contributor

This should be fixed in the upcoming (planned for this week) release: v1.53.1

@mattleibow mattleibow added this to the 1.53.1 milestone Aug 11, 2016
@mattleibow mattleibow reopened this Aug 19, 2016
@mattleibow
Copy link
Contributor

Re-opening this on account that x86 still uses getenv somewhere. ARM and x64 appear to be fine.

@mattleibow mattleibow modified the milestones: 1.53.1.2, 1.53.1 Aug 19, 2016
mattleibow added a commit that referenced this issue Aug 20, 2016
@mattleibow
Copy link
Contributor

I think everything is fixed now, just waiting on my app to be officially published.

@mattleibow
Copy link
Contributor

Your submission for Skia.UWP.Demo passed certification.

It will take up to 16 hours for your changes to be visible to all of your customers. Once published, your app's listing will be available at https://www.microsoft.com/store/apps/9NBLGGH51856.

Thank you,
The Windows Store Team

@tseemann-xematec
Copy link

Hi guys

I am still experiencing this issue with SkiaSharp v1.54 :(

Message from Windows Store Certification:
API getenv in api-ms-win-crt-environment-l1-1-0.dll is not supported for this application type. libSkiaSharp.dll calls this API

Any suggestions?

@mattleibow
Copy link
Contributor

@tseemann-xematec That is weird. Especially since I have an app on the store using v1.54.0. What you can do to test is to run the cert tool on one platform at a time and see which one is failing.

What you can try is to remove the NuGet, and then delete it from your cache
C:\Users\username.nuget\packages\SkiaSharp

Then restore it. Maybe for some reason it is doing it wrong. I released the app using the NuGet, so it can't be the released one. But, just for sanity, could you re-download and then run the cert again?

Let me know what happens...

@tseemann-xematec
Copy link

Thanks, @mattleibow - I will try removing and re-adding the package entirely. I'll be back.

@mattleibow
Copy link
Contributor

@tseemann-xematec Did this resolve your issue?

@tseemann-xematec
Copy link

@mattleibow Problem solved :) You were right - we still had a reference to v1.53. All our direct references in our projects to SkiaSharp were correctly v1.54, but it turned out we had an indirect reference to v1.53 in one of our own NuGet packages, because it stated a dependency on v1.53, even though it was itself using v1.54.

Thanks for your hint!

@ghost ghost locked as resolved and limited conversation to collaborators Aug 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants