Iris Classon - Migrating ASP.NET Microservices to ASP.NET Core: By Example

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/9781484243268 . For more detailed information, please visit http://www.apress.com/source-code .

I remember when I was straight out of school how excited I was whenever I came across something new a new language, framework, or tool it was always fun and exciting to play around with it. After many years as a programmer, I still get excited, but I am also increasingly skeptical and hesitant to invest time in new things as Ive seen so many come and go and not survive the test of time. This also goes for migrating existing systems. I used to want to rewrite everything, and I probably still do, but Ive also seen how expensive this can get without necessarily yielding a better code base or system.

When .NET Core was first announced, I was enthusiastic but skeptical even a bit cynical. I had jumped on the portable class library train early on and had my share of fun with that, and therefore the promise of .NET Core wasnt something I was going to believe until I could see it delivered. ASP.NET Core was the first framework to make use of .NET Core, and although I could see many benefits early on (often a result of getting to rewrite something that has collected technical debt over time), I wanted to wait and see where this would go. As the adoption rate increased, along with the contribution rate to this open source framework, we started discussing at work if ASP.NET Core could be something for us. The problems I came across while trying to answer that question were that information on ASP.NET Core was lacking, was referring to older versions, was scattered, inconsistent, and most importantly lacked real-world examples of doing large-scale migrations. If you, like me, are a natural skeptic, I can imagine that you would lean more toward a no in terms of migrating, even more so if you get lost in the information and opinion jungle, we spend most our time in. My aim with this book is to foremost show a real-world example, with actual code from our system, of a migration from ASP.NET to ASP.NET Core neatly organized in easy-to-follow steps. While the book wont be an authoritative guide on ASP.NET Core (there are plenty of excellent books that cover ASP.NET Core), it will cover what you need to know to make a decision on whether or not to migrate. It will cover your migration options, how to do an analysis, and prepare, migrate, and maintain your web services. The book also has an extensive list of resources and tools that can come in handy, as well as plenty of examples of both problems and solutions that you might come across. This book has all the information that I was struggling to find, and my hope is that this book will answer the majority of your questions and let you focus on building awesome software be that with ASP.NET Core or not.

When I first wrote the outline for this book, I didnt plan on spending too much time explaining ASP.NET Core. I would assume a certain level of understanding from you, the reader, and wed hit the ground running. But, often as developers, we are pressed for time and decisions are made when we start implementing, with good intentions to at some point take the time to dive deep in a new technology, but as we all can attest, sometimes we never get around to it. Therefore, I want to take a little of your time in the beginning of this book to share my insights and cover some of the more valuable aspects of ASP.NET Core that you might not be aware of. Hopefully, this will allow us to create a solid base for the migration that lies ahead of us in this book.

Besides understanding .NET Core, .NET Standard, as well as ASP.NET Core, I also want you to have an insight into the history behind the Microsoft web development stack and how we ended up with ASP.NET Core. And an important part of that is covering the difference between ASP.NET Web Forms, ASP.NET Web API, and ASP.NET Core. Not to mention the difference between the two project types: ASP.NET Core (.NET Core) and ASP.NET Core (.NET Framework).

Lets see if I can condense the history of ASP.NET Core and how we got here. If you have been around for a while, you know its a long story that can be tracked back to when Classic ASP (Active Server Pages) was a thing, and maybe even further back to one of Microsofts first inter-process communication methods , DDE (Dynamic Data Exchange) , in the late 1980s. Classic ASP was a revolutionizing way of dynamically rendering server-side pages with baked-in logic, and later evolved to ASP 1.0, followed by ASP.NET and Web Forms in 2001. In 2009, ASP.NET MVC was released as a (much-needed) alternative to Web Forms. Simultaneously, communication methods evolved from DDE to DCOM, to .NET Remoting, to ASP Web Services in early 2000. In 2006, WCF (Windows Communication Foundation) was released, tying together the different options and supporting a variety of communication standards. WCF was intended to be a unified programming model for building service-oriented applications that had explicit support for service-oriented development. However, WCF had some limitations in regard to REST (Representational State Transfer) support. The WCF Web API project was intended to fill the gaps and eventually evolved and became what we today know as Web API. Web API was quickly embraced, partly because it tied in nicely with the ASP.NET MVC style of programming. Not so surprisingly, when ASP.NET Core was written, as a rewrite of ASP.NET, the two were combined (Web API and MVC). But how exactly do .NET Core, .NET Standard, and ASP.NET Core fit in?