Products

Solutions

Resources

Partners

Community

About

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.


What .net Core 2.0 means for DNN (opinion)

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


Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 800 DNN projects since 1999. He is also chief architect of 2sxc (see github), an open source module for creating attractive content and DNN Apps.



Read more posts by Daniel Mettler

Comments

Jeremy Farrance
Great article!! Maximum appreciation!!
Jeremy Farrance Tuesday, August 29, 2017 6:39 PM (link)
David Poindexter
Interesting perspective - thanks for sharing!
David Poindexter Tuesday, August 29, 2017 10:44 PM (link)
Tony Henrich
The latest version of DNN got rid of Telerik. Looking forward when DNN gets rid of WebForms completely where DNN can run on Linux or Macs and running on .NET Core. Some of those PHP developers might get interested in C# & .NET and create even more superb modules.
Tony Henrich Friday, September 1, 2017 4:55 PM (link)
David Poindexter
Agreed Tony!
David Poindexter Friday, September 1, 2017 5:13 PM (link)
albert tsou
I'm in a little confused with JAR checklist,
J....do not use Razor, as it's not practical for this
A....
R....use Razor instead of WebControls for the bits of HTML....
seems conflict here, is this all your means ?!

But thanks your sharing anyway !
albert tsou Friday, September 7, 2018 8:18 AM (link)
Daniel Mettler
@albert Modern UIs will be in JS, because they are just "sexy". Especially for application development, that's all you need. But there are still cases where the HTML must contain real content - especially for content-oriented websites which want to rank great (SEO). In these cases, you can use razor, which is mostly "future-proof" but will never result in the sexy ajax apps we love today.
Daniel Mettler Friday, September 7, 2018 2:28 PM (link)

Comment Form

Only registered users may post comments.

NewsArchives


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out