Open ikijano opened 2 years ago
I agree - a library should support Netstandard 2.0 whenever possible IMHO. Also agree on relying on string literals isn't the way go, but on the other hand the suggested 'fix' doesn't actually test anything either; it just mirrors internal behavior.
I 'fixed' most of test in my test repo. So far everything is good.
I think, I could live with my fork until official library supports netstandard2.0 or i can move on to .net6+ era.
Of course it would be nice if official library would use more predicted message checks in tests so back porting new features to unofficial lib would be simpler.
@ikijano Why don't you do a PR?
I will do when I finish test fixes and do some cleanups.
Looks a fantastic library and I like to use it in my work project but unfortunate I'm stuck in .net framework world so i'm unable to use this library :( Have you ever considered supporting .netstandard2.0?
I played a little bit library source code and I managed get it compile when targeting to netstandard2.0 with langversion 10 using help of IsExternalInit and Nullable packages and re-ordering of namespace and using statements on couple files because of stylecop. It looks like there is no actual show stoppers in library code only some tests needs slight modifications. When running tests "only" 207/442 tests fails on .net framework 4.8. Common pattern seems to be that
ArgumentException
message format is slightly different on .net framework vs .net core. Tests are assuming blindly .net core message format instead of using real message format implemented by runtime which I considered to be implementation bug. If runtime implementation ever changes all these test will fail.In example following test will fail on .net framework 4.8:
Message:
if I change test to following form (not assuming any message format implementation details) test will succeed:
test repo (no test modifications) https://github.com/ikijano/throw/tree/wip-netstandard2