Hi,
Due to the significant amount of custom code that we have in our ASPNetZero solution, we are taking an incremental approach to upgrading our ASPNetZero instance from Version 9.2.0 (baseline) to Version 14.2.0 (latest). At this time, we have successfully upgraded to Version 10.0 and have all of our code (including our custom code) working. However, after upgrading ASPNetZero from Version 10.0.0 to Version 10.5.0, we are now encountering a runtime issue related to IdentityServer4 and dependency injection. The details are included below.
The application crashes on startup with the following error:
Castle.MicroKernel.Handlers.HandlerException HResult=0x80131500 Message=Can't create component 'IdentityServer4.Stores.IPersistedGrantStore_f2120c02-8e6b-4f2a-9b75-d1eb80f00762' as it has dependencies to be satisfied.
'IdentityServer4.Stores.IPersistedGrantStore_f2120c02-8e6b-4f2a-9b75-d1eb80f00762' is waiting for the following dependencies:
Service 'Abp.Domain.Repositories.IRepository`2[[Abp.IdentityServer4vNext.PersistedGrantEntity, Abp.ZeroCore.IdentityServer4.vNext, Version=6.5.0.0, Culture=neutral, PublicKeyToken=null],[System.String, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]' which was not registered.
Service 'Abp.Domain.Uow.IUnitOfWorkManager' which was not registered.
Source=Castle.Windsor StackTrace: at Castle.MicroKernel.Handlers.DefaultHandler.AssertNotWaitingForDependency() at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden) at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired) at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context) at Castle.MicroKernel.DefaultKernel.ResolveComponent(IHandler handler, Type service, Arguments additionalArguments, IReleasePolicy policy, Boolean ignoreParentContext) at Castle.MicroKernel.DefaultKernel.Castle.MicroKernel.IKernelInternal.Resolve(Type service, Arguments arguments, IReleasePolicy policy, Boolean ignoreParentContext) at Castle.MicroKernel.DefaultKernel.Resolve(Type service, Arguments arguments) at Castle.Windsor.WindsorContainer.Resolve(Type service) at Castle.Windsor.MsDependencyInjection.ScopedWindsorServiceProvider.ResolveInstanceOrNull(Type serviceType, Boolean isOptional) at Castle.Windsor.MsDependencyInjection.ScopedWindsorServiceProvider.GetServiceInternal(Type serviceType, Boolean isOptional) at Castle.Windsor.MsDependencyInjection.ScopedWindsorServiceProvider.GetService(Type serviceType) at Microsoft.AspNetCore.Builder.IdentityServerApplicationBuilderExtensions.TestService(IServiceProvider serviceProvider, Type service, ILogger logger, String message, Boolean doThrow) at Microsoft.AspNetCore.Builder.IdentityServerApplicationBuilderExtensions.Validate(IApplicationBuilder app) at Microsoft.AspNetCore.Builder.IdentityServerApplicationBuilderExtensions.UseIdentityServer(IApplicationBuilder app, IdentityServerMiddlewareOptions options) at XXXXX.Web.Startup.Startup.Configure(IApplicationBuilder app, IWebHostEnvironment env, ILoggerFactory loggerFactory) in S:\XXXXX-CUSTOM\Main\Source\Abp\XXXXX.Web.Mvc\Startup\Startup.cs:line 278 at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Microsoft.AspNetCore.Hosting.ConfigureBuilder.Invoke(Object instance, IApplicationBuilder builder) at Microsoft.AspNetCore.Hosting.ConfigureBuilder.<>c__DisplayClass4_0.
It is important to note that we have not made any manual changes to module registration or IdentityServer setup, as we expected the framework upgrade to handle this. All relevant IdentityServer4 registration code, modules, and configuration are already present in our codebase (e.g., XXXXXMvcModule, Startup.cs, and IdentityServerRegistrar.cs).
Despite this, it appears core dependencies are not resolving correctly in the DI container post-upgrade.
Could you please advise on what might be missing or misconfigured during the 10.0 to 10.5 transition? We understand that IdentityServer4 has been deprecated and ultimately removed as of November 2022, but we believe that this took place around ASPNetZero Release 12.so this attempted upgrade from 10.0.0 --> 10.5.0 should not be impacted by this deprecation. Please advise. Thank you.
2 Answer(s)
-
0
Hi,
Do you have these code blocks in your DbContext ?
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi @ismcagdas,
To answer your question, we did have the code blocks that you identified in our DBContext and still encountered the same issues. As I mentioned in our original post, we do have a significant amount of custom code integrated into the ASPNetZero solution, so we have noticed that taking smaller steps in our upgrade path has resulted in more manageable resolution of merge conflicts.
Rather than upgrading from 10.0.0 to 10.5.0, we upgraded incrementally from 10.0.1 --> 10.0.2 --> 10.0.3 --> 10.0.4 --> 10.0.5 without any issues. Thank you for your asssitance and support.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image)
