Assembly details and versioning extension (from user projects)

[mwpowellhtx]

Apologies if the verbiage is imprecise. Is there a widget or what have you to convey top level, presumably Orchard CMS enabled app, assembly details, copyright, versions, or just in general AssemblyName based details, etc? If not how difficult would that be perhaps? Thanks!

[mwpowellhtx]

This is just me thinking out loud, could possibly start by extending OrchardCore.ContentManagement.Metadata.Models.ContentPartDefinition and/or some OrchardCore.ContentManagement.Metadata.Models.ContentPartFieldDefinition. Based on a loose acquaintance with the OrchardCore namespace. Perhaps with some Startup configuration extension methods that allow connection with an Assembly, AssemblyName, etc.

Anyone's thoughts 💡 ?

Thank you...

[mwpowellhtx]

Okay, so getting brave, still with questions on the back end... Would need to arrange that in some content types or what not to get a better idea apples from oranges there.

[mwpowellhtx]

To summarize, what I am after is an easy-to-(re-)use widget, ContentType (?), item, that I can inject for a given site.

[Skrypt]

You seem to talk about using a custom module in that case. You can use dotnet new to create modules or themes provided with Orchard Core as easy startup modules. Please look at the documentation for this. And yes, that would mean that you would need to extend some classes in that module to get some reusable ContentParts.

[mwpowellhtx]

Okay; so ContentParts is the starting point? That's pretty much what I'm interested in, key starting points there. Probably then 2+ modules, for the Assembly credentials, another for theme(s), etc. I can fumble around from there, probably. Thanks...

[mwpowellhtx]

Not sure I quite understand the docs; however, starting from an Orchard Core Cms Module project template_. I setup a module, pretty sure I've named at least a stub for my ContentPart, i.e.

public class AssemblyCredentialsPart : ContentPart
{
    // ...
}

Also controllers, drivers, handlers, and so forth.

I can fill in some properties there? i.e. an Assembly and/or AssemblyName property? Which I asssume are somehow relayed to the CMS admin configuration and so forth?

How is that connected via a web app, one Startup to the module Startup? Let alone identifying requisite bits, Assembly, etc, to the parts.

[mwpowellhtx]

Okay, so far, seems to connect the dots... TBD in terms of arranging with a content type (?) or what not.

public void ConfigureServices(IServiceCollection services)
{
    // ...
    services.AddOrchardCms(config =>
    {
        // ...
        config.RegisterStartup<Path.To.My.Cms.Module.Startup>();
        // ...
    });
    // ...
}

[mwpowellhtx]

Maybe a follow on question here, OrchardCore.Modules.Manifest.ModuleAttribute ... what is it.

Eventually, I want to connect a .csproj build properties bump to assembly versions and so forth, i.e. bumps during build under prescribed conditions, and I want to relay that to ModuleAttribute, possibly. Possible? If so, how? Big question there would be when the attribute is resolved perhaps as a task with dependency on the bump happening first?

[mwpowellhtx]

Along same lines, as part of the .csproj rather than a Manifest.cs, per se. Seems that could potentially be far more appropriate IMO.

[mwpowellhtx]

Re: Migrations, what are they to a parts module? Not sure I quite understand that. Are we specifying a JSON translation? What happens as a part potentially changes from one version or commit to the next, we need to do another migration? For starters... Thanks!

[mwpowellhtx]

you can add other methods in there...

Huh? That is not how I read it from the base class comments, but I could be wrong. I read to mean it is more of an interface in the style and manner of its behavior. i.e. Create is specifying definitions and such through the man in the middle pattern i.e. _contentDefinitionManager, and a 'version', after a sort, though somewhat crude, is sorted and applied as such. i.e. if you updated version 3 and had 4-6 versions pending, those would be applied next time round. More clarity there would be fantastic, specify an interface, even an abstract method with comments.

[mwpowellhtx]

So in other words, I read to mean migrations should be approached more like this:

public class Migration1 : DataMigration
{
  public int Create() => 1;
}
public class Migration2 : DataMigration
{
  public int Create() => 2;
}
public class Migration3 : DataMigration
{
  public int Create() => 3;
}

With, presumably, DataMigration derivations being consumed by convention.

[Skrypt]

The create method is generally used to define the base data structure for someone starting with a fresh install. Then the other methods ... UpdateFrom1() { return 2; } ... would be applied only for those who don't have the latest database structure or even data properly set for the module to work properly. So, this is where we run DB data and schema migrations. This is quite similar to something done in EntityFramework as an example.

[mwpowellhtx]

Ah, okay. Curious, and interesting. Seems unnecessarily fragile to me, IMO. From previous lives and experience, generally, I just have a migration class, somehow specify a 'version', i.e. literally a System.Version instance, let's say, and order by that, and simply apply the ones in balance. That's all migrations are as far as I'm concerned. And with reflection and such, it is super simply to identify, create, and order instances.

[mwpowellhtx]

@Skrypt Remember also from a principled perspective, SOLID is key IMO. Single instance single responsibility; one class responsible for one migration only; and then, depending on the migration pattern, up/down/side grades as appropriate as well.

[mwpowellhtx]

Re: Views and such, it is sort of apparent what is going on there. Not sure however, what is the HomeController about? Or the corresponding Home/Index.cshtml view? Supporting settings, editing, etc, purposes, via the CMS?

[Skrypt]

The Home page in Orchard Core is a page that can be set through the AutoroutePart settings. On a specific Content Type, you can set the AutoroutePart to enable setting the current content item to be the home page. HomeController in our demos or examples is just for that matter. It could have been named TestController too.

[mwpowellhtx]

Cool, sort of understood. In which context, the configuration, editor? Or live rendered content? Or both...

[Skrypt]

Both, the home page is a tenant setting altered by that AutoroutePart. And of course live or from recipe.

[mwpowellhtx]

Okay, so one or two steps back and gaining perspective... I'm not sure there is anything I need/want to convey re: settings in the Content Management vernacular. However, perhaps I need/want to intercept the part instance itself and configure its corresponding assembly(ies), assembly name(s), and so forth, if at all possible. Probably as an extension method during Startup config, services, or whatever. Not sure if that is possible?

[mwpowellhtx]

Perhaps the way to do that today is via appsettings.json, i.e. relay a class name, etc, via configuration for consumption by the module (?).

[mwpowellhtx]

Instead of that approach, could just have DI provide the part with an IAssemblyCredentialInfo instance, i.e.

public interface IAssemblyCredentialInfo
{
  Assembly Assembly { get; }
}

Which can be wired during the CMS project Startup.

[mwpowellhtx]

Wired that and fed an instance to the ContentPartHandler<TPart> class; although not real happy with the name. Too generic IMO; EventHandlers or even Handlers might be better and convey more meaning. Also comments! Or lack thereof; self-descriptive comments are a must. But I digress... through which I can relay the Info to the part when we work with the instance.

[Skrypt]

I'm currently not sure if what you are trying to achieve makes sense to be done through a ContentPart. Adding Assemblies version and descriptions are generally something that you will achieve by using a Properties.cs file inside a .csproj module. Here, we also have Manifest.cs files for describing Orchard Core specific modules details.

I think you should definitely look at Properties.cs files inside a .net core project (.csproj). That's how you generally set an assembly copyrights details and else.

[Skrypt]

I will read your module documentation. Need to find if that would work with what we currently have. Also, need to think about how we manage the versioning of our assemblies (but that's another story). 😄

[mwpowellhtx]

Well, again, that's how we like to manage our versioning. How you manage yours is up to you. 😉 Cheers, sir, thanks so much.

[mwpowellhtx]

I will read your module documentation. Need to find if that would work with what we currently have. Also, need to think about how we manage the versioning of our assemblies (but that's another story). 😄

Bottom line is that it is evaluated during the build steps. As long as that happens, the normal versions that can be available, version, package, assembly, file, etc, all good. The variables are what they are, as long as that can be connected i.e. perhaps during a task depending on those phase lines, that should be fine.

[mwpowellhtx]

For perspective, trying to assemble something not unlike this, via OrchardCore CMS framework elements, and connect it with the top level application assembly and such.

Did a bit more experimentation, as I think I mentioned herein (or this is the first if not second time), I can connect the Assembly details through DI factories to the handlers and relay that during the handlers Initializing phase line. Perfect.

Also working with a 3P nuget package LibGit2Sharp for purposes of possibly informing about SHA or other repository details, i.e. during a debugging session. Has potential, whether part of the same supporting 'model' (loosely called) or resource.

Then I think it is a matter of the views that are involved. So... I think it is possible, cautiously optimistic at this point.

[mwpowellhtx]

...need to think about how we manage the versioning of our assemblies (but that's another story). 😄

Indeed. A bit more in depth thinking, @Skrypt. There has no doubt been adoption into the ModuleAttribute usage; but for versioning, I think the core attributes may already exist in one form or another via Assembly, AssemblyName, and so forth. Not sure why that does not work for y'all, and the constructs are well established in the .NET framework.

Also re: csproj properties, there's a whole set of them for versioning purposes, from simple Version, to Assembly, File, Package, and so forth. I support that via my BAV tooling. Which build turns around and generates the traditional AssemblyInfo, i.e. perhaps the Properties that you are thinking of, using that and some other elements. But you have to dig a little bit in the Microsoft docs to get to much of that detail; and, like I stated, we like to automate that versioning as much as possible.

The tricky part for us, I think, is that BAV rewrites the project file, IIRC, been little while since I reviewed it. I think this is reloaded by the build process, but my memory is a bit fuzzy where that is concerned. So not sure whether we have an up to date property value to feed ModuleAttribute. Or direct support for the assembly version would be the best possible case, I think; but how deep is your adoption into ModuleAttribute at this point, I cannot answer that for you and the Orchard team/community.

[mwpowellhtx]

Side issue when editing with the custom part added to the content type.

[mwpowellhtx]

Discussed with @sebastienros during triage Thu, 31 Mar 2022. Will file a more specific issue and submit PR along these lines. Thanks...