Hello,
I have a few core modifications I think would be beneficial to added to ANZ. Can I submit these in gitbhub via a PR? They can be used or not, just figured I would provide them.
Well that was silly of me. I didn't realize AppCommonModule was not in scope of subheader.module; importing it solved my issue.
Running Angular w/ aspnetCore, 10.5.0
I'm having difficulties trying to add a simple modal component into the sub-header module; it seems wherever I make the declaration for my modal module, it's inaccessible to the sub-header. The modal just a trimmed-down version of most of the ModalComponents, showing only a title and localized text string that are passed in.
When I place in any admin/main page's module and call, everything works as expected. It's only in the sub-header where I get the 'Cant bind to X since it isn't a known property'. I am probably missing something incredibly simple...
import { Component, Injector, ViewChild } from '@angular/core';
import { AppComponentBase } from '@shared/common/app-component-base';
import { ModalDirective } from 'ngx-bootstrap/modal';
import { merge as _merge } from 'lodash-es';
@Component({
selector: 'simpleInfoModal',
templateUrl: './simple-info-modal.component.html',
})
export class SimpleInfoModalComponent extends AppComponentBase {
helpText: string;
modalTitle: string = 'Info';
@ViewChild('modal', { static: true }) modal: ModalDirective;
constructor(injector: Injector) {
super(injector);
}
show(helpText:string, modalTitle?:string): void {
this.helpText = helpText;
if(modalTitle)
this.modalTitle = modalTitle;
this.modal.show();
}
close(): void {
this.modal.hide();
}
}
Thank you!
pre-reqs -- v10.5.0, Angular with .net Core.
Was wondering if there was an ETA for power tools VS2022 support?
D'oh! Can't believe I didn't think of that; you're 100% correct, thanks for a great product and great support, @ismcagdas
@Zony, thanks for your reply. Yes, they do. I see them immediately in the database and also via an application service reading the same values.
Hello,
I'm running into an issue with my background workers; I have a job set up to run every 5 minutes, which calls a domain service to process some data. My domain service is calling await SettingManager.GetSettingValueForApplicationAsync() to retrieve a application-level setting value.
What seems to be happening is, when I change this value through the web interface, my domain service still receives the old value. I have tried going through maintenance to flush the caches manually, but the old value is still received until I shutdown and restart the application in IIS.
Has anyone run into an issue similar to this?
Thanks @ismcagdas I re-ran npm run build, did a full clean+rebuild, and that solved my issue. Appreciate it!
I recently added azure blob storage to my application, with container generation based on the tenancy name. The approach I took, in hindsight was probably overkill. But I went with a generic implementation to allow for additional storage options in the future. I created entities for ConfigurationProvider and ConfigurationProviderParameter - so in this example Provider would be "Azure Blob Storage" and Parameter holds entries for things like DefaultContainerName and ConnectionString. Then entities for ConfigurationEntry (IMayHaveTenant) and ConfigurationEntrySetting holding tenant-specific values for my provider parameters.
After that point I have abstract classes for my providers, and an implementation of that base class for MicrosoftAzureBlobStorageProvider, which handles the comms to/from azure. I should note I'm using Abp.Dependency.IIocResolver class to dynamically inject the class needed. The class name is storage in the ConfigurationProvider table, e.g. 'Xyz.Factory.Storage.Providers.MicrosoftAzureBlobStorageProvider, Xyz.Application'.
If you are not planning on switching between providers then you could greatly simplify this by going straight with AppSettings entries for your azure configuration
Upload references are stored in a separate table. So as to not continuously ping Azure, I save to my db table things like contentType, fileSize, directUrl to the file (assuming it's in a public container), ETAG, and some basic metadata (dimensions for images, for example).
The nice thing with Azure is if your containers are public, you can save the path to the file and serve it directly to a user to save on your bandwidth. If you are working with blueprints you may need a little additional security, in which case you can mark your container as private, still store the direct path to the file on your end, and use the azure API to essentially stream the file to your server and then spit it back out to the end user. That way you can be sure files are protected against unauthorized access to anyone knowing the url.
hope that helps!