Previous Page Next Page

Serenity 6.2.1 - 6.2.4 Release Notes (2022-10-11)

Fixed DefaultSqlConnections Null Reference Exception Causing Sergen to Fail (6.2.1)

We added logging support in 6.2.0 to Sql methods, but as logging via dependency injection is not available in Sergen environment, and we missed a null check in DefaultSqlConnections, sergen command was failing.

Recreated package-lock.json File While Building VSIX Template (6.2.2, StartSharp)

We normally have a directory reference to corelib in our package.json during development:

{
  "name": "startsharp.web",
  "dependencies": {
    "@serenity-is/corelib": "file:../../Serenity/src/Serenity.Scripts/corelib",

This allows us to test our changes in corelib without having to publish an npm package, directly from the Serenity submodule in StartSharp.

During packaging of VSIX template, an automated process updated this dependency to the latest version of corelib at npm:

{
  "name": "startsharp.web",
  "dependencies": {
    "@serenity-is/corelib": "6.1.4",

But as this does not affect package-lock.json, that still contains the folder reference.

We distribute package.json and package-lock.json together in the StartSharp template. So when someone creates a new project from our template, package-lock.json still contained a folder reference.

This was causing npm to create a symlink to a non-existent folder instead of downloading corelib from npm.

This is now fixed as our automated process deletes the package-lock.json and node_modules folder after patching package.json and running npm install command after, so that users will get a valid package-lock.json file.

If you created a project with StartSharp template between 6.1.0 - 6.2.1, you may need to update Serenity packages, delete package-lock.json and node_modules and run npm install.

Fix Modular Typings Restore for Package References in node_modules Folders (6.2.2, StartSharp)

We had a target in Serenity.Pro.Coder file which restores modular typings from package / project references to folders under node_modules instantly in Visual Studio / during build.

This was a workaround to ship modular typing files with NuGet packages that can be used by TypeScript, as it can't find those files under user's nuget folders (which might change for every user / pc).

Due to an expression mistake in MSBuild target file, the typings for Serenity.Pro.Extensions package was being restored to an invalid folder like node_modules\@serenity-is\pro.extensions;@serenity-is\pro.extensions instead of node_modules\@serenity-is\pro.extensions only.

If your project had reference to Serenity.Pro.Coder 6.1.0 - 6.2.1, you may need to update Serenity packages and delete node_modules folder then run npm install.

Moved RestoreTypings to Serenity.Net.Web

We had a RestoreTypings target in Serenity.Pro.Coder and common-features that restores index.d.ts files from NuGet package and project references to typings folder for namespaced ones and to the node_modules\@serenity-is folders for modular ones without having to run sergen restore.

This meant, it only worked with projects that reference Serenity.Pro.Coder package. We now moved that msbuild target to Serenity.Net.Web package so that this feature can be used for other projects.

After updating Serenity.Net.Web you may notice that even if you clear typings folder while having Visual Studio open, the directories and files will be restored instantly.

If you don't want this feature for some reason, add this line to your project:

<PropertyGroup>
  <RestoreTypings>false</RestoreTypings>
</PropertyGroup>

Fixed the Problem Causing Grids To Not Display Data in Serene After Updating to 6.1.x (6.2.4)

DataGrid.defaultRowHeight and DataGrid.defaultHeaderHeight values are undefined by default. This values are passed to the SlickGrid instance via getSlickOptions() method of the DataGrid class.

As we rewrote SlickGrid as SleekGrid and made jQuery an optional dependency, this caused an issue in Serene when you update Serenity packages to latest versions.

We used Object.assign in place of jQuery.extend method to apply default SlickGrid options to the options you pass to the SlickGrid constructor. They are mostly compatible, but seems like there is a subtle but important difference between them.

While, jQuery.extend skips properties that have undefined value, Object.assign does not. Thus, the undefined default row height passed from getSlickOptions to the grid was overriding the SlickGrid default value.

We couldn't reproduce this issue in StartSharp because the premium theme sets DataGrid.defaultRowHeight to compensate for the larger default font size.