Import X509 certificate and collections from PEM. by vcsjones · Pull Request #38280 · dotnet/runtime (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation30 Commits10 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Fixes #31944
This does not have unit tests that exercise the I'm not sure of the best way to do it. Write the file out to a temp location? Or should I add a bunch of files to *File import methods. While I'd like those tested,runtime-assets package and open a PR there? Is there documentation about validating that it works locally?
Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
While I'd like those tested, I'm not sure of the best way to do it. Write the file out to a temp location? Or should I add a bunch of files to runtime-assets package and open a PR there?
Start with the temp file route. After everything is happy and stable we can add some things to the testdata package for the verisimilitude of loading a file that existed on disk before the process started.
Co-authored-by: Jeremy Barton jbarton@microsoft.com
we can add some things to the testdata package
Is there any practical benefit of doing this now if we can write temp files? My recollection from .NET Core 1.0 on Jenkins was that writing to disk was not a good idea because test interruptions would leave data behind and the environment was not ephemeral. If that's no longer true then I don't see much of a value add from adding files to the test data package.
we can add some things to the testdata package
Is there any practical benefit of doing this now if we can write temp files?
Not really. Mostly aesthetic or a "feel good" scenario completion feeling. I think the current model is fine, though.
