NuGet package?

[GreenWaves400]

Before anything else, thank you for improving and fixing the biggest flaw in OpenIddict by giving it NHibernate support.

Unfortunately, as of now, I noticed the NuGet package is completely unavailable for some reason. The page in the readme ( https://www.nuget.org/packages/Community.OpenIddict.NHibernate ) also returns a 404 error.

Has the NuGet package been pulled down for some reason? And is it planned for it to return?

Many thanks.

[vruss]

Hi, thank you!

I made this project while working on an internal implementation for my company. I got some more changes made on my laptop I never pushed too.

In the end, I never used this in our final implementation so I cannot give any guarantees that it is production ready.

That’s also why it’s not published, since it was never tested and confirmed working.

I can do a new commit and push my changes tomorrow perhaps but I don’t think I will spend time actually supporting this repo and publishing nuget packages unless there’s a business reason for me to do so.

So if you need an nhibernate implementation then please try your best and make a fork to see if you can get it running haha

[GreenWaves400]

That's awesome, thank you for sharing this effort. If you happen to push those pending changes you have, that'd also be most welcome, yes.

Sounds like we are/were on a similar boat, and in all likelihood a lot more people also are: just about any NHibernate user interested in an OpenID Connect server (to be their own IdP) and/or client implementation, which is a lot of people.

I'd also say, no worries about not being able to support this repo, that's completely fine. You actually already paved the way for most people to have NHibernate viably working, at least to a certain extent, with their OpenIddict setup. That's already more help than any of us could have asked for. So I have to thank you again for that.

---

I'm not sure if this will help other people stumbling upon our conversation, but just in case it does, I'm going to leave some other links below that correspond to old OpenIddict code and discussions from the brief period NHibernate was actually implemented in it (although not added to any OpenIddict release package), just in case this old info somehow can also supplement this current implementation in this repo, for anyone who might want to fork and maintain their own version:

Jan 27, 2019 - NHibernate support added
Introduce NHibernate 5.x stores (discussion)
Introduce NHibernate 5.x stores (commit)
Commits history up until that point

Jan 16, 2020 - Last commit before removal
Commit dae66ef
Project page at that point

Jan 16, 2020 - NHibernate support removed
Commit 24ebea5

May 2020 - removal discussion
How to use it with nhibernate?

Releases of potential interest during that period, back when OpenIddict release cycles were much slower:
2.0.0 (Nov 2, 2018)
2.0.1 (Oct 17, 2019)
3.0.0-beta1 (Jun 12, 2020)
Those 3 releases were consecutive, no "gaps" of any other releases exist between them. Note: Version 3 introduced OWIN support, used e.g. on ASP.NET (.NET Framework). See the chart here.

Hope this helps someone out there.

[GreenWaves400]

Just wanted to give an update here for all parties that could potentially be interested: I was able to successfully and cleanly use this NHibernate extension for OpenIddict.

Thanks once again, @vruss! And thanks as well to @kevinchalet for the original OpenIddict.NHibernate* code, as well as to any other contributors.

It must be said, however, that some fixes to this source code are required, else you will run into issues. Due to certain reasons, the best I can do is tell others how to get them fixed. Code-wise, it's not much that needs to be done, but here we go:

As those reading may or may know, OpenIddict sets up (maps) and manages 4 database tables to do all of its magic, regardless of ORM choice. By default, they're called "OpenIddictApplications", "OpenIddictAuthorizations", "OpenIddictScopes" and "OpenIddictTokens". They are used to manage your various tokens etc..

The 1st fix you need is to be done in the "OpenIddictNHibernateTokenStore.cs" file, in the methods "GetCreationDateAsync" and "GetExpirationDateAsync". When those dates are retrieved, they will be using your server's timezone, but when they were originally stored, it was done in UTC+0 time. So depending on your server time, your tokens/codes likely will be expired the moment they are created or, alternatively, will live for far longer than they should. To fix it, simply look at how the method "GetRedemptionDateAsync" is implemented, it handles the timezone of a DateTime property properly (as does "GetCreationDateAsync" in file "OpenIddictNHibernateAuthorizationStore.cs").

The 2nd fix is to be done in the 4 models: any read-only ICollection property was causing me an issue, in that NHibernate would hit me with an exception unless I at least added a "private set;" setter to them. I'm not sure if there's a better way to handle that situation, and I'm also not sure if this is required for every NHibernate setup, but it surely was the case for me (using the latest NHibernate 5.5.2 and FluentNHibernate 3.4.1).

The 3rd fix is essential to even get things kickstarted: by default, OpenIddict creates its own GUID from the C# side, and uses GUID as the Primary Key type for each of the 4 tables. That is fine and all, but for some reason @kevinchallet chose the wrong mapping type for the Id in his original NHibernate code, which also carried over to this project fork: All 4 entity mappings are defined to use "map.Generator(Generators.Identity);", which can only work if your Primary Key is an integer type, such as BIGINT (SQL Server), INT and so on. Certainly not GUIDs. So nothing works with this conflict, until you change it to something more fitting. There are numerous ways to address this bug, but if you intend to rely on OpenIddict's default behavior, and be as brief as possible, you can simply use "map.Generator(Generators.Assigned);" for all 4 classes, which is basically you telling NHibernate you will generate the values for your Primary Key yourself, which is perfect, as OpenIddict is doing exactly that.

There should also be the possibility to use "map.Generator(Generators.Guid);" or even the venerable "map.Generator(Generators.GuidComb);" (quick rundown), as long as you call "UseOpenIddict<System.Guid>()" (an extension method) instead of just plain "UseOpenIddict()" on your NHibernate.Cfg.Configuration object instance, as well as "ReplaceDefaultEntities<System.Guid>()" in the OpenIddict configuration, e.g. "services.AddOpenIddict().AddCore(options => { options.UseNHibernate().ReplaceDefaultEntities<System.Guid>().UseSessionFactory(repositoryFactory.SessionFactory); })". However, I did not attempt these, so I cannot promise doing so will actually work as is, or will still require some other tweak somewhere.

I did notice that keeping the existing "map.Generator(Generators.Identity);" can almost work when using e.g. "UseOpenIddict<long>()" and "ReplaceDefaultEntities<long>()" like mentioned in the previous paragraph, but for some reason, which I could not pinpoint, OpenIddict fails to update the .NET-side Id with the newly-generated integer value that was already successfully generated by, inserted into and committed to the database. This later on leads to an error when trying to get objects by Id, short of restarting the server application. In other words, it's not fetching back the value to the application, OR it is being fetched, but then getting lost due to some implementation oversight. To investigate that, a good idea might be to pay close attention to e.g. the method "CreateAsync" in "OpenIddictNHibernateApplicationStore.cs" during debugging. E.g. is that "MergeAsync" call actually working as intended? On a side-note, perhaps it might also be worth a mention that OpenIddict uses "FlushMode.Manual", with a whole justification for it seen in comments in "OpenIddictNHibernateContext.cs", whether ultimately valid/applicable or not.

Likewise, I suspect using "map.Generator(Generators.GuidNative);" might run into the same issue, as the GUID is then generated from within the database system instead, but only testing can tell.

The 4th and final fix is to be done in "OpenIddictNHibernateScopeStore.cs", lines 116, 133, 149: in "ArgumentNullException.ThrowIfNull(nameof(query));" or "ArgumentNullException.ThrowIfNull(nameof(scope));", we need to get rid of the "nameof" expression in each of those, because it's supposed to be a check if the given parameter is null in each case. The NAME of the parameter itself will never be null, however, thus never triggering an exception when and where it should.

I also went and changed checks against strings across "OpenIddictNHibernate*Store.cs" files so that, when checking for null OR empty, we check for null, empty OR whitespace instead.

And that's it! I won't promise anyone these will make OpenIddict.NHibernate production-ready, however I have yet to run into issues in my OpenIddict-based server once these 4 fixes above were applied.

NHibernate version side-note: It would seem the minimum NHibernate version is 5.2.0, based on GitHub discussions I have seen between @kevinchalet and the NHibernate developers, so if for any reason someone is still using 5.1.* or earlier, one might run into additional issues.

I also updated all code to be compatible with .NET Standard 2.0, .NET Framework 4.6.1, while keeping the original .NET 8.0 target. One simple way to do that is to use the same polyfill that is also used by OpenIddict itself for the same reason, which is PolySharp, but I personally just went and adapted whatever code parts were necessary to achieve so instead. If anyone chooses the latter, the only hurdle was to replace "Random.Shared.Next();", but an excellent, and quick, tutorial to do so can be found here. One can also downgrade the C# LangVersion with some work, if so desired for whatever reason (e.g. using older C# compilers, versions of Visual Studio and/or other IDEs).

Before I forget, it should also be noted that the Readme in this GitHub repo in its current state is simply not to be followed, as it is inaccurate, seemingly being more of a placeholder text of sorts than anything else, which certainly can cause some confusion... But this library is actually very easy and simple to use: We just have to call ".UseOpenIddict()" from the NHibernate.Cfg.Configuration object before building the session factory, and then we can simply call something like "services.AddOpenIddict().AddCore(options => { options.UseNHibernate().UseSessionFactory(repositoryFactory.SessionFactory); })" in e.g. Startup.cs "ConfigureServices" method. And, as always, we can update or create a schema from code with methods like "new SchemaUpdate(config).Execute(false, true);" or "new SchemaExport(filteredConfig).Create(false, true);" accordingly. A good path to get started with an OpenIddict+NHibernate server implementation IMO is to go for this tutorial, then swap EFCore In-Memory with an actual DB instance with EFCore, and then swap EFCore with NHibernate accordingly.

Finally, and this is important to keep in mind: I tested and confirmed all of this is working with as far up as OpenIddict 6.4.0. But just less than one month ago, OpenIddict 7.0.0 got released, that too unusually early, and it actually went and caused an unusual breaking change, considering OpenIddict's history so far. It seems rather easy to fix, but it is something I have not worked on just yet, so I cannot hand out the solution on a silver platter for it at this moment, like I did for the other points above, which were far more difficult to troubleshoot anyway. As far as I can tell, it has everything to do with this change.

[kevinchalet]

Finally, and this is important to keep in mind: I tested and confirmed all of this is working with as far up as OpenIddict 6.4.0. But just less than one month ago, OpenIddict 7.0.0 got released, that too unusually early, and it actually went and caused an unusual breaking change, considering OpenIddict's history so far. It seems rather easy to fix, but it is something I have not worked on just yet, so I cannot hand out the solution on a silver platter for it at this moment, like I did for the other points above, which were far more difficult to troubleshoot anyway. As far as I can tell, it has everything to do with this change.

I try to avoid breaking changes when possible, but in that case it wasn't an option, as trimming/Native AOT support required making quite extensive changes to remove the reflection calls that couldn't be statically analyzed. That said, it should be fairly easy to update your stores to be compatible with OpenIddict 7.0 (and actually, it should simplify things a bit, as the IOpenIddict*StoreResolver interfaces and their implementations are gone in 7.0).

[vruss]

@GreenWaves400 you really show what the best of open source looks like 🤩!

Applause for all the hard work you put in to figuring out my half finished stuff and then writing it down.

To benefit the community even more I wouldn’t mind handing over pushing rights if you wanna contribute your fixes.

---

Regarding the readme, yes it’s completely placeholder in its current form. I never finished it when I had to give up on this project due to business change directions.

And also you’re completely right with the GUID stuff you discussed. I took the time to write my own implementations for all the data models in the company repo using this nuget package back then because we needed to use integers for primary keys and I had to add attributes to some of the database fields.

[vruss]

@GreenWaves400 or I can update the readme to link people to your fork if you got one open source

[GreenWaves400]

@vruss I'm really glad you liked the effort and find it helpful! Indeed, hoping to help others was a big driving force for me to go through all this.

Thank you also for the kind words and even repo-related offers. Who knows what the future holds, but at least at the present time, I'm genuinely unable to commit my own code directly to the repo, or publicly fork my own repo, due to my specific circumstances, which is why I detailed the steps as much and as well as I could, so that anyone can easily apply the few code changes without problems. But I truly appreciate it.

@kevinchalet If one day you'd be willing to consider merging these NHibernate stores back to the main OpenIddict project, even if that means seeing further changes to it before that can be considered (e.g. full support for integer-type PKs, and/or OpenIddict 7.0.0 compatibility), please let us know.

[kevinchalet]

@kevinchalet If one day you'd be willing to consider merging these NHibernate stores back to the main OpenIddict project, even if that means seeing further changes to it before that can be considered (e.g. full support for integer-type PKs, and/or OpenIddict 7.0.0 compatibility), please let us know.

Unfortunately, the demand for NHibernate stores is way too low to justify supporting it officially (it's no longer the super-popular option it used to be... hard to compete against Microsoft and Entity Framework Core I guess). Development has slowed down and NHibernate relies on problematic legacy dependencies that haven't been updated for years (e.g ANTLR3 or Remotion's LINQ packages), which probably doesn't help either.

Without a company showing very strong and long-term interest, it's honestly unlikely to happen.

[GreenWaves400]

Alright guys, I finally had a small window of opportunity, which I used to make OpenIddict.NHibernate compatible with OpenIddict 7.0.0 and later! I have run it just as successfully with NHibernate 5.5.3 and OpenIddict 7.1.0, both of which were released just a few days back!

The amount of required code changes is surprisingly much less than I thought, and can be done by anyone. Most of what I documented below is optional, but a few things are required, and I noted each step accordingly.

---

Before I go there, I just wanted to address a few things:

Unfortunately, the demand for NHibernate stores is way too low to justify supporting it officially
Without a company showing very strong and long-term interest, it's honestly unlikely to happen.

That's fair, thanks for considering it to the extent you have and for letting us know!

(it's no longer the super-popular option it used to be... hard to compete against Microsoft and Entity Framework Core I guess). Development has slowed down and NHibernate relies on problematic legacy dependencies that haven't been updated for years (e.g ANTLR3 or Remotion's LINQ packages), which probably doesn't help either.

As far as I know, there are no real issues with ANTLR3 nor Remotion's LINQ packages, both are as powerful and reliable as they ever have been. Of course, I wouldn't mind being guided towards any issues or problems that could use getting addressed in them, if any exist. I also don't see a problem with NHibernate's pace: it's an extremely mature product, and so there isn't as much to do with it (but, of course, enhancement opportunities will always exist in any software project).

I am, however, aware that ANTLR3 has been superseded by ANTLR4, but not in a way that is a problem not to move away from it.

For me and I figure most NHibernate users, both EF and EFCore just don't quite measure up to NHibernate in terms of features, depth and stability, nor in the vast amount of built-in database drivers.

I also always find that EFCore introduces too many breaking changes and bugs with every release, enough to the point I have been repeatedly personally affected in the past in ways I'd never again deliberately choose it. We see remarks about EF Core bugs in every other project or blog post all the time, even the stores in OpenIddict very appropriately document some of them, and mentions what workarounds were taken, when possible.

The amount of supported TFMs in NHibernate 5.x is also a sight to behold, and much appreciated. EFCore, on the other hand, like with Microsoft as a whole, has a clear agenda that goes against actual software reach, made clearer every year.

In terms of popularity, NHibernate is still extremely popular. The main change I could notice however is that, indeed, due to the 1st party nature of EFCore, it also became incredibly popular after a really long time passed, and with every yearly .NET (Core) release, it gets a Microsoft-sized amount of free publicity, explaining much of the phenomena. But NHibernate stays popular out of pure merit and word-of-mouth alone, which IMHO is a testament to its greatness, even to this day, and moving forward.

However, with all that said... It is not my wish to start a whole NHibernate vs. EFCore debate, at least not here, so I will try to leave it at just that.

---

Now onto the exciting part!

Below I will try to highlight the exact changes that were necessary to get OpenIddict.NHibernate to work with OpenIddict 7.0.0 and later.

I have applied most of the changes based on what changed in the EFCore stores for OpenIddict between 6.4.0 and 7.0.0 (nothing changed in 7.1.0). In retrospect, choosing to do this with EF instead of EFCore might have been easier, as I suspect most of the code for the NHibernate stores we have here were based on EF's stores specifically, and it seems a lot of code was normalized between both EF and EFCore stores in 7.0.0 that made EFCore's more like EF's?

In any case, here we go:

OpenIddictNHibernateBuilder.cs

• Add two "using"s:

  • Microsoft.Extensions.DependencyInjection.Extensions;
  • OpenIddict.Abstractions;

• Inside method ReplaceDefaultEntities:

  • Delete everything except the return statement
  • Before the return statement, add the following code:

#if SUPPORTS_TYPE_DESCRIPTOR_TYPE_REGISTRATION
        // If the specified key type isn't a string (which is special-cased by the stores to avoid having to resolve
        // a TypeDescriptor instance) and the platform supports type registration, register the key type to ensure the
        // TypeDescriptor associated with that type will be preserved by the IL Linker and can be resolved at runtime.
        if (typeof(TKey) != typeof(string))
        {
            TypeDescriptor.RegisterType<TKey>();
        }
#endif

Services.Replace(ServiceDescriptor.Scoped<IOpenIddictApplicationManager>(provider => provider.GetRequiredService<OpenIddictApplicationManager<TApplication>>()));
Services.Replace(ServiceDescriptor.Scoped<IOpenIddictAuthorizationManager>(provider => provider.GetRequiredService<OpenIddictAuthorizationManager<TAuthorization>>()));
Services.Replace(ServiceDescriptor.Scoped<IOpenIddictScopeManager>(provider => provider.GetRequiredService<OpenIddictScopeManager<TScope>>()));
Services.Replace(ServiceDescriptor.Scoped<IOpenIddictTokenManager>(provider => provider.GetRequiredService<OpenIddictTokenManager<TToken>>()));

Services.Replace(ServiceDescriptor.Scoped<IOpenIddictApplicationStore<TApplication>, OpenIddictNHibernateApplicationStore<TApplication, TAuthorization, TToken, TKey>>());
Services.Replace(ServiceDescriptor.Scoped<IOpenIddictAuthorizationStore<TAuthorization>, OpenIddictNHibernateAuthorizationStore<TAuthorization, TApplication, TToken, TKey>>());
Services.Replace(ServiceDescriptor.Scoped<IOpenIddictScopeStore<TScope>, OpenIddictNHibernateScopeStore<TScope, TKey>>());
Services.Replace(ServiceDescriptor.Scoped<IOpenIddictTokenStore<TToken>, OpenIddictNHibernateTokenStore<TToken, TApplication, TAuthorization, TKey>>());

• Optional: Inside the UseSessionFactory method, see if there is a reasonable way to replace the existing code with this:

Services.Replace(ServiceDescriptor.Scoped<IOpenIddictNHibernateContext, OpenIddictNHibernateContext>());

return this;

This is taken/adapted from the 7.x sources, but it doesn't play nice on my particular project, and instead I kept this new code commented out for reference. So my "UseSessionFactory" implementation remains unchanged and continues to work as it did before.

OpenIddictNHibernateExtensions.cs

• In the UseNHibernate method, delete all the code and replace it with the following:

            if (builder == null)
            {
                throw new ArgumentNullException(nameof(builder));
            }

            // Since NHibernate may be used with databases performing case-insensitive or
            // culture-sensitive comparisons, ensure the additional filtering logic is enforced
            // in case case-sensitive stores were registered before this extension was called.
            builder.Configure(options => options.DisableAdditionalFiltering = false);

			builder
				.SetDefaultApplicationEntity<OpenIddictNHibernateApplication>()
				.SetDefaultAuthorizationEntity<OpenIddictNHibernateAuthorization>()
				.SetDefaultScopeEntity<OpenIddictNHibernateScope>()
				.SetDefaultTokenEntity<OpenIddictNHibernateToken>();

			builder
				.ReplaceApplicationStore<OpenIddictNHibernateApplication, OpenIddictNHibernateApplicationStore>()
				.ReplaceAuthorizationStore<OpenIddictNHibernateAuthorization, OpenIddictNHibernateAuthorizationStore>()
				.ReplaceScopeStore<OpenIddictNHibernateScope, OpenIddictNHibernateScopeStore>()
				.ReplaceTokenStore<OpenIddictNHibernateToken, OpenIddictNHibernateTokenStore>();

            //// Note: a default session factory is always registered to make debugging easier when
            //// no session type was configured by the user: the default implementation
            //// registered here is automatically replaced by the UseSessionFactory() API.
            //builder.Services.TryAddScoped<IOpenIddictNHibernateContext>(provider =>
            //{
            //	throw new InvalidOperationException("No NHibernate session was configured to be used with OpenIddict.\n" +
            //                 "To configure the OpenIddict NHibernate stores to use a specific 'ISession', use 'options.UseNHibernate().UseSessionFactory()'.");
            //});

            builder.Services.TryAddScoped<IOpenIddictNHibernateContext, OpenIddictNHibernateContext>();

	    return new OpenIddictNHibernateBuilder(builder.Services);

Note that half of the code actually stayed the same, but giving instructions like this is simpler. Also of note is the commented out code: again, it was inherited when looking at the 6.4.0->7.0.0 changes, but that part would not play nice in my setup, nor does it seem actually required, but I kept it there for reference.

OpenIddictNHibernateApplicationStore.cs

• Inside method SetJsonWebKeySetAsync, replace line:

application.JsonWebKeySet = set != null ? JsonSerializer.Serialize(set) : null;

With:

application.JsonWebKeySet = set != null ? JsonSerializer.Serialize(set, OpenIddictSerializer.Default.JsonWebKeySet) : null;

I'm not sure if this is required, but it is definitely a change that occurred between 6.4.0 and 7.0.0, so better add it for good measure.

OpenIddictNHibernateTokenStore.cs (optional)

• Optional (some performance improvement): Update method RevokeByApplicationIdAsync. Look for this line:

.Where(authorization => authorization.Application!.Id!.Equals(key))

Add this new line under it (but keep both):

.Where(authorization => authorization.Status != OpenIddictConstants.Statuses.Revoked)

Note: You can rename this "authorization" lambda variable to "token"; That "authorization" there is a typo of some sort.

• Optional (some performance improvement, just like the previous one): Update method RevokeByAuthorizationIdAsync. Look for this line:

.Where(authorization => authorization.Authorization!.Id!.Equals(key))

Add this new line under it (but keep both):

.Where(authorization => authorization.Status != OpenIddictConstants.Statuses.Revoked)

Note: You can rename this "authorization" lambda variable to "token"; That "authorization" there is a typo of some sort.

• Optional (some performance improvement, again): Update method RevokeBySubjectAsync. Look for this line:

.Where(authorization => authorization.Subject == subject)

Add this new line under it (but keep both):

.Where(authorization => authorization.Status != OpenIddictConstants.Statuses.Revoked)

Note: You can rename this "authorization" lambda variable to "token"; That "authorization" there is a typo of some sort.

OpenIddictNHibernateApplicationStore.cs, OpenIddictNHibernateAuthorizationStore.cs, OpenIddictNHibernateScopeStore.cs, OpenIddictNHibernateTokenStore.cs (all optional)

• Optional (minor performance change): Delete all the implementation of the ConvertIdentifierFromString method and update it with the following code instead:

	    if (string.IsNullOrEmpty(identifier))
	    {
		return default;
            }

	    // Optimization: if the key is a string, directly return it as-is.
            if (typeof(TKey) == typeof(string))
            {
                return (TKey?)(object?)identifier;
            }
            else
            {
		var converter =
                    #if SUPPORTS_TYPE_DESCRIPTOR_TYPE_REGISTRATION
                                    TypeDescriptor.GetConverterFromRegisteredType(typeof(TKey));
                    #else
                                    TypeDescriptor.GetConverter(typeof(TKey));
                    #endif
				
		return (TKey?)converter.ConvertFromInvariantString(identifier);
	    }

• Optional (minor performance change): Delete all the implementation of the ConvertIdentifierToString method and update it with the following code instead:

	    if (Equals(identifier, default(TKey)))
	    {
		return null;
	    }

            // Optimization: if the key is a string, directly return it as-is.
            string? value = identifier as string;

            if (value == null)
            {
                var converter =
                    #if SUPPORTS_TYPE_DESCRIPTOR_TYPE_REGISTRATION
                        TypeDescriptor.GetConverterFromRegisteredType(typeof(TKey));
                    #else
                        TypeDescriptor.GetConverter(typeof(TKey));
                    #endif

                return converter.ConvertToInvariantString(identifier);
            }
	    else
            {
                return value;
            }

Solution-wide changes

• Delete "Resolvers" folder and all their contents.

• Delete any "using" references to "OpenIddict.NHibernate.Resolvers" across the solution.

• Optional: Change namespace name for all classes inside "Mappings" and "Stores" folders, to match official OpenIddict sources, by using just "namespace OpenIddict.NHibernate" instead.
  Make sure to remove any references across the solution to these older names and, when needed, add a "using" for "OpenIddict.NHibernate" instead.

• Optional: Delete/Adjust Unit Tests to match the changes.

• Optional: Add [EditorBrowsable(EditorBrowsableState.Advanced)] attribute to both the OpenIddictNHibernateContext class and IOpenIddictNHibernateContext interface (don't forget to use using System.ComponentModel;).

---

And, believe it or not, that was all of it! Well, somewhat:

There's still adding the [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All)] attribute (with a single exception in "OpenIddictNHibernateHelpers.cs" that uses, once, [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)] instead), with using System.Diagnostics.CodeAnalysis;, across the classes (easy to see where when comparing 6.4.0 and 7.0.0 sources), but that's only required if you like keeping the NHibernate stores trimming-ready. I have no idea if NHibernate is already AOT and/or trimming-friendly or, if not, if it will ever be, but if this is important to you, make sure to apply this throughout the code accordingly. For the record, EF, EFCore and the MongoDB driver do not fully support Native AOT/trimming, although EFCore is supposedly trying to get there someday.

It's also important to note that we cannot use this attribute in .NET Framework and .NET Standard (and in .NET Core before 5), so on top of all that, it'd be needed to either:

• Wrap the attributes with #if NET5_0_OR_GREATER and #endif;
• Add a reference to a polyfill such as PolySharp, which I mentioned in a previous post;
• Provide a dummy / stub of our own. I cannot vouch for its accuracy, but when I prompted an AI LLM to do it, it generated something close to this:

#if !NET5_0_OR_GREATER
namespace System.Diagnostics.CodeAnalysis
{
    [AttributeUsage(AttributeTargets.Class            |
                    AttributeTargets.Field            |
                    AttributeTargets.GenericParameter |
                    AttributeTargets.Interface        |
                    AttributeTargets.Method           |
                    AttributeTargets.Parameter        |
                    AttributeTargets.Property         |
                    AttributeTargets.ReturnValue      |
                    AttributeTargets.Struct,
    Inherited = false)]
    public sealed class DynamicallyAccessedMembersAttribute : Attribute
    {
        public DynamicallyAccessedMembersAttribute(DynamicallyAccessedMemberTypes memberTypes)
        {
            MemberTypes = memberTypes;
        }

        public DynamicallyAccessedMemberTypes MemberTypes { get; }
    }

    [Flags]
    public enum DynamicallyAccessedMemberTypes
    {
        None                           = 0,
        All                            = ~0,
        PublicFields                   = 0x00000001,
        NonPublicFields                = 0x00000002,
        PublicMethods                  = 0x00000004,
        NonPublicMethods               = 0x00000008,
        PublicProperties               = 0x00000010,
        NonPublicProperties            = 0x00000020,
        PublicEvents                   = 0x00000040,
        NonPublicEvents                = 0x00000080,
        PublicNestedTypes              = 0x00000100,
        NonPublicNestedTypes           = 0x00000200,
        PublicConstructors             = 0x00000400,
        NonPublicConstructors          = 0x00000800,
        PublicParameterlessConstructor = 0x00001000
    }
}
#endif

With this, you could use the feature for .NET 5+ targets, and not let it disturb .NET Framework, .NET Standard and .NET-pre-5 ones. However, I would not be surprised if such a stub would have to be tinkered with again, and/or the usage of the attribute itself even in the official OpenIddict stores, due to possible changes in .NET, specifically in .NET 10 and later.

In my humble opinion? I'd rather avoid the whole of AOT/trimming entirely. Memory size and startup times can improve, so it's a plus if it's working (and if you're willing to adapt it for future .NET changes), but overall application performance is not particularly improved upon. Still, it's something that can count, but just not for me.

In any case, to use this polyfill, the wrapper and/or the attribute or not is a choice that is up to you, the reader, as a developer. Make sure your choice makes sense for your scenario or situation.

---

OK, so I could stop here, but since reviewing 6.4.0->7.0.0 changes forced me to revisit everything, this gave me the opportunity to catch a few things to improve.

These are all optional, but I'll list the improvements below for good measure, and are applicable whether you keep compatibility at OpenIddict 6.4.0 and lower, or 7.0.0 and higher:

• Search and replace (Ctrl+H) every instance of : IEquatable< across OpenIddict.NHibernate and OpenIddict.NHibernate.Models with : notnull, IEquatable<. These only appear on key types, and our keys are not nullable. This also matches OpenIddict's official stores.

• Declare the classes in the following files not just as public, but as public sealed instead, for more consistency with the official OpenIddict stores: "OpenIddictNHibernateOptions.cs", "OpenIddictNHibernateContext.cs", "OpenIddictNHibernateBuilder.cs", "OpenIddictNHibernateApplicationMapping.cs", "OpenIddictNHibernateAuthorizationMapping.cs", "OpenIddictNHibernateScopeMapping.cs" and "OpenIddictNHibernateTokenMapping.cs".

• Add the following 3 new declarations to OpenIddictNHibernateBuilder:

        [EditorBrowsable(EditorBrowsableState.Never)]
        public override bool Equals(object? obj) => base.Equals(obj);

        [EditorBrowsable(EditorBrowsableState.Never)]
        public override int GetHashCode() => base.GetHashCode();

        [EditorBrowsable(EditorBrowsableState.Never)]
        public override string? ToString() => base.ToString();

• In "OpenIddictNHibernateAuthorizationStore.cs", PruneAsync method, replace comment // Delete all the tokens associated with the application. with // Delete all the authorizations based on the filter criteria., and replace .Where(token => batch.Contains(token.Id)) with .Where(authorization => batch.Contains(authorization.Id)). These are purely cosmetic, but make the code clearer and non-misleading.

• Similarly to above, in "OpenIddictNHibernateTokenStore.cs", RevokeAsync, RevokeByApplicationIdAsync, RevokeByAuthorizationIdAsync and RevokeBySubjectAsync methods, change all the lambda variable names from "authorization" to "token".

• In "OpenIddictNHibernateApplicationStore.cs", DeleteAsync method, there's a method chain for deleting Authorizations, then another for deleting Tokens. I made it so that the Token deletion declaration comes first, as nothing depends on tokens, but tokens depend on authorization. In other words, I just inverted the order of the two call chains, for clarity, if for nothing else. I also corrected the comment for the authorization deletion chain, which otherwise was accidentally copy+pasted from the token one, by replacing // Delete all the tokens associated with the application. with // Remove all the authorizations associated with the application and the tokens attached to these implicit or explicit authorizations..

• Removed any use of the "this" keyword that wasn't strictly necessary (usually flagged as such by Visual Studio). In this case, this made the code a lot clearer and to-the-point. It also kept it consistent with the current OpenIddict official stores.

• While the 4 mapping classes work as is by this point, I was able to catch various things to improve upon:

  • In all 4 mapping classes, make sure to specify the exact length for any string property/column that was also specified in the EFCore version. Otherwise I kept the length untouched. Use syntax map.Length(123);, where you replace 123 with the actual size;

  • In the Authorization and Token mappings, add an index to "Application", "Status", "Subject" and "Type" columns by adding map.Index("IX_OpenIddictAuthorizations_abc"); to their Property calls, where abc is the column name. Feel free to choose any other name for your indices if you'd like. These are also indexed in the official EFCore stores.

  • In the Token mapping, add also an index to "ReferenceId", e.g. by adding map.Index("IX_OpenIddictTokens_ReferenceId"); to the Property. Note that the EFCore version also seems to mark it as "unique" (?), but we don't do that at least in NHibernate, as the column is nullable, meaning it can only store NULL to a single entry, but future NULL entries will otherwise trigger an exception. Really am not sure how this is supposed to work in EFCore: Perhaps the setting is ignored in nullable fields in EF despite the explicit "unique" declaration? (EFCore sure does silently ignore certain configurations sometimes, such as setting string length on an integer field, as seen with "ConcurrencyToken" in the EFCore mappings.)

  • In the Token mapping, note that the length of the "Type" column was explicitly changed in OpenIddict 6.4.0 from 50 to 150 in 7.0.0: for some reason, now the values for this field are not as straightforward as they used to be, so now we have e.g. "urn:openiddict:params:oauth:token-type:authorization_code" instead of just "authorization_code". I assume this was somehow a sacrifice required for the native AOT/trimming goals? Or maybe for another reason.

  • In the Token mapping, note that although an index is declared for "Application", none is declared for "Authorization", despite both having a 1:N relationship with Token. I assume this was deliberate for a good performance or practical use reason, but I found this noteworthy to point out anyway.

  • There is a bug in the Authorization mapping, in which we have a map.ForeignKey("ApplicationId"); declaration for "Application", with the presumed intent of making the column "ApplicationId" into an FK, but what this does instead is to create two columns, one called "Application" and another "ApplicationId", in which only 1 of these 2 gets used. We fix this by simply replacing it with map.Column("ApplicationId"); instead, and optionally also use map.ForeignKey("FK_OpenIddictAuthorizations_OpenIddictApplications"); to give the FK constraint a custom name of our choosing. Don't forget to also index it, e.g. by invoking map.Index("IX_OpenIddictAuthorizations_ApplicationId"); , like mentioned earlier.

  • Similarly to above, we can give our FK constraints custom names in the Token mapping, to both the "Application" and "Authorization" properties, by using both ".Column" and ".ForeignKey" calls one after the other (and the index call for "Application", as well).

---

I wish I could fork/commit all of this personally, but I still remain under restrictive circumstances, so telling people step-by-step what to do is still the best way I can convey all of this at present, and I apologize for the inconvenience of it.

I hope all of this can help someone out there, someday. Perhaps someone else altogether might fork this and implement all that I wrote here so far.

[GreenWaves400]

I forgot to mention: below are the official public references I could consult with, with regards to OpenIddict 7.0.0+:

• Remove all the store resolvers and mark all the assemblies as trimming/Native AOT-compatible openiddict/openiddict-core#2278
• 7.0.0-preview.1
• 7.0.0-preview.2
• 7.0.0-preview.3
• 7.0.0-preview.4
• 7.0.0 Release Blog Post
• 7.1.0 Release

[vruss]

Thank you very much @GreenWaves400 ! I will attempt to do the steps you described in #1 (comment)

Your details report make me want to at least finish this project. Though I have no application that I can try it out on so I will have to create some sort of Example project too..

I created a branch for it