 Hi, this is Kathleen Dollar from the.NET Core team at Microsoft, and I'm here today with Rich Lander to talk about some tips for moving to.NET Core. How are you doing today? Great. So the way I kind of think about this talk is, I often meet with these big customers who come to campus and ask us for guidance. I'm like pushing.NET Core, and they're like, Rich, don't lie to me. Tell me the truth, tell me how it really is. So this is supposed to be how it really is talk for moving to.NET Core, right? We're certainly aiming that direction, and so we're going to be going into a few places you might not really expect us to go, including spending some time on making that decision about whether to go to.NET Core and when to do it. So let's start out. And no lying. We're not going to lie to you. We're going to try really hard not to lie to you. So we're going to start out like I said, should you do it in the first place? Should you pour it to.NET Core? How are you going to prepare for it? And then some tips about porting it, but that's actually not the biggest part of the talk. The biggest part is the setting up, which I think it's going to be the experience you have as well. Kind of like how to make the plan. How to make the plan? How to detail that down to being able to carry it out. So before we do that, I think we should start with why do it in the first place? What's good about.NET Core? Because then we're going to talk about some pain points. And I don't want to do that without first saying, why bother? And so these are some of the benefits for.NET Core. We think for a lot of people, the side-by-side installation, which is that's installation of the runtime, that also can be one of the pain points. But it's a benefit in that you can have two applications in the same space, two applications on the same VM or the same machine, and they're each running their own copy of the runtime. And don't interfere with one another? At all. Not at all. All right. It's also faster. It's cross-platform and open source, and it will be getting new features while.NET Framework is now stabilized. Yeah. It's faster though. One thing we actually forgot to say, it's faster and uses less memory. It does and that's super important because when you actually measure just one little piece of code, you can see the speed of that. But what's much, much harder to get a handle on, is how the allocations going on in the background are increasing your load for GC, and then you wind up with GC pressure and kicking in a GC. So allocations are super important for a couple of reasons. That's the main. But yeah, the simplest thing is, if you have a hosted environment with servers, you can pack more apps onto the same machine. Right. All right. Let's go. All right. So you can find out more about the .NET Core 3 features at this blog post, which did. So since Rich wrote it, he's pretty excited about that. So should you move? Big question. All right. We're going to look at a couple of considerations, and we're just going to walk through each of these. Yeah. There's just one tiny bit is, I've been talking to customers on campus, but also I've been to customer sites. I think mostly in the United States, but I'm moving to other countries too, definitely in other countries. This question is very real, because different companies work different ways, but a lot of times you have a higher level manager who's resistant to change, and they're like, show me why we should really do this, and is the risk that is it low? Yeah. So this is some of the things you can do to establish specifics about what it's going to take and where you're going to get value from it. We definitely encourage you to go. If you can find the value, and that's why the benefits slide is super important, and I hope that when you come back and consider this, you will explore the great things about.NET Core, but not in isolation. You want to look at those alongside the cost. So before we go there. Can I just say one more thing? Yeah. Back to these managers that are resistant that you couldn't have to prove this to. I was at this one customer, let's say I think it was in last spring, and we did this project with them, and the management was resistant, and then we did this prototype. We spent like a day upgrading their app. We were actually able to give them real numbers. They were like, whoa, this actually looks pretty good. This was back in- Was it performance numbers? Yeah, it was performance numbers. This is back in preview three. Yeah, and that's better. I've done a core. Yeah, well now we ship too. Yeah, it's great. Okay. So before we get into some of those specifics, I do want to look at some other concerns that are kind of things that aren't the right reasons to make a decision. So let's take a quick look at these. And so the first thing is, yeah, if you're worried about .NET Framework not being supported, that's not in and of itself a good reason to move. So it will be supported for a very long time. Yeah, I agree. I understand that in response to that, you might say, hey, but there was this thing, whichever thing it is, that comes to mind. And .NET Framework is actually really different than anything that's been out there before that's gone undergone a similar change. And the first reason is that it's a Windows component. And so it's a critical, it's part of Windows. Windows needs it. It's literally on the Windows DVD if we still have those, the DVDs. For those of you that remember what a DVD is. Yeah. So then also it's used heavily within Microsoft and it's in fact Visual Studio. Yes, that's an example. Visual Studio is a .NET Framework application right now. So and then the biggest reason I think is that this is not something, this change to .NET Core and .NET Framework splitting a bit here. It's not only to freeze up to do great things in the future with .NET Core. It is definitely to do that, but it's also to say there are, oh, we don't even have a good estimate of how many apps they're out in the wild. Millions. That's working. It's working and it's getting things done for people. And so stabilizing that aspect of our ecosystem is important to us and important to being able to set it for the future with this base of existing apps being solid where they are. So I think it's super important to think about there's great reasons to go to .NET Core, being afraid that we're going to pull the plug in .NET Framework. Is it one of them? It's not one of them. Yeah. A couple of other things. You need NT services. Cool. You can do that. Sorry. Oh, and then licensing. So if you're concerned about our license, we are MIT. And we think that that is a good license for business. And if you want to hear more about that, let us know. And we'll get rich to write a blog post. Yeah. I'll just say one tiny thing about that. And this is where I've talked to several customers, some of them very, very large. So our source is MIT, which is the part that's friendly to business. But a lot of customers want to hear from us that they're still installing Microsoft provided software. And when you actually go download .NET Core from the website, that's actually like a Microsoft build. And if you want to think of it as a Microsoft proprietary product, feel free. It is built from open source, but it's supported by Microsoft and it is a Microsoft product. So there's nothing scary there at all. So if you want to use the word open source, you can, some people really love that and it's true. If you want to use the word, like, you know, Microsoft certified and supported, you can use that word too and it's also true. It's both true. It's both true. We sign it, we also provide the source code for people like Red Hat to build it separately. So we work really hard to be on both sides of this list. We're kind of doing all the things. We think it's great to be both at once and we think we're hitting that. So Microsoft is still, you know, we're still, nobody's going to be thinking crazy. We're still a commercial software. We are watching it very closely. We approve every commit. We're watching it very closely. It's very safe. At the same time, we do take commits from the community. We're thrilled to do that and I think it's worked out really well. Okay, so let's get into those specific questions. And the first one is your application and active development because if you only open your application occasionally and it's to do very small things like change what the current year is, you're just not going to gain a lot. The new features. Well, there's the other side of it is maybe it's an enormous app that has a very slow rate of change. That's probably the one that you most want to think about is if you only have this one developer left who's working on this mega app, then that may not be the best thing to move to Dynacore. It has to be under active development and you kind of want to have some kind of team. And I want to kind of clarify that. It's because the active moving will put it under active development. And so if that's sensible, hey, then that's great. That's actually a perfect way to put it. Yeah, it's going to force it. So we'll talk a little bit more about thinking about that. The frameworks, we have some stuff that's not going to be there. Most things are there. WinForms and WPF there now in 3.0 and then there's the Windows compatibility pack will bring some more things in. So there's a number of things that are actually there, but there's some important ones that aren't going to be there. I think a couple of things of app domains are there, aren't they? Or is that completely? No, so the app domain type is there and some of the basic functionality, like for example, getting the list of assemblies, is there, but the fundamental concept of app domains is definitely not there. Right, so it doesn't make sense to do things in a particular way on Dynacore for some of these things. And so they're just not there. So that's, if you're in, if you're WebForms, you're looking at a pretty deep reconsideration of your application. Can I say one more thing about the last slide? You can always say one more thing, Rich. So one of the things we've been doing over the last years, last few years is, it's like, okay, we're going to bring more functionality into Dynacore that you used in Dynaframework and kind of our, and we definitely did that in Dynacore 3.0. We brought Windows Forms and WPF and those were obviously very big projects. That is the end of that journey, the journey of bringing more Dynaframework functionality into Dynacore. So we feel like we did a great job. We took a ton of customer feedback. We added, like if you look at between Dynacore 1.0 and Dynacore 2.1, we added 40,000 APIs and that's not even including what we did with Windows Forms and WPF. So we feel really good about what we did, but this is the end of that particular phase. So there's all these things on the right-hand side. Those are not the next candidates we're going to bring back. Those are going to remain on that list on the right. And now we're going to go do other things, but not more Dynaframework functionality. Right, so waiting to see if Web Forms or WCF. Exactly. Sorry. Yeah, it's just not in the cards. So, and there's some good reasons for these. None of this was arbitrary. It was all, we took a very deep look at all of these things and how it would impact Dynacore and where we felt that it was not going to come forward with enough compatibility without being inconsistent with Dynacore, it went on this list. So it's, yeah. All right, so the next thing is to talk about support policy, doesn't that sound exciting? Yeah, I remember when I first, before you worked here, I was telling you about the support policy. Do you remember that? Yeah, yeah, yeah. That's the MVP summit. Yeah, and I was like. I was talking to you and Julie. Yeah, so the support policy is different for Dynaframework and Dynacore. So I'm going to talk here for a minute about the Dynacore support policy. And a year ago, in December, not quite a year ago, we released 2.2 and then 3.0 we released, like right now, we just released it. Yesterday. That's where we are. So let's look at the schedule going forward, because we've announced the schedule. Yes, which is awesome. And we think that's a great idea, so you know what it's going to be. So first of all, in November, we're going to have 3.1 and we're calling that LTS, which is long-term support. And I'll explain what that means. Coming up after that, we're going to have a major release every year. And every other year, it's going to be LTS. So this LTS thing is pretty important. So you can think of it like a second train and along that second train track, we have LTS versions. And one of the reasons that this visualization is kind of important is that it's hard to jump across the track in between. So for example, if you're on .NET 5.0 and you want to get back to 3.1 because you want to jump across halfway through, you have to go back to 3.1, which may not be an easy thing to do. So your best bet is to pick one of these tracks and then be able to commit to it. That's the best way to go about it. So let's talk about the specific support policy and here's a link to it. It's, you can go read it and everything here is a visualization of that. This is, it's true, this is my picture. So first of all, what does LTS look like? The current LTS today is 2.1. And we have announced a special date for it, which is August 21st of 20. It was released 2018, so it will go out of support. August 21st, I think that may be 23rd there. I may have a typo on this slide of 2021. Well, that's a minimum. Yeah, it depends on when, yeah, it depends on when we ship 3.1, but I guess, I guess that will be the date actually. Yes, yes, it will. Yes, it is a special date for that one because it was, we were settling on the final policy right then and we've been discussed for a while before that, but that's when we committed to the policy, so there's kind of a special date on that one. All of these are minimums. We could extend support further. It hasn't been our pattern, so I certainly don't think you wanna count on any of these extending beyond these dates. It might happen. So 3.1, it's three years from the date of release. It's actually three years from the date of the release, unless we run late on the next release and then we expect to go a year past that, but the easiest way to think about it is three years. That's the easiest way to think about it. So what's the current then? That's what LTS does. Current track is 2.2, we'll go out of support on December 23rd of this year. Detonate Core 3.0, which is releasing today will go out three months after 3.1 ships. Go out of support. Go out of support, sorry. Yes, go out of support. Three months after 3.1 ships. We don't know exactly what the pattern will be around 5.0 and the reason is that we don't really anticipate point releases at this point in the 3.1 timeframe. We don't really expect. Meaning a 3.2. A 3.2, exactly. We don't have any plans on that. There's no plans for a 3.2 or a 3.3. We don't know what our plans will be for 5.0. So we could see a 5.1 or a 5.2. We just don't know yet. So that's what we can look forward to. So you can see that the support is significantly smaller and this is not to scale. The stuff on the left is a bit more spread out than the stuff on the right. Yeah, so the thing I'd like to add on this is if we look at say 3.0 to 3.1 in particular, the level of kind of migration cost between those should be extremely low. Absolutely. So in terms of the thing that I would be doing if I was trying to interpret this, like if I had a team building an application, I would just always stay on tip. I would just stay on the latest version and then my team would get all the benefit of all the latest features. And I know that the Microsoft team is trying to make those as compatible as possible. And probably my server costs are gonna be lower than someone else's who doesn't stay on tip. Yeah, this is absolutely true because not only are you going to be getting the new features, so nullability is, you would get that if you are on 3.0 right now, if you're in the LTS 2.1, you don't get nullability, you don't get async streams. All the great stuff you're hearing about, you don't get F sharp 4.7, all the great stuff that we're doing, you don't get that. Or the new Docker limits support that we added in 3.0 or the much smaller SDK that's in 3.0. Right, performance, there's a lot of reasons to stay on the tip. However, we feel like it's important for it to be your choice, not our choice. So this is why we offer this alternative commitment that occasionally, once every couple of years, we'll mark one and say we'll support it longer. So if switching versions is a problem for an individual project, this isn't a company-wide decision, it's per project, if that's the right thing to do, go for it. We are running a little bit behind, so we're going to have to kick it up a bit. I just want to say that one more thing real quick is the dot-net framework. The arrow just goes right across. It just goes, it keeps going, okay. So we are going to kick it up because I realize that we're running a bit short on time. We're just talking too much. Yeah, we are, I'm talking too much too. So one of the things is that you're going to be managing your own security updates for dot-net core, and in dot-net framework, the security updates are part of Windows updates. We're not going to go deep into this. The reason it's sometimes on you deploying is that you had to make sure there was the right dot-net framework on that machine that you were deploying out to, but you always have to do that. Make sure it's there, and it won't be there from Windows. Windows update. From Windows update. Windows, it's just not part of Windows, and there's good reasons for that so that we can change it and we can move forward. Third-party dependencies. Ask, how do we ask today? We go to search engine. Go for it. Third parties mostly have a statement. Now let's prepare. So, preparing to dot-net core is going to have a couple of steps. We'll walk through these again. The first one though, you just want to move to a recent version. If you're back on 4.5 or even before, oh my gosh, any problems you have moving forward, settle that first. Right, because there were a few points in the dot-net framework journey where we made significant changes, breaking changes, and you need to make sure you've gotten through all of those waves of changes because 4.72 and later are the most similar to dot-net core, so that's really why it's so valuable to validate that your app runs successfully on 4.72 or 4.8. Yeah, and then you want to know how you're going to validate success. What does that look like? Test coverage is one great number here, but so performance metrics is going to be important too. We expect it to get better, but checking that's always a good idea. Yeah, so back to those stories that I told earlier. So those developers that I talked to, they had performance tests, which they ran on the old stuff and the new stuff, and then they just did basic arithmetic to figure out which one was faster. But if you don't have those things, then you're kind of just a finger in the wind setup, which is not really science. Yeah, you definitely don't want to be there. So evaluating architectural changes. There's a couple things here. We're going to bounce through this because I think the slide to come back to it, this is deep consideration on your part. We're throwing this out there, and then you can come back to the slide and say, yeah, I want to spend more time on that topic. So first of all, if you have a library that can target dot-net standard 2.0, you absolutely want to do that. That's what's supported on dot-net framework. You want to limit architectural changes during the port because if you say, oh, I'm going to change a bunch of stuff and port at the same time, it really made the whole effort is going to be crazy. It's going to be hard. And then it won't be obvious to everyone why the build is breaking. Is it because of my migration or is it because I actually made some bad plans or it just can be a mess? But before you move, you might want to look at a couple of things and one of which is the isolation of concerns. So if you're using WCF for one task, but it's spread all over your application, start by taking all that into one library so that you can replace WCF in just one place. That's what we mean by isolation of concerns. And then there's something called the dot-net portability analyzer. And I'm going to walk through this just real quickly. It's a Visual Studio download. You can get out that link. It's an extension to Visual Studio. And after you run it, you get a spreadsheet. And I'm going to start with a portability summary. And I did two. These are both just standard dot-net framework applications for WinForms and web. This is a web MPC. And let's look at the difference. Right here, this number 34%. That says we're in trouble. ASP.net MPC, you don't just do a straight port on it. It's different work. We'll talk about that in a second, but you can see that number. If you look at... Get it back here. If you look at WinForms, you see 77.77%, which is still a little bit low, but you can immediately go and find out what you've got. And I think that I just don't have the right SDK here and that there's some... The work that I can do that's going to move that over. The way that you define Windows forms itself changes the way the project file looks between framework and core. And I think that's what causes this because... Well, yeah. You can see almost all that stuff is supported. Actually, all of that's supported. So this one was probably pretty close to 100%, actually. It would have been except that we changed from a dependency to the SDK. And that's what caused the problem. So I'm showing you this because we want to again show you where you might trip a little bit and when you see this, don't panic and think you're not going to be able to move WinForms. It's just that the way that we define it isn't this tool doesn't handle really well. All right. So portability analyzer? Yes. All right. So we did a little demo of that and going back to porting your app, what do you actually want to do? Yeah, this is the active phase. And we are updating these apps today. Docs. Docs. I'm sorry. We are updating the docs today. Right now there's a PR. We don't know the state of the PR at the moment. Right. But within the next 24 hours it should be merged and then the right content will be at that link. Right. So you want to choose the project to port. We recommend that you look at the ones with least dependencies and test projects early on. And then you'll change project files and code differently. Test projects early? Is that obvious? If you move early with them it's going to be, life will be better. Actually, so I don't think it is obvious. Oh, okay. So yeah, this helps shine the light on what the heck it is you're doing. So I think this is great advice. All right. Project files. Project files is going to be a big headache for you. We'll just tell you that up front. It's going to be a little bit of a headache on this. Right now, they actually showed something in the keynote that I just want to mention. In passing, Olia showed a tool and there wasn't much background given on that. And what I want to clarify is that's a prototype that is really got, it's going to work in some easy cases. And so we're trying to understand how you perceive that process of moving your project file. So we have normal channels that you can give us feedback on that, which is the upper right, give feedback in Visual Studio, or if you'd rather go to githubrebo.net.core, be a great .net github.net.core, slash core, slash core, slash core. All right. So you want to create a new project file and then allow globbing to bring in your actual files. That is standard libraries are ready to go. WPF WinForms, console, class library, they should be pretty straightforward. ASP.net is going to be a little bit harder. You're going to need to replace certain aspects of that in the IS integration pieces. Yeah. And you're not just going to want to try to make this a straight port. This is going to be taking the new ASP.net core, which is vastly improved. It's a fantastic piece of work. You're going to want to take that and then move your old code into it. I realize now that we made the slide slightly incorrect. It shouldn't say plan to replace IS integration. ASP.net core also has IS integration. It's just that it's slightly different. Right, right, right. So integration only in that where you are counting on these features, then they're going to be different. Yeah. And we still, you're still going to use IIS. You're right. We had a poor, and we have one more slide and then we're going to get to try to take some questions. We ran a little bit over here. Yeah. So web forms, we suggest that you look at Blazor. And the reason for that is that Blazor is an event model similar to the way web forms is an event model. And so if you go to Blazor, it's going to be easier for you to take your ideas forward. So should we move to questions? I think we should move to questions. I think we should too. Yeah, yeah, yeah. Are we at that time? All right. Okay, so moving to questions. So Rich, I thought this one would make you smile. It doesn't look like a question to me. Rich Lander rocks. So looks like you have a fan. Wow. The first one. Let's see. Okay, so let's look at real questions now. Okay, let's see what's a good one. Is .NET standard going to move to V5 when we get .NET 5? I don't think we know. Well, I think the first answer is that's unlikely because we have a different numbering scheme for the two. Oh, do you mean will there be a .NET standard? Do you mean what the number? It just says whatever the question was. I don't think it'll be V5 and we haven't figured out our .NET standard plan going forward. Okay, let's move on to the next one from Bill. So in addition to the releases on their product plan, can we expect bug fixes and other updates on a fairly frequent basis? Yes. It's basically monthly. Yes. Monthly, great. That's easy. I like that question.