I couldn't find a satisfying answer to that question.
I'm trying to migrate my code from .NET Framework into .NET Core, and I ran into problems with my .ashx files.
Basically there are compile errors (Because I need to update my used NuGet Packages).
but even before that, I'm trying to figure out - Can I even use .ashx files inside .NET Core proejct?
Are there any changes I need to know about? Or should it be identical to .NET Framework (Besides packages).
Thanks!
Simply put, no.
Long answer:
All .ashx files have a background class that inherits either from System.Web.IHttpHandler or System.Web.IHttpAsyncHandler.
Now, if your handlers are programmed well, most of what you have to do is declare those interfaces in .NET Core:
And automatically rename System.Web.HttpContext into Microsoft.AspNetCore.Http.HttpContext.
Then you need to remove all references to System.Web.HttpContext.Current (which you wouldn't need to do if you programmed your handlers properly).
If that is a lot of work, my answer here https://stackoverflow.com/a/40029302/155077 suggest a dirty workaround (basically, spoofing System.Web.HttpContext.Current).
Then, all you need to do is search to root path recursively for the ashx-file-paths, parse those files with regex for the corresponding classes (or do it manually if you have few) and add them as endpoint in .NET Core. Either you can just instanciate the class (singleton IsReusable = true), or you can write a handler that creates a new instance of class, and then calls ProcessRequest in said class.
You'll need to fix all compilation problems, though.
You can also parse the paths in the source project once, and generate the middleware/endpoint-injection code programmatically once.
That's probably the best option you have for large projects.
Though, you are in luck if you have ashx-handlers.
But don't just start just yet.
If you have aspx-pages or ascx-controls, you are definitely out of luck, and don't need to start with the .ashx-handlers in the first place - unless your aspx/ascx usage is so tiny, you can replace them fairly quickly.
Still, if you just need to port a lot of plain raw .ashx handlers producing json/xml, this method can work excellently.
Oh, also note that you need to change context.Response.OutputStream with context.Response.Body.
You might also have to change everything to async (if it isn't already), or you need to allow synchronous methods in the .NET-Core application startup.
Here's how to extract data:
And here's the Middleware with example handler "Ping.ashx".
Then you still need a generic Endpoint Middleware, here:
And then you can set up the Endpoint with:
Keep in mind, middleware is async, and your ASHX-Handlers probably aren't.
That's gonna be a source of work-intensive problems (or deadlocks, if you just use .Wait() like in my example).