What .net Core 2.0 means for DNN

DotNet Core 2.0 is out (see official post) - and this is an important milestone for the .net ecosystem and DNN. I would like to bring you up to speed on the basics and why it matters to DNN.

Brief Summary of .net Core 2

So .net Core 2.0 is the next version of .net Core - and it delivers a cross-platforms .net  for all kinds of devices (PC, Mac, Android, iPhone, Linux, Raspberry-Pi, ...). So it's a lot like Java - just freshly built using more modern paradigms in terms of packaging etc. which should make it faster, easier to develop with and lighter. In the Microsoft release it doesn't just contain the core framework (kind of like the operating system), but also:

1. Entity Framework Core 2.0
2. ASP.net Core 2.0

So it's the Microsofts future oriented platform for developing solutions - with a very strong focus on data input/output and web based scenarios resulting in HTML, XML and JSON. Which is the world DNN lives in. 

Note that there are also some other very exciting new things which I won't go into right now, as they are not important to the DNN on .net Core discussion.

More Important: .net Standard 2.0

The big magic is actually .net Standard 2.0. I really must say that Microsoft isn't good at naming things, because most people overread the difference between .net Core and .net Standard, believing it to be the same thing. They are not. So here's what you really need to know - it's important for our future:

.net Standard is a convention of .net APIs - like the DateTime object and the properties and methods this DateTime object has. So any code which is written for .net Standard 2.0 can be compiled to different types of .net, like .net Framework 4.7 or the latest .net Core. The new Standard 2.0 contains around 32'000 such definitions, and is very, very complete. 

We can now use "old" .net DLLs in .net Core

This also means, that already existing and already compiled DLLs which only use these commands, will automatically run on .net Core. This is correct: existing "old" code will run in .net Core 2.0 without recompiling. 

Cool Example: the Zip-library in DNN, SharpZipLib, can now be used in .net Core 2.0 without any changes!

Let's run DNN on .net Core 2.0!

Unfortunately this won't work yet. The reason is that these 32'000 APIs don't contain any WebForms APIs, which DNN relies on. Note that this is also the reason, why only 70% of NuGet packages are compatible - the incompatible ones contain WebForms or other desktop-APIs which don't exist in .net Core 2.0 or .net Standard 2.0. Here's what's included ATM:

BUT we're getting closer to getting it to work, here's what's already happened these last 3 years:

1. DNN has been dramatically slimmed down to only have very few modules included - so the amount of code to maintain & migrate is shrinking
2. The DNN UI has completely changed to being JavaScript and REST-API based, so there is almost no WebForms UI components left in DNN. I believe the transition is only 80%, so that there still are some parts left.
3. Many DNN components like 2sxc or DNNSharp have long ago moved their UIs to the JS/REST stack, so many components are actually much more .net-core compatible than you may think. 
4. Some (but still very few) DNN components have already moved their internals to .net core stacks. For example, 2sxc has moved the entire data layer to EF Core 1.1 and the dependency injection is also .net Core, so these components are ready when DNN is.

This is Missing for DNN to run on .net Core 2.0

If we look at it from far above, here are the main pain-points left to manage:

#1 Razor based Skinning

To drop WebForms, we must create skins and content-templates based on Razor or other .net-core compatible technologies.

• Content-templates are simpler: 2sxc already uses Razor or Tokens and many other content-management modules like OpenContent have similar solutions ready. 
• Skinning is still completely unsolved - but I must admit it doesn't look very difficult, someone with the skills would just have to invest ca. 2 weeks for a proof of concept and about 3 months for remaining details like security, helpers, in-page buttons etc. 

#2 DNN APIs

Do drop WebForms, the DNN APIs would need some dramatic changes, because often they internally use WebForms objects like Server or Request, which are different in WebForms and MVC. These differences are fairly extensive, and the problem is that such APIs are used by third party-components, which will break if these internals are changed. There are a few solutions to this:

1. Provide a V2 API, which uses the plain ASP.net-Stack (called MVC, but the name is misleading) - this would allow a soft migration with two APIs on .net 4.7 and only the newer API on .net Core 2.0
2. Create a Shim which basically clones the missing objects on .net core. This would allow for a compatible API to be used - and internally the system would use either the .net 4.7 objects or the shim based on the environment. I must admit that this feels elegant, but I believe it will be a desaster, because it introduces a new layer of complexity and tries to hide the truth, which is that the new ASP.net ist simply different at many levels. It would also stop us from really leveraging the power of new features, as the code would still look like .net 4.7.

I'm a big fan of the 2-API solution. This would also allow DNN to clean up the API, providing a more limited API which will be easier to maintain in the future (the current API is fairly large, and often not necessary but used nevertheless, because people find code-snippets and re-use them).

#3 URL Handling

URL handling in old WebForms is very different from the new ASP.net. The funny thing is that this is one of the smallest problems on DNN, as DNN URLs have always been emulated by the CMS, and rarely represent real paths on the server. So www.mywebsite.com/home never existed as a file anyhow, and replacing this layer will take some work, but no magic. 

#4 Third Party Components

This is the hardest part, and the chicken-egg problem. Almost all third-party components will not work on DNN Core, because they were built using WebForms paradigms. As of now, I believe all third party components will need some kind of refactoring. Modules which have very little DNN-API-Use or which avoid WebForms paradigms will be quicker, but others will take much longer. For example, 2sxc is completely decoupled from DNN, but has a DNN7-Connector so it runs in DNN7 to DNN9. But for DNNCore we would have to create another connector layer, which will probably cost us 2-4 weeks of work. 

Most other third party components will need much more work, since most developers have very deep ties to the underlying APIs and still rely on WebControls for the output. For example, I would estimate a component like DNN Blog to require ca. 4-8 weeks of work, whereas commercial components are hard to estimate, as their code cannot be reviewed. 

Preparing Components for .net Core

Important: Components don't have to wait for DNN! It's a common missconception that the components must wait for DNN to make the first move. But they don't - everything we need to do is already known. Here's your quick JAR checklist:

1. J for JavaScript: migrate all UIs to use JavaScript instead of WebForms - do not use Razor, as it's not practical for this
2. A for API: use WebApi instead of PostBacks for any kind of server interaction
3. R for Razor: use Razor instead of WebControls for the bits of HTML which the server must still generate, mostly in output-pages

This can - and should - be done now, ahead of DNN. It will make it easier for DNN to make the migration, knowing that the components are ready. 

TL;DR

In summary: please start migrating any modules to the JAR model now. It's IMHO the only way for our awesome DNN to migrate into the future.

Best wishes from Switzerland,
Daniel