Make SqlConnectionEncryptOption string parser public#1771
Make SqlConnectionEncryptOption string parser public#1771cheenamalhotra merged 5 commits intomainfrom
Conversation
Codecov ReportBase: 71.82% // Head: 71.41% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1771 +/- ##
==========================================
- Coverage 71.82% 71.41% -0.41%
==========================================
Files 293 293
Lines 61376 61383 +7
==========================================
- Hits 44082 43836 -246
- Misses 17294 17547 +253
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SqlConnectionEncryptOption.cs
Outdated
Show resolved
Hide resolved
DavoudEshtehari
left a comment
There was a problem hiding this comment.
(SqlConnectionEncryptOption)null returns True. Just raising it for more discussion.
If it's by design it'd better be mentioned in the documentation, plus extending the code coverage.
cc @David-Engel
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SqlConnectionEncryptOption.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/netcore/ref/Microsoft.Data.SqlClient.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/netfx/ref/Microsoft.Data.SqlClient.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: DavoudEshtehari <61173489+DavoudEshtehari@users.noreply.github.com>
Do you have a use case for that scenario? It wasn't intentional (it wasn't even considered), but since that's the behavior, we should maintain it by adding it to the tests. |
No, just a random test. I'd suggest these 2 options to improve this part: 2- Keep it as it is instead of interpreting |
|
I realize I missed the discussion before approving the changes, but the changes is relatively safe and tests were included to validate them so perhaps the suggestion from @DavoudEshtehari could be handled in separate PR. |
It would be useful to have these parsers public to be able to parse string values directly when needed, instead of consumer apps writing their own.