Activities of "mightyit"

Your use case is not supported out-of-the-box. The way to go is to program tier 2 and 3 as two specialised types of tenants, and setup permissions / roles accordingly. You can also explicitly code in behaviour for things like impersonation if you need it.

If you really need seperate databases per branch, then why not just treat tiers 2 & 3 as seperate tenants?

Here it is, but, as I mentioned, there really is no other useful information:

System.ObjectDisposedException HResult=0x80131622 Message=Cannot access a disposed object. A common cause of this error is disposing a context that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application. This may occur if you are calling Dispose() on the context, or wrapping the context in a using statement. If you are using dependency injection, you should let the dependency injection container take care of disposing context instances. ObjectDisposed_ObjectName_Name Source=Microsoft.EntityFrameworkCore StackTrace: at Microsoft.EntityFrameworkCore.DbContext.CheckDisposed() at Microsoft.EntityFrameworkCore.DbContext.get_DbContextDependencies() at Microsoft.EntityFrameworkCore.DbContext.get_Model() at Microsoft.EntityFrameworkCore.Internal.InternalDbSet1.get_EntityType() at Microsoft.EntityFrameworkCore.Internal.InternalDbSet1.get_EntityQueryable() at Microsoft.EntityFrameworkCore.Internal.InternalDbSet1.System.Linq.IQueryable.get_Provider() at System.Linq.Queryable.Where[TSource](IQueryable1 source, Expression`1 predicate) at MyNameSpace.TroubleshootingBackgroundJob.Execute(TroubleshootingBackgroundJobArgs args) in REDACTED\TroubleshootingBackgroundJob.cs:line 17

@ryancyq It is the only line omitted from the Stacktrace as I actually copied it from production code. I indicated the originating line in the code snippet with the comment // <== Generates the exception

As far as I can see the EFPlus library only offers extensions for bulk update and delete, not insert. Is this correct or am I mistaken?

Hi @ismcagdas

I have implemented the temporary workaround but have came to the same conclusion as your second suggestion - that a shared library for authentication and authorization should be created. Perhaps something to consider for future versions of the boilerplate solution (if I may suggest)?

I'm not mistaken. I know the generic repository pattern. I'm talking about clean coding (SOLID) practices.

Thanks for the feedback.

This wil work as a temporary quickfix, but is wrong insofar as clean coding principles.

1. Creates an explicit dependency on a concrete class
2. Tightly couples my module to my base solution (The User class is generated as part of your base solution and inherits from AbpUserBase).

I am trying to do custom / direct registration as per the official dependency injection documentation, but without success.

Oh fudge....

Thanks. That was pretty much the approach I was trying to avoid, as it now means that "generic" services which the AspNetZero / ABP framework provides out-of-the-box can not be used.

Also, I was trying to rely on DI for Azure Functions V2 - as you can see in that post it is still very unstable.

Appreciate the input!

The "Default" connection string was set as a user secret. Once I updated it the issue was resolved.