Forum Discussion

JesseTaber's avatar
23 days ago

Behind the Scenes: Storyline’s Move to Modern .NET

We just wrapped a project that’s been hanging over Storyline for a long time:
Moving from .NET Framework 4.8 to modern .NET (now .NET 10).

This one goes deeper than it might sound.

Back when Storyline was first built, choosing .NET Framework was the obvious call. This was 2010-ish. Windows dominated our space, and the .NET ecosystem gave us a lot of what we needed to move fast and build a really capable tool.

That decision worked. For a long time.

It also shaped some of the realities of the product today. Questions about platform support come up a lot, and early architectural choices like this are a big part of that story. They helped us move fast early on, but they also made certain paths more complex later.

Fast forward to now…

Microsoft has effectively stopped evolving .NET Framework and put their energy into modern .NET. Meanwhile, we were still running on a foundation that wasn’t keeping pace with where things were going.

So we made the call to move.
This wasn’t a simple upgrade.

We relied on parts of .NET Framework that don’t exist anymore. AppDomains. Binary serialization. A handful of “seemed like a great idea at the time” features that modern .NET intentionally left behind.

We had to rethink and rebuild some pretty fundamental parts of the product.

So what did all of this actually get us?

We’re now on a modern, actively supported runtime. It’s easier for us to keep improving performance, adopt new capabilities, and evolve the platform without constantly working around legacy constraints.

We also retired some very old pieces of the system along the way, which… felt pretty great 😅

And then there's performance.

Microsoft has invested heavily at performance improvements in modern .NET, and we're seeing that surface in Storyline.

We ran benchmarks across 18 Storyline projects, measuring open, save, and publish times. Every single project got faster with improvements ranging from 0.4% to nearly 30%. The larger the project, the larger the improvement. 

In the animated gif below, I put .NET Framework (left) head-to-head with modern .NET publishing the same course.

Neither project was pre-published to warm the cache, and I even gave .NET Framework a slight head start by clicking Publish there first.

The gif is sped up for easier viewing, but the result is real: modern .NET finishes publishing well before .NET Framework.

Big credit to the team that pulled this off. This was deep, risky work in some of the most critical parts of the product.

Curious to hear from folks here:

If you're on the latest Storyline 360, have you noticed any performance improvements when opening, saving, or publishing your projects?

4 Replies

  • Thomas_Shayon's avatar
    Thomas_Shayon
    Community Member

    Wow! Team, congrats on this huge foundational tech-stack switch! 🙌🏾

  • ID4WiscState's avatar
    ID4WiscState
    Community Member

    I absolutely appreciate the improvements! As an animation-heavy educator, I absolutely would open files and meander off for a coffee refill, to come back to a still-opening file. I experience fewer lags in all sorts of workflows, and really appreciate their keeping up with my flow states.

  • JenLynnRusso's avatar
    JenLynnRusso
    Community Member

    We ran benchmarks across 18 Storyline projects, measuring open, save, and publish times. Every single project got faster with improvements ranging from 0.4% to nearly 30%. The larger the project, the larger the improvement.

    Wow! Appreciate all the Storyline improvements and cleaning up. I don't use it as often as I do Rise, but when I do, I know I can make the sweetest assets 🙂

  • Frankie's avatar
    Frankie
    Community Member

    Jesse,

    I was scratching my head a few weeks ago when I went to publish a more finalized version of a large project file I was working on...and it took SIGNIFICANTLY less time to publish than I expected! I thought for sure I had accidentally done something wrong (like publish only one scene of the project or something)...and I had to double-check my work.

    I am happy to hear that the underlying reason for the change was improvements on the back-end. I would have never known otherwise.

    Great work to you all on making the upgrades!

    - Frankie