implicit cast operators for HttpContextBase, HttpRequestBase, HttpResponseBase

[sdekock]

For HttpContext, HttpRequest and HttpResponse there are implicit cast operators from and to the equivalent ASP.NET Core types.

However these are mostly missing in the *Base variants. Currently there is only an implicit cast to HttpContextBase.

[khellang]

Question; should the conversions be implicit both ways?

Microsoft's guidelines state that

If a custom conversion can throw an exception or lose information, define it as an explicit conversion.

If you want to discourage people from sticking with the old APIs, I suggest making the ASP.NET Core -> System.Web conversion explicit. Since there's a lot of System.Web APIs that are unsupported running on top of ASP.NET Core, it makes the old abstractions much weaker.

[twsouthwick]

If a custom conversion can throw an exception or lose information, define it as an explicit conversion.

This is why I had removed initial versions that would implement this. Can you share the scenarios you would make use of these conversions?

If you want to discourage people from sticking with the old APIs, I suggest making the ASP.NET Core -> System.Web conversion explicit.

Interesting thought. Part of the goal here is to aid with making the conversion from System.Web -> ASP.NET Core simpler. One of our principals here is minimal code changes to get running on core. It seems that if we made the conversions explicit, it would end up adding those explicit calls everywhere.

The next step in a migration after adding the adapters is "how do you get off of them". This is something we haven't focused as much on yet, but is top of mind. We'll probably start with some analyzers that will flag things like implicit conversion and provide some helpers to convert things to more ASP.NET Core specific patterns.

[sdekock]

This is why I had removed initial versions that would implement this. Can you share the scenarios you would make use of these conversions?

In my current project I only need the conversions from the ASP.NET Core context classes to the System.Web *Base classes. As we are passing them from MVC controllers to other parts of our application (business layer / utilty functions / ...).
These other parts currently expect the *Base classes as we don't use HttpContext.Current but the HttpContext property of the Controller, which is of type HttpContextBase. Similar situation for HttpRequestBase and HttpResponseBase.

The conversion in reverse (System.Web to ASP.NET core variants) is not strictly necessary in my situation.

Having to add explicit conversions would feasable but a lot more upfront work. We are currently multi targeting .NET fw 4.8 and 6 (with separate .csproj files and lots of #ifdefs). I guess we could call the conversion method too on .NET fw and just make it return the original instance.
We plan to just remove the dependency on the adapter package when our app is running stable on only .NET 6.

[twsouthwick]

What about just the implicit operators of the ASP.NET Core->System.Web types? The other direction is not as straightforward. Using the *Wrapper implementations for the implicit *Base would probably make sense.

[sdekock]

What about just the implicit operators of the ASP.NET Core->System.Web types? The other direction is not as straightforward. Using the *Wrapper implementations for the implicit *Base would probably make sense.

Would be fine in my specific case.

I was just aiming for parity with the regular HttpContext/HttpRequest/HttpResponse types, for those you already have a cast from the legacy to the new types.
And if you see in my PR it's not too difficult to implement, you just need a virtual Unwrap method.

[sdekock]

I also get why you would choose for explicit conversions. I believe the concerns @khellang already stated are definitely valid.
But I believe the conversions for the regular HttpContext types should then be explicit as well.

However I see this entire package as something you only should use when migrating. Most of it implies you pay for a performance hit anyway. The end goal should be to remove the dependency entirely and not stick with the old APIs ...
Having to add the explicit conversions everywhere, and then removing then afterwards might be a lot of wasted effort.

[twsouthwick]

Merged in