In this episode of Adventures in .NETm we get deep into .NET with Andrew Lock. Kubernetes, .NET Framework to .NET Core and everyone’s favorite topic configuration. Join us and you are guaranteed to learn something new.

Links

Joel Schaubert

Shawn Clabough

Caleb

Wai

Andrew Lock

Hello, and welcome to another episode of denturesin.net. I'm Sean Clebi, your host. And with me today, we've got a full panel. Alright. Caleb Wells.

Welcome, Caleb. Y'all. Hey. How's it going? Good.

Is hurricane season over for you finally? Not not officially, I don't think. But, you know, hey. We've we've made it this far. A couple another weeks won't kill us, hopefully.

Yeah. Hurricanes for you, we're getting snowstorms this weekend. So Oh, okay. In my area, Sunday, we're supposed to be, a low of maybe single digits. So Whoo.

Only a couple weeks ago, we were 80 degrees, so a big change for us. That's why I live in the south. I'll take the hurricanes over the snow any day. Wow. Wow.

Yep. Not bad. Hey, Josef Wailu. Good night. How you doing?

Hey. Good. Good day, mate. Yep. I could try.

Oh, god. Alright. How are you? Yeah. I'm good.

Good. We're getting a lot of rain here soon actually. I think I think we're getting a lot of rain here. I think, it's gonna be raining for literally the next week, Kinda be fun at home with the kids. So Better than fires.

Yeah. You're right. Yeah. Although, this means that this will be more fuel for when someone comes. Mhmm.

I see. Yep. And we have Joel Sjoberg. Hey, Joel. How are you doing?

John, how are you doing? Good. Any you got some snow? Yeah. I heard.

We've been under a solid blanket for about a week now. So, I guess we could have a snow off contest here, but I think I might be winning right now. Probably. Probably. Alright.

Our guest today is Andrew Luck. Welcome, Andrew. Hi. Thanks for having me. Yeah.

I'm New England, so we just got rain. Just rain. Rain? Always. Wow.

That's what I'm I'm not too far from Seattle. That's you know, Seattle is also known for rain, so I can, I can relate to you? Yeah. It's just great days. So, welcome to the show, and thanks for coming.

And, why don't you tell us a little bit about yourself, what you do, and how you got into programming and how you got into dot net? Sure. So I'm an ASP Netcore developer. I I got I got a bit of a later start than a lot of people. I didn't start programming when I was a kid, really.

My dad tried to teach me basic at one point, and he showed me the print numbers on the screen. And I was like, meh. Fine. Whatever. I played games and I enjoyed that sort of side of it, but I never really never really got into it until I got to uni.

And so I did I always liked maths and science and things, so I did engineering degree. And then in the 1st year of that, we had a couple of programming courses and assembly and c plus plus. And that's why I really realized that's that's actually what I enjoyed. That's why I wanted to do. So I kept doing as much of that as I could and started picking up jobs on the side just doing doing a bit of programming here and there.

And and then so when I I went on to do do a PhD, and again, it was just mostly because I could do more programming that way. I couldn't get the the job I wanted at the time, and so I did the PhD and did the programming on the side. And after that came out of it and finally got my programming job. So that was about I was quite late to the dot net party really. That was, I guess, dotnet 3.5 was when I started.

Just still 10 years ago, I guess. Right. So you love assembly? You love assembly. I I I enjoyed assembly at the time.

I only did. I I did one one course of it, but it was it's logical. It's, you know, you obviously can't really build anything. I got UV lights and that was it. But it's yeah.

You know? Thought that was where I really started to realize that you could actually build a lot of things. It was with wind forms, and I was just suddenly got desktop apps applications seem to really, you know, show what was that what I could actually achieve. Yeah. It's kinda kinda good to know, you know, what what the code that you write actually ends up at down when it actually work actually run through the computer.

So it's a little bit beneficial to know that, dealing with registries and, you know, peek and poke and pop and all the different branches that you can do once it gets down to the level. But, man, in my college days, that was that was just really, really tedious. The tools have gotten better since then, but, yeah, it's a good it's good base knowledge. I will, I'll leave that to you guys. I'm happy with my graphic design degree.

Y'all can have assembly. You and your color wheels and things like that. Exactly. Right? Alright.

So, then how did you get into dot net? Then why what what attracted you to that, arena? It was it was sort of by accident, really. It was just a company that, around the corner was using .net. I I start actually, no.

I lied. They were using classic ASP. And so I was doing, yeah, old school ASP. Doing all the VB script in the in the browser or I think I think you could actually do it in the browser at that point. I'd Yeah.

Oh, yeah. It was it was nice and secure. I've been there. Oh, yeah. Yep.

And then so they they slowly drifted on the ASV on that, the first early remnants of that. But I I still got taste for it then. But then really, it was because I was coming out of c plus plus and try I was trying to build forms using Open GL and using c plus plus. That was it it wasn't fun. And that's that's what I found.

I just just just a bit of Google doing all what the equivalent was at the time of, and I found WinForms. It just you know, it was so easy. Suddenly, it's literally just drag something on, double click it, and you've got a form instead of having to try and work out pixel locations. I think I think WinForm is actually a really good place to learn programming. Because you like you said, you got that designer.

You can just literally just drag thing onto onto the, you know, onto the designer. You can see it straight away. I started yeah. When I started Windows programming, it was fully when I think it was vb3 or something. Like, someone I I took a, like, a private version of vb3.

It was, like, 5 meg file or something, you know, back in the early nineties or late late nineties sometime. So So So you moved from WinForms. Yep. So you moved from WinForms then into the web? Yeah.

So this talks to a few different companies that are just doing little little bits and pieces on the side really. Sort of contract work really. And, yeah, that's where I sort of discovered the web at that point, going from a few bits of, you know, a few WinForms apps. Obviously, the WinForms apps then maybe you need a back end. So that's where you start building APIs.

And from that, yeah, just got generally into ASP dot NET and been pretty much just on the web ever since. I haven't touched another WinForms app since then, which I guess is 8 or 9 years ago now. Andrew, people may not know you straight off, but I can bet you money if they do a search for something in ASP dot NET Core or like ASP NET, migrations or configuration, your blog will be on the first page. Because I have actually used several of your your posts, and I think we're gonna talk about a a few of the things you've you've gone into. But what got you to to blogging about that net?

So I was working at a job, and I was it was ASP dot NET at the time. It was just the beginnings of ASP dot NET Core was starting to be be whispered around, really. And so I sort of I I started tinkering on the side. I didn't have any blog at that point. I didn't have anything about that.

There was and the the blog was basically a way for me to force myself to teach myself ASP dot NET Core. It was a way for me to look at your code. And by by knowing I was always gonna be putting out another blog post every week, I would look into something new, try and learn about it and teach it. So it was it was really a selfish thing. It was just so I could make myself learn it.

But since then, it's just, yeah, it's just become one of those things. I do a new blog post every week. Just normally with things I've run into at work, tackling problems or new things are coming out. Cool? So I think, one of the main topics we wanna talk about is using dotnet and Kubernetes.

So for those aren't familiar with Kubernetes at all, kinda give us an intro to that first. Sure. So Kubernetes is an orchestration platform for containers, which in itself needs an explanation probably. And a lot of people probably heard of containers and Docker. And really they are they they seem to do what the future of deployments where you can wrap up all of your dependencies, all of your operating system into a file.

You describe describe what you want and you don't have to when you deploy that Docker file, you don't have to have the dependencies already installed on the image. They come with you. Everything's packaged up as a single artifact. So the struggle you have with that is when you start deploying those around, you need to manage them. You need something to control when they're deployed, when they're shut down, which one new ones are run, and Kubernetes fills that niche.

Kubernetes is controls your bucket containers. So does your app typically have more than 1 container running? So it depends. It it it depends. Typically, an app so a single ASP NET core app would just be a single container.

But the whole app as a whole, you might split that into multiple services. You might want to have separate apps if you want to deploy them separately. You might have a separate container, which is just doing sort of message handling. If you've got a RabbitMQ or some sort of message bus, you might just want to have that deployed separately. Again, really anything that you deploy separately or you'd want to deploy separately or control separately or scale separately, you'd put that in a separate container so that you can, manage that independently of the other ones.

So so Kubernetes, would would you say is useful is not useful if you've if you've got an app that it's only got one container, but it is useful if you've got more if you've got an app that's got multiple containers and you can decide when to turn containers on and off? And I wouldn't have said it's it's not useful, but it's certainly overkill at that point. That's it's really it's really not gonna bring you a huge amount. It's give you a lot of complexity. If you've just got a single app at that point, you really probably wouldn't be looking at something like Azure App Service or a a PaaS offering there because there's not a lot of management to be done.

There's not really much orchestration. Mhmm. It's only when things start getting complex that it becomes very useful. So Kubernetes is kinda like the conductor for an orchestra, and each one of the containers is like the musicians in the orchestra. And the conductor says, okay.

You start now. Okay? And really keeps the beat so everybody's in sync. And then, you know, when everything needs to stop, the conductor says stop. So that would be Kubernetes.

Right? Exactly. Yeah. That's, that's good analogy. Yeah.

Good analogy. Why did you choose Kubernetes? I know the company you're working for, right, had some ASP dot NET apps that you've migrated into core and got them running into Kubernetes. What was the the the thought behind that? So I wasn't actually part of the the initial decision, but the the the fundamental problem was Windows deployments were being problematic.

They had probably about a dozen apps sort of it wasn't quite microservices, but in the separate services giving, you know, separate parts of the domain. They were all, all deployed on Windows IIS machine with it it was it worked, but it was flaky. There was some problems of and try to get 0 downtime deployments was difficult, and there was they had message handling services right in the background, which we deployed as Windows services. And the deployment code is just it was full of all sorts of hacks. Like, you try and you try and stop the service.

The service doesn't stop for some reason. So you try and deploy it and it won't deploy it because it's still running. And it was it was it was just a bit messy, and I think they had basically had enough. They were already using Python for doing some various machine learning stuff. And so they were already deploying to Linux machines, and Kubernetes really just seemed like the best option.

It was solving it was gonna solve the problems, basically. It was gonna solve that deployment problem, orchestration problem, and talking between the different apps. I can see that. Yeah. I've I've had those issues, right, where you have a Windows service and it hangs and there's nothing you can do but restart the machine.

And, of course, that's not ideal. So Exactly. And that was the you don't have to go in every night again and just reboot the VM. It's just it it got too much. Yeah.

So what's it like to set up Kubernetes? I mean, you you tell it about each one of your different containers, but what do you tell it beyond that? So setting up Kubernetes itself is not very faint hearted and not something I have actually really had a lot to do with. It's, there's a lot of networking, you need to understand, you know, how how, how the different networks work, you need to understand VPCs. And it's not I I if I could just say it's beyond standard developer fair, actually setting up the Kubernetes cluster.

The good thing is that generally you don't have to do that a lot of the time. Like I've I've got other colleagues that are good at that side of it. And they've handled that for me in terms of what I do is deploy to the Kubernetes cluster. Similarly, if you're if you're deploying to AKS, so the Azure Kubernetes service or there's EKS is the AWS version, They take care of essentially setting up a cluster for you. You just have to deploy it to it.

So that's that's more of a sort of developer DevOps role that I've I've been in. Yeah. It can't be as bad as setting up a SharePoint cluster, but, yeah, I I get what you mean there. So deploying to Kubernetes, you know, you're you're pushing your containers out there, but still there has to be some configuration about how it knows when to start things and when to shut things down. How do you do that?

I see. So there's there's certain primitives in the Kubernetes uses. So you have the smallest the smallest unit you've got is a pod. And a pod is typically like one container, but it can have multiple containers in there. If you're willing to sort of side, It's called the sidecar when you have little containers which are running extra services for you.

But typically, you'd have essentially one container in a single pod. That pod, you then combine multiple instances of that pod together to form a service. Kubernetes can then assign each of those pods separate IP address, and the service acts as a load balancer across these different pods. And so you have to configure all of these different layers. You have to configure what what you want to go in your pods.

You have to configure how many you want to be deployed, what service you want to call the service to, direct traffic between them, and how you wanna expose that side of the cluster. So all that side of it, you manage essentially using YAML files. That's the Kubernetes primitive, configuration. Just YAML everywhere. It is so funny, and I even hear this from the Microsoft people.

They're like, yes. We get you don't like YAML, but it's what it is. So just learn it and be happy. Yeah. Exactly.

And there's there's some tools that can help with that. So the one thing we use is called Helm, which is essentially a templating language on top of the YAML, which could just reduce the amount of duplication you have. And they have some sort of boilerplate templates that you can set up, which makes it a lot easier to get started. So actually deploying a service, you first need to build your containers. You build your ASP NET Core application.

You inside a container, and then you push that container up to a registry, which is accessible from your cluster. At that point, you can then deploy your YAML files into your cluster, which tells it where to pull the Docker files from, how to run, and what endpoints to expose. And where you deploy it? Is this in enters onto Azure? So we're not we're doing it to AWS.

And so we are essentially running our own Kubernetes cluster just in VMs at the moment with a view to moving to to the managed service later. But as everything we have is in AWS, it's I haven't really I haven't really played with the management side of it. But it's essentially that. Yeah. I say the the managed clusters seem like the way to go, really.

Okay. So you're deploying it to just a, like, a virtual virtual machine on AWS? Exactly. So we got we got several virtual machines in AWS, which are then all networked together to form the Kubernetes cluster itself. So I'm not actually dealing with the VMs generally.

That that's kind of transparent in the background. You all you see is just one coherent cluster over the top of it, and so you're interacting with the the cluster has an API, an admin API, which is what we use in the back end. So that's all our scripts used to to, deploy our applications. So so what would be the benefit of deploying Kubernetes, like, into onto a VM versus just using something like an like an app service then? Honestly, I wouldn't recommend doing it to a VM at this point.

We've been running it for a while now. At the time, the managed service wasn't it had it had a few issues. At this point, the the managed EKS and things like that are I I think it's fair to say that the way to go for initial running is some sort of huge cluster, and you need to have really tight management over them. I can't see a reason to do that at this point. Yeah.

Because, I mean, on a on a VM, you're still gonna have to do your own security patching and things like that and and your own kind of all that all that management underneath. Yep. Exactly. Which is it's just not worth it if you can get away without having to do that. Absolutely.

Mhmm. Does Kubernetes do anything like health checking so it knows, you know, this little pod, this container is still working the way that it should? Absolutely. So that that's that's really integral to the way Kubernetes works. They have multiple types of health checks.

You have liveness checks and readiness checks and startup checks, which startup checks are barely self evident. It's basically an endpoint in your application that it calls. And once your application starts up, you start returning to 200. It knows that pod is alive. Liveness checks the same thing.

It pings apps constantly just to make sure that your app is still running. And readiness checks are slightly different. That's that tells it whether it can be traffic to you or not. And so it uses these these liveness and readiness checks to decide which pods are alive, which ones need to be restarted because, you know, you you aren't now hung. Normally, you run more than one instance of the application.

So if it hangs, that's fine. Kubernetes just restarts in the background, and that's fine. You just carry it on. And the other good thing about this is it means you can have zero downtime deployments just really easily. You just deploy your next instance of your application, and Kubernetes will wait for the new wait for new pods to start up sort of healthy.

And then once they're healthy, it can it will divert traffic across to them, and then it'll slowly wind down your old pods. So you just get that rolling deployment without any issue at all. Yeah. That's what I'm talking about. Right?

Don't have to worry about once a is ready, flip b to a or back and forth, or this is our staging 1st production, and we're gonna rotate the 2. It just handles it. That's great. Exactly. That and that's to me, that is the biggest selling point because it's it's so easy to do that.

It just works. Is there anything special about the containers that you use in Kubernetes? Are they aware that they're even inside of or being orchestrated by Kubernetes? That it's up to you. Like, they don't have to be.

It's all for most purposes, no. They're they're just a standard ASP dot NET Core application listening typically on local host, and Kubernetes takes care of forwarding that port that is listening. So it's listening on port 80 probably in in the container or 4 5000 for ASP dot NET Core apps. And then it just forwards that out to an appropriate port and fuddles the traffic where it needs to go. The actual application doesn't have to care at all.

It can. If there's if there's specific things that it wants to get access to, you can absolutely hook into that. You can expose the underlying file system and things like that if you like. Generally speaking, it's you do you don't want to you want the app to be just stateless if possible. That makes things a lot easier and to just inject configuration using environment variables preferably.

So how much fun was it converting from dotnetframework to dotnetcore? It was fun. I mean, it wasn't too bad. In the actual fact, it it it wasn't too bad. And there's part of that was to do with the application, so I was converting.

And partly was was timing and so we were basically at that point just running web APIs using Owen and Katana, which is sort of a precursor to ASP Net Call. And so in a lot of ways, it was the same. You just had a startup class. You have your APIs controllers all all configured the same. They all look the same.

You have concept of middleware. So it transferred across pretty well. Biggest problem initially was lack of support for dotnetcore in the NuGet packages. Considering this was this was 2017, so it was a bit of a way back when we started this process. And we we also started at dot net core 1, and that that was just a nonstarter, really trying to migrate something.

Dot net core 1 wasn't happening. So we waited for 2, and then that was all good. And was the main mode of motivation so that then you can containerize the solution? Is that the main reason you do it? Yeah.

Pretty much. There was it it was it was multiple reasons, but there was Windows containers weren't really a thing at that point. And even now, they're still essentially inferior to to Linux containers and that they're so much bigger and, you know, chunkier. Linux is generally cheaper to run-in the cloud. There's no real reason to be on stuck on dotnet framework in that case.

If you're not gonna if you're not actually gonna be deploying to Windows, you need to move to dotnetcore. It was all yeah. It it was it was it was a lot of reasons as well as the fact that Microsoft is clearly, especially now with .fi, essentially saying that .netcore is the future. So it was just the way things would start to point, really. Yeah.

Unless you're stuck on web forms like I am. Yeah. I I'm trying I'm trying to get off them, but it took just got a lot of technical debt there. Yeah. It's difficult.

It's it's always that battle as well. It's like, is it worth migrating something? If it's something if it's if it's not interactive, you know, development, it doesn't seem worth it. But this was their main application that they were intending on with we're still working on now. So it's clearly was the right choice to make at that point.

What did you find as far as, like, what advice did you figure out for people that might be doing something like this as far as docs go? Because I got a mixed app where the API server is still in dot net, and then the UI server up front is in dot net core. And I find that certain things like, I was trying to look up how to implement filters, and that's, you know, where you've got a hook so all the pages go through that before they go to the actual page itself. Anyways, the docs I found almost bewildering trying to figure out am I on a dot net core or dot net doc about filters? Is it the right version?

I found it very difficult just to look up a concept like that because they weren't implemented exactly the same across the different versions and then the different families. Right. Yeah. So so that's some docs.microsoft.com, I assume. And so in the top left hand corner, I think it is, they have a a drop down where you can choose the which version you've ASP NET Core you're looking at.

Right. But I do I think I I'm pretty sure they still have the sort of dot NET Framework web API docs up there as well just in slightly different URLs. And I occasionally run into them, and I have no idea how I've got to them a lot of the time. So I I'm not I can't help you there. I'm afraid.

I I have the same problem. Okay. So it's not something I'm doing wrong necessarily on that one. No. I think because it used to be that the dot net framework, like docs all looked old.

And so you knew there, you want me to hold stuff, but it's smart and to all love. So, so, yeah, you can you can definitely choose the version of dot net core that you're looking at with the little drop down on the left. So that that's something that I do need to use occasionally. And what core are you on now? It sounds like you've start tried with 1.

I'm on 21 right now, which seems to be pretty decent. Have you made it to 3, or what what are you guys working with now? Yeah. So we have most of our things are on we're either on 31 or 21. But if you the the 21 stuff is mostly because they're applications we haven't needed to touch.

As soon as you come back to them, we're just upgrading to 31. There's a little bit of little bit of a jump you have to make between 23. It's not it's not hard to do, but you have to redo some of your authorization, and you have to reach that's sort of the way recent works. They switch to using endpoint routing in Netcore 3, which makes things a little bit different. But generally speaking, it should be it should be pretty smooth.

Our 2 1, 3 1 migration we did. A smallish app took me a day or 2, and that was it. So it shouldn't be too bad. And go to 5 from 3, looks like it'll be very easy. Oh, that's good news.

Do you know is 5 the one where they're gonna finally unify everything? So dotnet and dotnet core be the same or is that further out than 5? It's it's sort of. There's the that was the always the intention was it was gonna be 5. And I think they've unified the BCL for mono.

So all of I think they're using the same code base for mono and dotnet core now, but the Xamarin tool chain hasn't been pulled in yet. That was supposed to be a dot net 5, but that's gonna be in dot net 6, I think. That's the one I want. This is Xamarin tool. Dot net 6 is gonna be LTS as well.

So that dot net 5 is is is the current release, so you still got a year and a bit of support for it. But, yeah. It's actually amazing, how quickly LTS or support or deprecated stuff is happening these days. Not that it's a bad thing. Because like you said, the transitions aren't as significant as going from framework to core, but it's just it's it's interesting to see the new cycle.

Well, yeah, LPS studied for years. Right? Yeah. That's crazy. I mean, like, you look at dot net, was it 4.8?

That that was what you released 5, 10 years ago now, I think. So that's still being weekly supported. So And that'll be supported forever as well. Yeah. For sure.

It'll always be one of those it'd be like the Cobo of in 20 years' time, you know, there'd be an app that's on done that 4.8. Yeah. It's it's part of Windows. So they really can't get rid of it until, you know, they'd have a complete rewrite of Windows. Yeah.

Right. The Monday might that might happen, but not anytime soon. Why? You just you got me picturing myself in 20 years hunkered over a keyboard, writing dotnet, and people pointing at me like, yeah. See the old guy over there doing dotnet?

Yeah. He's he he's he's lost it. He's so far behind. Yeah. I'm probably the old guy who gets paid $250 an hour to work Right.

Yeah. Yeah. Because no one knows knows about it anymore. In 20 years, I hope I'm sitting on a beach in retirement. I won't be, but that's okay.

Oh, so, Andrew, we're on one of the apps I'm I'm using right now. It does have the 2 parts to it. It's got the API server and then it's got the UI server. And so on that, we're actually using Docker Compose to run the 2 different talk or court and then coordinate them. And even for that, there's a little bit of networking, like what's on what port and how they find each other and stuff.

Now have you used some of that? And then can you kinda just bring people through why you would move into Kubernetes then from Docker Compose? So Docker Compose is actually it's it's very similar in principle to Kubernetes. It's it's yeah. It's an orchestrator.

It connects pods together. The only thing that's sort of different is scale. I think it's not it's not intended necessarily for, you know, a production oh, I don't know. Actually, I'm not I'm not I'm not entirely sure if it is production or not. I use it locally for testing for integration tests, actually.

So is it so if I want to test ASP dot NET Core apps with a with a real database, so we spin up an instance of Postgres and we spin up, like RabbitMQ inside a doc post file. We're running that on the build server. So we run proper end to end tests using, docker compose. In terms of Kubernetes, like, it's it's essentially the same principle. It manages some of the things for you.

So you shouldn't have to worry about ports quite so much depending on how it but it's all once you get the details, sometimes you do. In my current setup because I'm I work on a Windows machine, but I'm running currently running a VM with with my Kubernetes cluster for local development. And so I have a bit of mapping back and forth between which which does require specifying ports and things like that. So in principle, it's very similar. Some of my colleagues, they are running on Linux machines, and they use all sorts of fancy tools that I don't really know how to use, which means they can get away with it.

They they do their development actually inside the Kubernetes cluster itself, so they don't have to worry about any of that sort of thing. But I haven't quite haven't quite briefed that yet. So if you wanted to, in your in your environment you're working in, could you just run raw just Visual Studio, press start and go, or do you need to be using containers to do your dev work? So I I do run more just Visual Studio and JetBrains Rider is the one I use. It's exactly that.

So the way I the way you've got it set up is I run a little reverse proxy in front of my Kubernetes cluster, and that checks to see if I'm running my local, like, Visual Studio version of the app. If I am, then it reads my traffic to that. If not, then I have sort of the older version of the, the app running in my Kubernetes cluster and it uses that. So it uses that for new services I'm not working on, for example. Yeah.

Because I mean, I found if you can run just directly from Visual Studio, then the cycle. So, like, debug, set a break point, find it, and then rerun again are just so much faster than if you'd have to do dev through a container. So I can't imagine, like, if you're if I I bet you're more productive than your Linux classmates. I I I don't know. I thought I I'm not gonna get into a contest like that.

No one wants that war. Yeah. Exactly. Exactly. One well, I was wanted to say one thing I've noticed and, of course, I haven't done this on a day to day setup.

But right now that Docker is integrated into Visual Studio, if your project or solution is Docker based, you can spin it, test it locally, get all your debug points, and it still be in Docker. It's just kind of off to the side. And the stuff that I've spun up and tested that, I found that it was it was pretty smooth. Right? It wasn't a difficult process to to get to get going.

That's not bad. Yeah. Yeah. Versus code has some interesting things as well if you're if that's the sort of thing you like to use. They have remote remote debugging and remote development, which is it's kinda mind blowing the way it works.

It's funneling up all of the context back across to your, to your machine even though it's running up in a cloud somewhere else that they even. The whole I haven't used to do it. And and Visual Studio online stuff that they're developing is it is mind blowing. Right? How does that work?

I actually used Live Share for the first time this week, so it was interesting. Cool. You know? It was a pretty good experience. You know?

It's it's not quite the same as, you know, remoting in because if you're trying to you show somebody around, you know, getting it to follow what you're seeing and so you can see everything was a little more difficult. But actually, you know, to get multiple people working on the same set of code, it was awesome. Do you think you still need, like, a team's session or something like that? Or or the screen shanks? They're not seem like a just a like a just like another session.

Go to meeting or Yeah. Something like that. Yeah. Yeah. If you're trying to demonstrate something to somebody, I think that type of, you know, share your desktop works better than than live share does.

But So, Andrew, something else that you've had to deal a good bit with is configuration inside of your applications. And I know that's something that we've all had to deal with and all spent weeks on and and, you know, banging our head against the wall. I find that with dot net core, it is significantly better, but there are still stumbling blocks. What are some of the ones that you've run across? So so with the migration thing, initially, there there's a fundamental problem of everything stored in web configs in in the dot net framework.

And then moving that across, you have to get all of that config out somehow. So I I actually wrote a little tool which converted all those web configs into just into JSON files because that's why f t net core tends to use. You can read you can read web config files directly, but it's just not idiomatic. Then at that point, you essentially get a dictionary of key value pairs, just string values to to string keys to string values. And so then the ASP dot NET Core version of things is to use strongly typed configuration, which means you essentially map those values to poccoobject.

It's a normal c sharp class, which works really well. If you can get your configuration going there, you can have layers of configurations. So you can have production environment settings overriding your sort of default settings, you can pull your configuration from all sorts of different places. So you can pull it from the JSON files, but then you also put it from environment variables or key vault. And in any way, you've got configuration.

You can generally pull it from. I saw someone write a, configuration provider that use it used, like, GPS coordinates, which was just as a comedy one. Oh, so you mean, like, based on your location, you get different configuration values? Exactly. Yeah.

Alright. Just some fun. I I wish it was in production, that one. Cool. Yeah.

I've recently been dealing with some configuration stuff in dot net Core myself. And it's and it's funny because I actually read one of your blog posts and took some of your advice to to resolve a configuration issue earlier this week, not even realizing we were going to be doing an episode with you. So So so I'm interest. What was what was the issue you're running into? Well, the application I'm working on, it's got multiple libraries in 2 apps.

Well, 3, an API, a web app, and a admin app. Right? And the web app had a bunch of tenant configuration inside of it that only it needed at the time. But we're having to expand the admin app to to allow for more permissions and more tenant access and things of that nature. And so it needed that chunk of JSON.

Right? And, you know, I talked with my coworkers, and we could duplicate it in the management app, which is not ideal because if it changes in the web app and you don't change in the management app, it blows up. Right? And we looked at, a suggestion that actually, you know, found your website where you could set up a separate project and then share that project with the other 2 and be able to to talk to the config that way. What we ended up doing was created a separate, shared settings dot JSON with, of course, development stage and production, put all the shared config inside of that, and that sits in the web app.

And we're actually linking it into the management app and and having it copy when it's newer. Right? And we had to do some some stuff in in, the main, function to make sure that everything found the JSON. But the it's it's it's one of those things, right, where you gotta find what works for you in your right situation. There are multiple ways that are going about it, but but that that would spit in a nutshell.

Is that sharing is that sharing done during build time, Caleb, or is it done during run time that you're going on finding the shared JSON config? It's, I believe it's on build. When you when you build it or deploy it, it's actually copying the version from the web app into the admin app. Okay. Yeah.

That's good. We got a similar problem that if the stuff being on web config is kind of a pain because after you get it deployed, if you find something you need to change, You gotta roll the whole app again. And so we actually had that happen just today where there was Oh, okay. It was pointed at a server that had an expired cert, and we wanted to go point it somewhere else. Well, it's in the web config, so that's not just a trivial little change of text file thing.

Right. Well and in this case, you can actually tell that it's a linked file inside the project. It has a different icon. Okay. So you know that it's getting pulled in from somewhere else.

So I like that. Yeah. Yeah. That's that's the exact approach we have as well. So we have, we have a shared settings with shared settings development, everything like that, which falls into all of our apps.

And then you have the app settings, which overrides those as well. Right. Yep. So you have those extra layers. Yeah.

So Awesome. Hey. We got it right. On one of my full framework applications, I took just about everything I could out of web config, put it in a JSON file, and then wrote a an in memory, caching provider that reads those JSONs. And then if I ever needed to change it, I could just change the JSON, tell the caching provider to clear itself, reload, and go from there without, extra time to make a change to web config.

Because web configs are peta, especially in IIS. Well, that's another thing where where Kubernetes sort of comes in here because, you know, the the sort of the the, oh, I don't wanna do another deployment. It's no big deal with Kubernetes. You just push it up, and it goes out. And it's it's sort of it's it's done.

That whole caching of JSON files reading into memory, that's pretty much why SDNET core does. So if you do need to you do need to get out there, edit the files, It's that that's exactly the way it works. So you're the best of both worlds there. Yeah. Hey hey, Sean.

I'm curious. What did you use as the trigger for your system to then realize that the file had changed and needs to reread its config? Right now, it's manual. Okay. Because that way, I can say clear now.

You know, I can tell it when to do it. It it doesn't actually look at the time stamp every once in a while, which would be an option. It could look at the time stamp on a file on a polling basis. And if it changed, it could clear and reload. But right now, I just do manual.

When you say manual, do you mean completely shut it down and restart it or something a little general? I have a I have a a management page in the application that I can go to for each one of the the cache, you know, configuration, sections. And I can say, you know, clear all the settings, or I can say clear by this section, this section, whatever whatever I changed. Oh, that's not bad. So it's it's developer manual.

It's not like manual manual. Right? Like, I'm gonna create a button. All I gotta do is click it, and I don't have to remember how it does it or what it does. It just does it.

Right? Right. So in ASP dot core, you, you you get file reloads sort of for free. It detects file changes, and it will repopulate configuration. But there's also an Ioptions monitor object, which you can use to trigger all sorts of things.

So you can manually update configuration and have that essentially send the signal throughout the rest of your application as well. Say, config's changed, refresh yourself. So you can then do similar things like that with some of the built in I option stuff as well. Yeah. Joel, one of the tricky things about that if you're using AM memory cache is if you're in a cluster, you have to have some sort of communication between all of them to say, you know, clear all of the ones in the instances, not just the the one.

I was lucky enough that we're just running on a on a an active failover type of system. So there's only one that is actually loaded at a time, so that made it a little bit easier without have to do messaging between servers. Mhmm. Mhmm. So, Andrew, for people that are moving from full framework into dot net core, what are kind of the some key, you know, things that they're gonna run into that they might not be familiar with?

So middleware is probably the first one. That's kind of the fundamental building block of ASP dot NET Core applications. If you're coming from full framework, then you're used to modules and handlers, and middleware is is the alternative to those. There's sort of a simpler version of modules in that you instead of having lifestyle, life cycle hooks that you have to pick up and know which ones are running where, It's just a linear list of middleware, and you can apply a function. So your request comes in, you apply a function using middleware, you apply another function using another middleware.

And so you sort of you'd build up this linear processing of the request. That's probably the first thing. One tricky part is when you get to authentication and machine machine keys. That's that's difficult. And to put it mildly, if you're trying especially if you're trying to do a gradual migration from ASP dot NET to ASP dot NET Core, there's there's a docs on it, but you have to follow that carefully.

Yeah. One of the things that I've thought about for migrating my full frame at work is to getting shared authentication between the 2. So it only had to log in once, and certain section of the application would be core, and other sections that I haven't rewritten yet would still be full framework. Yeah. And you can do that.

It's just it's not trivial today. There's I I believe you have to essentially move to the ASP NET Core authentication and retrofit your, ASP NET applications to use the a shim, which plugs across. And it it actually works as a sported scenario. It's just you have you have to make sure you get everything right. And I or maybe use something like identity server that might work as well.

Yeah. It's a similar thing. We have so the the first application I moved across to was identity server. And so that sort of worked fine because identity server is the only thing creating the cookies. So if you have identity server as being the only thing that you're using the data protection stuff itself, that can be a bit smoother if you're sharing.

Like, if you're doing cookie authentication between your different applications, that's where you have to start, you know, being careful. And I know you can, wire it up in dotnetcore to use, like, a third party provider or an Azure or Facebook, or you can use forms and kinda do it within your own app. Which method were you working with when you went to your when you did your core migration? So we were already running, an IHIP server. So each of the API so it sort of was that model.

It was the 3rd party doing authentication, but that third party was us. So the first thing I did was migrate that identity server from identity server 3 to 4 and do the migration to, ASP dot NET Core at that point as well. And, yeah, that that went pretty smoothly. I I started it too early. I started at NET Core 1 and had to hang around for sort of 6 months while it while we're ready for 2 to come out.

But it got there, and it was that that went pretty smoothly. That was pretty bleeding edge. Yeah. It was Lots of a bit bold. Yeah.

3 years ago, my team started Greenfield project using Angular release candidate and dotnetcorereleasecandidate, like, you know, right before the but it was a 3 year project. So by the time we we got to the end, we were on Angular 6 and dotnet core 3 dot 1. So Perfect. Right? Well timed.

Yeah. I feel like it was a mistake for them to have called dotnetcoreone.zeroy. They they probably should have named it 0.1 or or something because Well, they're you're fixing that now with dotnet5. Yeah. Yeah.

They used to be a Microsoft legend back in the day. That's like, if you wanted something stable, you never went on 1 and you didn't go on 2, you always waited for 3. I don't know if that still is that way. But in this case, it sounds like Netcore is somewhat that way still. Yeah.

It does seem to be. One of the big, changes from full framework to dotnetcore for me seem to be, you know, understanding how dependency injection works because you don't really have that so much, especially in web forms in full framework. Yeah. Absolutely. That's something you could plug in, and there were points to be you could plug into it, but the various different containers.

But, in s v dot core, it's absolutely it's completely built in. The framework itself uses dependency injection. So that's definitely something to try and get your head around. And it's it's a limited form of dependency injection as well. It's very specific.

It's constructor injection, which sort of means there's fewer concepts to try and figure out, but it's definitely something to get your head around. Yeah. That's one of the things that I learned. It's it's not like you have this dependency injection, you know, space that you can just call into. You have to call it in the in the constructor and then pass it down to everything underneath that.

You can't just new up something and say, get this object out of dependency injection yet. If it's not at the top, you have to pass it down. Yeah. Exactly. So you you can do that sort of service location if you need to.

You can inject an I service provider into your services. So if you if you really have to do it like that, you can do that pattern, but it's generally discouraged and it's less performance and it's can cause testing issues and things. So the right way to do it is, like you say, you declare in your constructor all the things you're going to need and then let that pass its way down. Ideally, if you shouldn't have that much that you depend on, if all goes well, I mean, if you're on web forms, that's maybe not the case. Generally speaking, you should try and only have a few dependencies if possible.

Otherwise, it's a bit of a smell. Well, is there anything else you you like to to tell us, Andrew, about your your journey from dotnetframework to dotnetcore and Kubernetes? There's so many things I could go into, but I think that's pretty it's a pretty good overview. Are you about dotnet5? Yes and no.

Like, it's it's there's certain parts of it which are very exciting. I think Blazor is very interesting. I think the performance improvements again, they've just done amazing things just by getting it faster and faster. But in a lot of ways for ASP dot NET Core, it's it's sort of boring and that there's not it's just gonna be the same. It's just gonna be better.

So it's kinda good. I don't have to I'm just gonna update things to dot f 5, and it's nothing's gonna break. It's just gonna carry on. It just looks fine. So Yeah.

I think I think boring is good, to be honest. I hate having to upgrade, and there's, like, a 1,000,000 breaking changes, you know, and things like that. So Exactly. So have you tried that with your project? Have you tried building on a dotnet 5?

I've I've done a couple of testers with the the RC versions that they've got now. I haven't haven't got anything in production or anything like that at this point, but I've done some tests and it's changed the packet numbers, changed the target framework, and it worked. That was literally all what all that was required. So it's a good sign. Do you think it's worth going to 5 or you reckon it's better to wait till 6 comes back?

Because that is LTS. Yeah. The LTS thing is a bit tricky because I've seen I've seen a lot of people say exactly that that they're not gonna go to 5. They just go wait to the wait for the LTS. The trouble is you should be updating your applications every month.

They have security fixes every month. So to actually stay supported, you still need to be updating even if you're on the LTS every and so in that Yeah. I also said that the LTS is this is still a lot less breaking changes, though, if you if you stay on the LCS version. Yeah. There is.

And I think the fact that going from 3.1 to 5 has been so easy means that I've got 5 because the breaking changes from 3.1 to 6 or 5 to 6 are gonna be the same, essentially. So you're gonna have to do do that same jump at some point. So I'll probably I'll probably move to 5 just for the benefits. You get the other options. You can use the extra bits that are in there.

The extra gRPCs for the h t v HTTP 2, I think, has got better in dot net five. There is various bits like that. Okay. So if there's nothing else, I think I'm gonna move us into picks. Alright.

How about, Joel? What's your pick for this week? Well, we have reached that time of year when you put away your summer bicycles because there's no more riding. This time of year, once you get any rain or snow, the trails just don't dry out. It's just too close to freezing.

So we're in the little waiting game now until actually they freeze over, and you can get out your fat tire bikes and ride across the snow in the trails. So if you wanna be on the roads though, you need something with spikes on it. And the dilemma there is there's so many different levels of how spiked the tires are and are the kind of spikes that will, like, wear out if you ride them on tar or are they kind of made for less snow and will work on tar? And there's a bike shop owner, Peter White Cycles at www.peterwhitecycles.com. I'll put a link here in the notes.

And he has an amazingly detailed article on the different levels of spikes for your tires, when you'd wanna use what level, and what kind of riding you expect to do. And if you do have one that's too spiky, how to be a little more gentle on them if you're riding across tar. It it was great. And so using that, I was able to pick out a pair of tires and get them ordered up for, for bikes for my wife and I. So we will be winter ready when those they're let's see.

They're on DHL shipping here. They're supposed to arrive on Monday. So we should be ready for the snowmageddon here and, by Monday. Again, thank goodness I'm not in the north. I don't that's awesome.

You know? I'm a little dis disappointed this year, Neil. Because of COVID and everything, I'm not gonna get to play hockey. So, it was really it was really fun last year that I played, so it's just a little too risky being in a high risk, medium risk group. My wife, myself, so I'm not gonna do hockey, so I gotta find something.

But You do. You gotta have something to get through the winter, Matt. You can't just sit down and read a book. So, like, that's not enough. Alright.

So why? What's your pick? So, actually, on the topic of, I guess, exercise, my so I guess a lot of people have started working from home, and it's actually been really, really good for me because I've kind of set up a a bit of a, like, a home gym. It's the first time in my life where I've actually started doing any kind of gym work, like, regularly. And it's and yeah.

So one thing I really recommend is to kind of just build your own gym, but and as I as I build it, I kinda realize that you don't actually need, like, that much equipment. I've only got, like, this tiny spare room where where we've got it. And the only thing I'm really using it is just the only thing I'm really using is just a a bench and and just some dumbbells. And so my pick this week is are these, like, adjustable dumbbells that I bought, and this this this has got this dial that allow you to kinda set the weight. And based on, you know, what you set, it's got some sort of mechanical thing underneath that allows it to change the plates really quickly.

So it's, like, super quick and just super convenient and just like this just like a massive space saver. So so yeah. Like, I'm I'm really enjoying, just regularly doing exercise, because I'm working from home, and these these numbers have been really useful. Alright. Keep it up.

Keep it up. Alright. Caleb, what's your pick? So I have something to exercise your mind versus your body. I think a while back, right, I I did a a book pick from blanking on his name.

Oh, Deepak Chopra metahuman. Right? And and, again, it's very theoretical and kind of out there, but it was interesting book on, you know, you and your brain and the universe and all this stuff. This book is, in a similar vein. It is really more focused more on the mindfulness side and the science behind it and how it can help your well-being.

It's called the the finders. Very, very interesting book. Dense, but good. The finders. Okay.

So, my pick this week is just this week, I got delivered a brand new Oculus Quest 2 VR headset. So I I I Well ordered it I ordered it fairly early. I ordered it from Walmart in instead of directly because that way, you know, something wasn't right or I didn't like it or something like that. I could take it back to my local store. It makes it a lot easier there.

And I actually got it, quicker than some people that ordered it directly through oculus. So I mean, it's a pretty nice unit. I'm trying to learn a new some what what are the popular games and things like that. So one of the games, you know, I'll start picking those probably as some of my picks. My first thing I was working on was called Beat Saber.

It's kind of like Guitar Hero, but you're like this you got these lightsabers, and you got to hit these things flying at you. So I hear it's good exercise too. Yeah. It is. And, yeah, I like the Oculus Quest because it's standalone, but you can still hook it up to your PC and use PCBR games.

And the screen door effect on it is barely perceptible. Only if you, like, really look for it can you see anything like that. So it's a nice powerful unit. It's, been really popular because it's out of stock everywhere. So that's what maybe I'll spend my, my winter, you know, keeping in shape that way.

Alright, Andrew? You can no. Sorry. Oh, go ahead. Why?

I was gonna say, do you reckon VR is kinda there yet, you think? So because I've always kinda thought it was more of a novelty kinda thing to to do you reckon it was like, did there is, like, a killer app that you can regularly use? Yeah. It's definitely it's it's getting a lot more popular. You know, you can watch Netflix movies on it.

So, you know, you don't have to sit on your couch and have your TV to watch Netflix. You can just you could lay on the floor. You could lay in bed. Whatever. You could watch Netflix that way.

But I think it's definitely getting a little bit better. You know, I would like the the field of view to get wider. I think that's something that they could really improve on it because right now, it's kinda like looking through a set of binoculars, somewhat, but I think it's definitely definitely getting better. Exciting. Alright.

So, Andrew, what do you have for your pick? So I got I got a couple for you. So the first one I got is a is a Chrome extension for which is called Octo Tree. This works on when you're on GitHub, it gives you a nice solution explorer on the left hand side of your screen. Let's say you got a proper file browser.

You can click around. It's got a free version, and it's got a pro version, and it is just invaluable. If you're someone who's using GitHub all the time, I find it's great. That's my first one. And my second one is a game which I found called Streets of Rage 4, which is a throwback game when I used to play Streets of 23 and on the, Mega Drive.

And it's a new game that is it's just great fun. It's just a side scrolling, but you can have coach couch co op so you don't have to be online to be playing other people, and it's, yeah, just great fun. Yeah. I remember Streets of Rage from from my youth, I guess. So what is this like a rewrite or is it just, like, a Yeah.

Yeah. It's it's a new game. Yeah. And it's even it's got it's got all the same characters coming back and things like this. It's just it's great fun.

They even have a copy for the Switch. So Oh. If you own a Switch like me Caleb got it in there somehow. There you go. Right?

Switch in there. Go get your streets arranged. Alright. Great. Thanks for joining us today, Andrew.

If the listeners wanna reach out to you and get in touch with you, we put a link for your blog in the show notes. But is there any other ways that if they can reach out with questions? Oh, yeah. It's, on Twitter as well, Andrew Locknet. Like I said, it's my blog, and just on my book forum as well.

You can, talk to me through that. Awesome. Awesome. So thanks for your time, Andrew. I think we have such a really great episode.

So, hopefully, lots of people get something out of it. I hope so. It's good fun. Thanks, guys. Hey.

You're welcome. Thank you. Thanks, Andrew. Thank you. Alright.

And we'll catch everybody on the next episode of adventures in dot net. Oh, one last thing. If they wanna reach out to the show, please give us feedback on Twitter. Reach me at dotnetsuperhero. Dun da da da.

Right? Bye bye. Bye, y'all. See you.