Some methods don't resolve on .NET Framework

[twsouthwick]

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)
  • T:System.Void M:System.Web.HttpException.#ctor(System.Net.HttpStatusCode,System.String)
  • T:System.Void M:System.Web.HttpException.#ctor(System.Net.HttpStatusCode,System.String,System.Exception)
• 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
• HttpResponseBase.Cache should be of type System.Web.HttpCachePolicy (HttpResponseBase.Cache is typed incorrectly as HttpCachePolicy; Causes MissingMethodException #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