Dolittle 3.0.0 — Release notes

We just released version 3.0.0 of Dolittle across the board of our major components for .NET. This post walks you through what has changed and sparked a major version across all the repositories involved.

Tooling

A major part of building Dolittle applications is tooling and specifically the tooling for generating the metadata regarding your application. Due to our investment in WebAssembly, we needed to improve our build pipeline for MSBuild. We also pay a lot of attention to not being a major bottleneck to the build process in terms influencing the build time too much. Feedback loops are super important.

Since Dolittle is so modularized and decoupled, we needed a core build system that was pluggable in an automatic convention based manner.

This new pipeline is part of the reason for the major version. We have a package called Dolittle.Build which before 3.0.0 was part of the Dolittle .NET SDK, which was fine except it broke the naming convention of assemblies coming out. Repurposing the name means a breaking change, so we decided that was the best. This do however have a massive consequence up the stack, since our Runtime is not completely isolated and is in fact also consumed as NuGet packages and the Fundamentals being at the bottom level, you basically have a cascade all the way through.

For any applications this now means you need to have the following package references to get the build going.

<ItemGroup>
 <PackageReference Include=”Dolittle.Build.MSBuild” Version=”3.*”/>
 <PackageReference Include=”Dolittle.SDK.Build” Version=”3.*”/>
</ItemGroup>

WebAssembly

The thing that set in motion the cascade of changes is our WebAssembly support. Our support is still very much a work in progress and we do have things that have yet to be implemented and also a bit of work to be left for optimization and improving the development story. But all in all we’re very happy with where we are and what we have got thus far. To get started, please read our getting started guide. We also presented this at the London PWA meetup earlier this week as you can see here. We also have a working ToDo sample that shows how to do a side-by-side server with WebAssembly solution here.

Dolittle Folder

The Dolittle build tools have a very specific job and that is to generate the metamodel for the application. It holds information about the artifacts and topology of any bounded contexts being compiled. This information is outputted into files that are being used at runtime and located inside a folder called .dolittle by default. This is now possible to override so that two projects, for instance a side-by-side scenario of regular application running on a server and a WebAssembly version. These will have two different entry point projects and want to have the same reference to the same projects and share the metamodel. This is now possible by adding a property to a PropertyGroup inside the .csproj file:

<PropertyGroup>
 <DolittleFolder>../Core/.dolittle</DolittleFolder>
</PropertyGroup>

Autofac

Our Autofac support used to live as an extension in its own repository. With the effort going into the new build pipeline we had to move this down to Fundamentals. The reason being that we wanted to build our build pipeline without compromise on our core principles and wanted to dogfood our own systems for discovery and other things we have in Fundementals. It was moved down, but without any change or coupling to Autofac within Fundamentals and other components. In fact, it is a promise from us not to couple to a specific IoC container within Fundamentals, Runtime, SDK or any other frameworks as we strongly believe that within an application you should be able to chose this yourself. Internally, we hardly ever notice or use anything from the IoC directly, just adhering to the Dependency Inversion principle and trusting the composition will happen.

Performance Boost

Very important this time around is a general performance boost. This is more a general theme and tiny pieces here and there that has been made faster and more optimal. In total this results in a significant boost in the startup time. This was sparked by a need to improve startup for our WebAssembly support and we’re seeing our startup time halved as a consequence, from ~5 seconds to around 2 seconds on development machines. On regular cloud / server scenarios, the boot is below 1 second and is not as noticable — but general feedback from projects using the new bits is that they are seeing the boost. This work will continue moving forward, as development machines are not a reference for what is being used by end users.

MongoDB Collections

A breaking change that was introduced in this version is how the naming of collections are generated when using the IReadModelRepositoryFor<> interface for read models. This used to be the name of the type of the readmodel, which turns out to be a very bad strategy if you have two different types with the same name representing two different collections only different namespaces. Right now the strategy has been changed to use the fullname of the type but excluding the prefixRead from namespaces prefixed with that. This will give a consistency in naming in conjunction with our feature and module system found in the metamodel. We do however have an issue registered for improving on this.

Known issues

After release, we discovered a couple of things missing:

• Permission denied on some occasions on Windows for the build pipeline — #220
• Boilerplates for our CLI and VScode extensions out of data — #28
• Update documentation on changes in our Build pipeline — #208

These will be taken care of over the next couple of days.

Enjoy!