For our app we are segregating users by type as they have data that needs to be segregated. Roles will not suffice as the difference between users involves data tied to the user and IExtendableObject pattern would suffer from the same issues as adding these segregated properties to the User directly.
Consider the following:
public class User : AbpUser<User>
{
....
}
public class Foo : User
{
public object FooProperty { get; set; }
....
}
public class Bar : User
{
public IEnumerable<object> BarProperty { get; set; }
....
}
The issue with the above subclassing is that it seems nearly 90% of the code from UserManager and UserAppService would have to be duplicated with mostly just type updates and permissions changes; which makes me feel like I am missing something.
An alternative approach that I considered was creating Foo and Bar with navigation properties to an optional user account. But that introduces more complexity around permissions since it would always have to be checked from the Foo or Bar object as User wouldn't have any knowledge of them. Code for this as follows:
public interface IHaveUser
{
public User User { get; }
}
public class Foo : IHaveUser
{
public User User { get; }
public object FooProperty { get; set; }
....
}
public class Bar : IHaveUser
{
public User User { get; }
public IEnumerable<object> BarProperty { get; set; }
....
}
So to summarize, what is the best approach for creating multiple user types that invloves the least duplication of user management code and is the most compatible with upgrades (minimal modification to AspNetZero demo code)? I prefer the subclassing pattern as it makes the most sense for our needs, just need some direction on making sure we don't duplicate more code than we need to. The intent is to also subclass the existing UserDtos so that we can reuse the Angular components too.
Yes, it can be reproduced in the demo project. In a pristine solution just run add-migration followed by remove-migration . You can actually skip adding the empty migration and just run remove-migration to achieve the same exception.
We've had to nuke ALL of the migrations that come with A0 and recreate them as a single migration in order to get things working properly. We're avoiding committing this change as it will create additional pain when upgrading the A0 framework.
In the github issue I linked to the problem was reported fixed, but the use case here does not seem to be covered by the fix. I would venture to guess that if the SQL Server column types were explicitly defined in the cs.designer files all would work as expected, but that requires a prohibitive time investment on our end and presents the same problem in terms of upgradability. This is something your team would need to do to maintain maximum upgradability of the framework.
One final note, I've tried to recreate this problem in a VS2019 templated project with no success. These were the steps I used:
I have been unable to reproduce in a templated app. I can, however, reproduce in a pristine copy of A0 8.0.0. Could you or I provide a copy to their team behind auth challenge and share credentials privately? A demo app would be sufficient.
This bug is having a pretty severe affect on our workflow for an application we've just started working on so we really need to get this addressed. I'm not sure how to work around it in A0, and A0 is the only app we have that's exhibiting this behavior. If you all can find a workaround, we're fine with that as well. We just need it fixed for 8.0.0 to be a viable platform for us to move forward with.
We've run into a bug with EF Core which appears to be in the EF Core team's court, not ASP.NET Zero's. The bug is documented here: https://github.com/aspnet/EntityFrameworkCore/issues/18178 It was supposed to be fixed with the 3.1.0 release which came out today, but we continue to experience the issue after upgrading Nuget packages. So far the only project we're experiencing this with is our ASP.NET Zero based solution at v8.0.0, and as such we need to share the codebase with the EF team.
How can we go about sharing the A0 codebase with the EF Core team without violating your license terms?
Yes, using single solution. Since it's pointing towards MVC directories in the gitignore we're guessing at which files should be excluded based on a previous project that used A0 5.x.
8.0.0 appears to contain the .gitignore for the MVC version of the project. Can you provide the proper version?
This is one of the more maddening things about ASP.NET Zero/ABP- when debugging the application locally I want to see where exceptions are coming from at runtime within my IDE. I know they're written to the log but that's not an efficient workflow. How can I keep ANZ/ABP from swallowing exceptions when running locally? Is this primarily a symptom of async code or specific to the platform?
I've noticed that ASP.NET Zero/ABP is still adding EF migrations to the EFCore project as of earlier this year. From time to time we update the core ASP.NET Zero framework by merging the latest code changes into our development branch and reconciling any conflicts. For the most part we try not to touch any code files that are part of the framework, but we do have to add our own migrations from time to time. Eventually we're going to find ourselves in a position where ANZ/ABP has added a migration with a timestamp prior to one of our own custom migrations, and upon merging and running update-database, it's not going to work. Is there a best practice in place for handling this situation?
Dead link on the github discussion.