During porting, we had been using various tools (such as EnablePackageValidation and some tests) to validate that the members/types ported matched with System.Web.dll so that the assembly would resolve correctly. However, looks like the testing did not validate return types correctly. This is to track methods that will not resolve correctly on framework when using the .NET Standard library:
Can obsolete and add the correct members if possible:
[ ] the following HttpException constructors should not exist:
-T:System.Void M:System.Web.HttpException.#ctor(System.Int32)
-T:System.Void M:System.Web.HttpException.#ctor(System.Net.HttpStatusCode)
[ ] HttpException.StatusCode should be int HttpException.GetHttpCode()
[ ] CacheDependency.Dispose(bool) should not exist
[ ] System.Web.Caching.Cache.GetEnumerator() should be an implicit interface implementation
Will require a breaking change to the API:
[ ] HttpRequest.LogonUserIdentity should be WindowsIdentity
[ ] HttpContextBase.Application should use the type HttpApplicationStateBase
[x] HttpResponseBase.Cache should be of type System.Web.HttpCachePolicy (#476)
Thanks @AvremelM for point out the HttpResponseBase issue. I've added a test in #487 to catch further regressions and to identify other existing ones.
This will probably necessitate a bump for v2.0 of the adapters as changing these signatures is technically a breaking change (although it is currently in a broken state...)
During porting, we had been using various tools (such as EnablePackageValidation and some tests) to validate that the members/types ported matched with System.Web.dll so that the assembly would resolve correctly. However, looks like the testing did not validate return types correctly. This is to track methods that will not resolve correctly on framework when using the .NET Standard library:
Can obsolete and add the correct members if possible:
HttpExceptionconstructors should not exist: -T:System.Void M:System.Web.HttpException.#ctor(System.Int32) -T:System.Void M:System.Web.HttpException.#ctor(System.Net.HttpStatusCode)HttpException.StatusCodeshould beint HttpException.GetHttpCode()CacheDependency.Dispose(bool)should not existSystem.Web.Caching.Cache.GetEnumerator()should be an implicit interface implementationWill require a breaking change to the API:
HttpRequest.LogonUserIdentityshould beWindowsIdentityHttpContextBase.Applicationshould use the type HttpApplicationStateBaseHttpResponseBase.Cacheshould be of typeSystem.Web.HttpCachePolicy(#476)Thanks @AvremelM for point out the HttpResponseBase issue. I've added a test in #487 to catch further regressions and to identify other existing ones.
This will probably necessitate a bump for v2.0 of the adapters as changing these signatures is technically a breaking change (although it is currently in a broken state...)
See the baseline of known issues that should be updated as these are fixed