Microsoft recently released .NET Core 3.0 and set the stage for WCF’s exit. .NET Core no longer supports “full framework” mode which effectively ends support for WCF as we know it. Our options for migration vary. Today let’s discuss one such approach I feel is a “low-impact” approach. Let’s look at migrating WCF to gRPC using .NET Core while still maintaining backwards compatibility.
Your software application will crash. Even the most principled software following the best practices will inevitably have a bad day. Figuring out why it crashed and how to prevent it is a skill in and of itself. Fortunately there are steps you can take to help you when this time comes. Application logs are your friend and it is necessary to learn how to read them.
Breathing new life into a “legacy” ASP.NET website is a way you can help slowly transition the site towards ASP.NET Core. One way you might accomplish that is by referencing .NET Standard libraries. Everything seems fine and dandy until you attempt a publish operation. Generally you might not notice these until running msbuild from command-line–such as in a CI environment, batch deploy script, or otherwise. Let’s talk about one major msbuild error you’ll encounter while publishing your ASP.NET MVC application that references a .NET standard library. We’ll also talk about some other errors that might arise in the process.
Recently I was going through the motions upgrading an ASP.NET Core 2.0 website to 2.2. Overall the process was fairly straightforward, minus some gotchas. We were attempting to switch the website from targeting the full framework (
net47) to target
netcoreapp2.2 but that caused a cascade of problems. One such problem was WCF. Today we’ll discuss using WCF with .NET Core and some of the gotchas you may run into.
Last month we talked about Cookie management in DotNetCore web applications and introduced a generic cookie service. Today we’re going to look at an alternative option for storing user data. Session state is a server store of information linked to a browsing session. Today let’s look at a technique for generic session management in dotnetcore web applications.
Last year I worked on a team migrating a large application to ASP.NET Core from ASP.NET MVC 5. Among our goals we wanted to make the site use responsive layout, become “future-proofed” on a technology stack, and clean-up a bunch of legacy cruft. Our initial launch did not go smoothly and we reverted to the previous site to make changes. In the process we learned some “gotchas”. Today I’m going to discuss one of those and how we addressed it. We’ll learn about throttling requests in .NET Core web applications.
For those of us used to cookies in traditional ASP.NET the switch to ASP.NET Core might leave us scratching our heads. In the old system we were able to directly add and remove cookies from both the request and response objects (for better or worse). This might have led to us writing and overwriting the same cookie multiple times during a request as different portions of code affected it. DotNetCore has changed the game and that’s a good thing, trust me. Today we’re going to learn a technique for cookie management in DotNetCore web applications.
In my last post I talked about creating a .NET Core console application for removing advertisements from a recorded stream. I glossed over some of the things I did in that application such as hooking up dependency injection and configuration management. Today I’m going to talk about implementing dependency injection in a DotNetCore console application.
Hypothetically, let’s say I have some software that records streaming video from the interwebs. For the sake of this exercise I’m also pretending this software is called PlayOn. Next, I’m imagining that the recorded streams also include advertisements. Continuing into our hypothetical journey I’m guessing I have a media center where I host the recorded media.