We started noticing this a day or so ago. I thought once we purchased this product we could optionally pay for yearly support/maintenance, but we could continue to use/develop/build/release the version we are using forever without having to pay each year. We have been paying yearly maintenance for support and upgrades, and are still in our previous contract period, and our license key has not been changed in source code. Any help would be appreciated.
Below is the exception details and I really do need to know how the licensing works for ASP.NET Zero. If it connects to a remote server, does it limit functionality somehow if it cannot get a license, etc. Also, how do we go about getting this resolved.
Abp.AbpException HResult=0x80131500 Message=Failed on license check Source=Abp.AspNetZeroCore StackTrace: at Abp.AspNetZeroCore.Licensing.AspNetZeroBaseLicenseChecker.<ValidateLicense>d__29.MoveNext()
Thanks, Chuck
Hi,
I'm working on adding notifications to our application. All in all things are going fine but I've noticed some strange behaviour appearing.
I noticed that unless I manually call SaveChanges before publishing notifications some fields are no longer automatically set by ABP. These include TenantId, LastModfierUserId and most likely also CreatorUserId. After investigating a bit I found that this happens because the publish notification logic switches to a Host unit of work context and performs a SaveChanges. This leads to tenantId not being available.
I then found documentation stating that tenantId should be manually set which resolves that part of the problem. However, nothing is said regarding LastModifierUserId nor CreatorUserId as far as I can tell.
My question, therefore, is: Is it recommended to call SaveChanges before switching to a host unit of work in order to prevent problems like these?
Thank you
I am using v9.1.0, .NET Core and Angular.
We have a multi-tenant application that uses multiple databases with 1+ tenants per DB. We have a an EF model that must have a tenant and can contain many entries per tenant.
The problem is that we need some of the instances to be created by us while allowing other instances to be created by each tenant. The tenants will only see what we created for them and what they created themselves - they wont see what other tenants created.
For the instances that we create they will be exactly the same for every tenant. It will not be a different set of objects we create for each tenant and we will not be creating them manually for a specific tenant - they will be created when a new tenant is created or when we install a new release of our application.
What I am trying to figure out is a good way for us to create and add new entries that we want to control. So, for example, when a new tenant is created we want to create several entries for that tenant. Also, when we install an upgrade we may want to add more instances, or modify previous instances, so we need to go through all existing tenants and create/modify them.
I see where I can hook into the tenant creation process (TenantManger.CreateWithAdminUserAsync) so that should work for new tenants. But, when it comes to adding or changing data for existing tenants when we install a new version of our software I am at a loss. Migrations might be an option, but the default Migrator application only applies migrations once to a DB so for multiple tenants per DB it would not work.
Are there any built in mechanism for handling the creation/updating of tenant specific data when a new tenant is created or an upgrade is applied? Should I try to modify the Migrator application to have it update existing tenants with new data?
Any thoughts or suggestions on how best to do this would be appreciated.
Thanks!
We are getting ready to generate our real product and have a name in mind. That name might change slightly before we actually release our product though. So, by selecting a name now what does that lock me into? Is it only the project/solution names in source code or does it force that name into the UI or other areas that our customers might see?
We have decided to move our code into separate AbpModules so that we can make minimal updates to the orignal ASP.NET Zero code. The idea behind this is to make it easier to get updates to ASP.NET Zero in the future. What we are running into is a circular reference being introduced between our AbpModule and the original .Core project. So that got me thinking maybe we are not using it quite right, or we just have a hard decision to make in terms of how we organize our source.
When creating a product with ASP.NET Zero what is the best or recomended practice when it comes to adding our own code. Should we add it to the orignal projects or should we create separate AbpModules and hook those into the original solution? It seems like if we start adding a lot of code to the original projects then it will eventually become impossible to pull in updates. I have seen some posts about how to use branching to help with getting updates to ASP.NET Zero but I am not sure if that will work for us and it seems like it will still result in a lot of conflicts and merge issues (which is expected if we are adding/removing/changing the original source.)
So, I am just trying to get a feel for what the normal/suggested usage of ASP.NET Zero is. Should we just think of it as only a starting point or initial code base, add our own code and make changes to it however we want, and not really upgrad to newer releases in the future? Or should we try to keep our code separated out of the original source so that we can more easily update it later?
I just want to make sure we start our new product in a way that works well with the frameworks we are using and gives us the best chance at being successful with it in the long term. The product we are making is not going to be a small, one-off, application but rather a large enterprise solution that we will be adding features to over many years to come.
Thanks!
This might be related to the changes made back in January (https://github.com/aspnetzero/aspnet-zero-core/issues/2892) or with the DB migration 20200305082815_Upgraded_To_Abp_5_3 but not sure. If I change the index specified in the error to not be unique I can then create an OU again but I am not sure what impact that might have on the system.
If I add an OU at the root level and then delete it and try to add another OU at the root level I get the following error in my logs. I also get this error if I add, delete and then try to add a child OU. Also, when I look at my DB I do have a row for Tenant 2 and Code 00002 but it is flagged as IsDeleted.
Cannot insert duplicate key row in object 'dbo.AbpOrganizationUnits' with unique index 'IX_AbpOrganizationUnits_TenantId_Code'. The duplicate key value is (2, 00002)
I had an Organization Unit with a Role and a User associated with it. I deleted the OU and now when I edit the User it shows that it still has the Role and that it is from an OU, but it does not show any OU anywhere. The problem is there is no way to remove this Role from the user now so it will be there forever. I have not tested if the User still gets the permission for that Role, but my guess is it will.
Is this expected behavior? Seems strange to me if it is since OU's and Roles are built in feature and not something I should have to mess with unless I want to enhance it somehow. I would expect that if I delete an OU then the Roles and Permissions that it was granting are no longer granted and do not show up in the UI.
My current OU view:
What it shows for the User that was part of that OU:
