DesiGen v1.15.0 now released

Published
11 February 2022
Category
Releases
Author
Andrew H

The latest beta version of DesiGen is now released, containing the latest improvements and bugfixes.

User feedback is most welcome.

Details on how to install this version can be found on the installation page of the documentation.

New in this release:

  1. BREAKING Template Change: Changed the using statement within each of the CSLA artefact templates to support a change of subfolder name in a CSLA Objects project from DataAccess to DataContracts. This name change is intended to help people understand the difference between the folder in the Objects project containing the contract for a Repository and the entirely separate DataAccess project in which the implementations of Repository classes are intended to be placed.

If you have already created a project using the old DataAccess scheme, there are two options. You should either change all future generated classes to use the old namespace, or change the name of the folder (and optionally the namespace of all of the classes it contains) to use the new name. I will probably be doing the latter eventually, as the differentiation between the contracts and the implementations will probably help aid the understanding of the solution for anyone who reads the source code.

  1. Template Changes: Added a DataContracts folder as a subfolder of an object library as part of each of the Blazor solution set templates. This is something that used to be created manually during a demo, but as it is referenced in the artefact templates for CSLA classes, it seems better to create this automatically as this reduces the risk of people struggling with invalid namespace errors.

  2. New Templates: Added a new templates for unit test projects, and generating unit tests of ViewModels.

  3. Template Changes: Added the creation of a unit test project as part of each of the Blazor solution set templates.

  4. Template Changes: Upgraded all project references to the Csla package to version 5.5.2.

  5. Template Changes: Upgraded all project references to the core Microsoft.Extensions packages for configuration, dependency injection and logging to version 6.0.0.

  6. Template Changes: Upgraded all references to DotNotStandard.Validation and DotNotStandard.Caching to version 1.0.0. Version 1.0.0 of these libraries are functionally unchanged, but are newly released under the MIT license rather than the GNU GPL that was originally applied. This licensing change removes the restrictions that would otherwise (unintentionally) have been placed on all applications built referencing them. There is no longer any copyleft restriction on these components, allowing users of DesiGen to apply whatever license they choose on the works they create with the tool.

  7. Template Changes: Added a reference to the new DotNotStandard.DependencyInjection.AutoDiscovery package. Added code to the ServiceCollectionExtensions artefact templates for both UI Control and Data Access projects so that ViewModel and Repository implementations are registered into the DI container automatically during the startup of any application built using the Blazor solution set templates. This removes the need to manually register each individual ViewModel or Repository - a common source of exceptions after a new development task.

  8. Template Changes: Commented out the exception that was thrown in the SetUser method of the FakeApplicationContextManager class. Suddenly this appears to be a problem in a newly generated Blazor WASM solution, perhaps because of a change/fix in CSLA 5.5.2 to which we have now upgraded.

  9. Enhancement: Increased the maximum permitted length of the ArtefactSetTemplateCode field from 50 to 100 characters, in line with codes of its children. This allows set templates with longer codes to register successfully.

Known issues/limitations in this release:

  1. The application will not run if installed inside of the "Program Files" or "Program Files (x86)" folders. This is a permissions problem that is out of my control. Please workaround this by installing it outside of these folders. The default location is C:\DotNotStandard\DesiGen.

  2. Clicking on a link in the design menu causes unsaved changes made on the current page to be lost. The workaround is to click either the Next or Back button before navigating away from the design section.

  3. There are a limited set of templates at the moment. We do not intend that we deliver all of the templates you will ever need; instead you are able to create your own. However, there are a number of solution quickstarts that we do intend to add, such as a template for a hybrid MAUI solution.

  4. There is limited functionality to assist with collaboration between team members, including design reviews. We will assess what extra work is required in this area as part of a future development phase. The workaround for the moment is to interact via other channels. If you wish to do offline collaboration, we suggest generating a Word document, which you could print and review by hand, or use the notation features in built into Word to enable collaboration upon it.

  5. There is no data management in place, such as the scheduled deletion or archiving of old designs, or log entries. The failure to clean up old log entries may cause your database to grow beyond your expection; please be mindful and allow sufficient space in your database for this slow growth.

  6. All child CSLA objects are code generated to have async data access code. However, a limitation in CSLA currently makes async inserts and updates unreliable in some UI technologies, especially WPF applications built using Mobile Blazor Bindings. It is recommended that repository interfaces and classes for child CSLA objects are changed to use synchronous methods for Insert, Update and Delete if any application hangs are encountered with generated code. This issue does not affect Fetch methods/operations, which can still benefit from async data access for maximum scalability.

  7. Whilst custom artefact templates can make use of artefact template helper types, at this stage only built-in helper types can be used. This is an intentional limitation because importing user-defined helper types needs careful consideration; importing external code could represent a security vulnerability if not handled correctly. This limitation will be removed in a future release, once the code to mitigate the security risk has been completed.