Activities of "marble68"

I did indeed have to create an entirely new repository.

Only then did my migrations seem to behave better.

Thank you.

Thank you for the response. Yes, I'm seeing that I have to do that in 11.2. The heathchecker context requires -context since it, too, is a dbcontext.

My deeper question is around those migrations. After merging 11.2 into my 11.0 project, I have existing migrations and need to add another for the changes in 11.2.

So, I then added a new one, to pick up the new tables (such as password history, etc).

The end result would not apply, and it ended up trying to add a bunch of foreign keys that already existed.

Is this the normal workflow? At this point, I am supposed to edit the new migration to make it compatible with my project?

Sorry if this is a dumb question - but I'm strugging to find the "best practice" for this. I will eventually have to figure it out because I can't just wipe out my database every time I update my project.

I'm just not clear on what's required. If editing the migration manually is required, I suppose that will be what I'll have to do.

AHA - Found it! Facepalm.

When adding your view - documentation says s.Add(AbpZeroTemplateDashboardCustomizationConsts.Widgets.Tenant.DailySales,

I ran into this a long time ago - facepalm.

C

I wasn't thinking. I created my own object and just returned that, with the same interfaces as the PagedResultDto.

I think that did the trick

By the way, this package doesn't work with 11.0.

Just adding the package to the project causes it throw an error in startup.

To recreate:

Add the aforementioned package: Castle.Core-Serilog Add to Public, MVC, Host, and Migrator, just like log4net. Run - You'll get the following error:

System.TypeInitializationException HResult=0x80131534 Message=The type initializer for 'Abp.Dependency.IocManager' threw an exception. Source=Abp StackTrace: at Abp.AbpBootstrapperOptions..ctor() at Abp.AbpBootstrapper..ctor(Type startupModule, Action1 optionsAction) at Abp.AbpBootstrapper.Create[TStartupModule](Action1 optionsAction) at Abp.AspNetCore.AbpServiceCollectionExtensions.AddAbpBootstrapper[TStartupModule](IServiceCollection services, Action1 optionsAction) at Abp.AspNetCore.AbpServiceCollectionExtensions.AddAbp[TStartupModule](IServiceCollection services, Action1 optionsAction, Boolean removeConventionalInterceptors) at inzibackend.Web.Startup.Startup.ConfigureServices(IServiceCollection services) in R:\Surpathv2\src\inzibackend.Web.Mvc\Startup\Startup.cs:line 201 at System.RuntimeMethodHandle.InvokeMethod(Object target, Span1& 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.ConfigureServicesBuilder.InvokeCore(Object instance, IServiceCollection services) at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder.<>c__DisplayClass9_0.<Invoke>g__Startup|0(IServiceCollection serviceCollection) at Microsoft.AspNetCore.Hosting.StartupLoader.ConfigureServicesDelegateBuilder1.<>c__DisplayClass15_0.<BuildStartupServicesFilterPipeline>g__RunPipeline|0(IServiceCollection services) at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder.Invoke(Object instance, IServiceCollection services) at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder.<>c__DisplayClass8_0.<Build>b__0(IServiceCollection services) at Microsoft.AspNetCore.Hosting.StartupLoader.ConfigureServicesDelegateBuilder`1.<>c__DisplayClass14_0.

This exception was originally thrown at this call stack: [External Code]

Inner Exception 1: TypeLoadException: Could not load type 'Castle.Core.Pair`2' from assembly 'Castle.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.

Yes, it was something stupid..

Fixed by job doing the following:

ImportClientFromSPLService(){Logger=Logger}.DoImport(args);

To clarify, here's what I'm trying to do:

Background

I have a legacy, non aspnetzero project. I am trying to import data from the old system into this new project.

First, I have to create a client and admin user, then I have to create some default entities, then I have to create the users from the old system, and import data from there. This data includes large binary objects (PDFs, for example).

This process takes a significant amount of time. If I do this in the migrator, it succeeds because it locks the database and imports the data.

While this works, it makes applying updates painfully slow and makes me take down the system to import more data. One cient import can take as long as 30 minutes.

Challenges

First challenge is if I create the tenant with an admin user, the app services complain that the user I try and use to import objects doesn't have permissions.

For example, if my UOW uses the create tenent with admin user. This succeeds, but I cannot create a new UOW, tell the session to use that new admin's ID to create entities. I get 'not authorized'.

That entire job has to 'complete' before the application services will "see" the new admin user and their permissions.

I'm not sure, but I think this is because the background job is run as a unit of work.

Secondly, when importing the large files, as a single unit of work, the page for the entity is unresponsive (likely the table is locked).

Lastly, this import takes a long time. If I do it as a background task, the engine tries to run the task before it completes again. This makes me think I should have my background register as a singleton? Maybe have two - where a singleton kicks off the import and returns success as having run? I'm not sure.

What I'm trying to do

The goal is, as host, to kick off an import from the old system after it launches, and have the job create the tenant and setup the users, etc.

1. It'd create the tenant with an admin user
2. It'd create tenant admin accounts from users in the old system
3. It'd construct entities for the new tenant based on data in the old system
4. it'd create tenant user accounts from the users in the old system
5. It'd import tenant user data from the old system

As a background task this takes way too long. As a migration task this takes way too long.

I need to find a way to manually start this process after the system starts, and have it run in the background and be allowed to finish without timing out or running again.

I think my singleton "import manager" approach is the way, but I'm just not sure how to get there yet.

Maybe a singletone migrate control in the framework core project. Then, in core, a domain service that uses that. Then, I'd have a backgroundjob that could be started, that'd use the domain service. Since the migrate control is a singleton, the domain service would start an import, or fail if one is already running (based on migrate control's state).

the migrate control singleton could then use units of work to go through each step, each account, each entity.

Does this sound like a sound approach?

This is a good idea.

I determined why: I was importing a project into the .core project and it downgraded TZConvert.

I made sure my imported project's csproj file, packages, etc were as identical to .core as I could - and in doing so, the TZConvert is behaving as expected.

Therefore, shedspotter, check your nuget packages, and more in the csproj file - in the event you're importing a project or a package downgraded your TZConvert.

What's interesting, is if I move that function from the TimeZoneService, and run it inside the TimingAppService, it works fine.

Only when it's under Core project does it fail.