I've emailed twice in resent days asking for the Metronic 7.1.5 source, and have not recieved a response yet. This is really holding our team up.
@Tusksoft
The link isn't dead, you just need to have access to the ASP Zero github repositoy, because it's private.
You can grant access to your github account by logging into the ASP Zero main website, clicking the account dropdown, and then going to github members and adding your github account there (assuming you have an active ASP Zero subscription.)
I have, but I have not seen anything about what ASP Zero project plans to do with ABP.io.
Presumably there will be a complete rewrite of the paid product, as well? What does that mean for those of us who have spent thousands on licenses for the current version?
Or do you not plan to migrate Zero to abp.io, and continue to use the legacy boilerplate framework in perpetuity?
I'm not sure how much more thorough anyone can be. Two years doesn't change the necessary setup, it's really just proper gitflow for building on closed source projects.
In case you missed it, here is the relevant description, which is quite thorough. It is also the basis for the process that we use.
https://github.com/aspnetzero/aspnet-zero/issues/96#issuecomment-268093697
I would add that we actually did not start off with this proccess, but that's ok. If you didn't start with a framework branch, and you use git, you can always check out your first ever commit, create a new framework branch from it, do the upgrade to it, and then merge that upgrade back into develop. This is what we ended up doing. From then on, we maintained the framework branch, and have had no issues.
There is no other way.
Moreover, as a product owner you need direct control over which changes are actually applied to your product during an upgrade.
We, for instance, have many customizations that we do not want overridden by framework updates. (For instance, we completely replaced the UI with angular material. We don't want that work undone every time ASP Zero upgrades Metronic or adds support for a new template (which we also have removed.))
If your project is set up correctly, the merge process is actually quite painless. Our base branch is framework, which only ever has framework changes, and this is the root from which all our other branches originated. That way, when we upgrade, we simply download the new version, replace the framework branch and commit those changes.
Then we can merge framework into our development branch and resolve conflicts, giving us just the latest framework changes since the last version.
Usually it takes us less than an hour to do an upgrade, and we have a tremendous amount of customizations to Zero itself that make up most of that time. Most people I expect will have little to no conflicts, and the process should only take minutes.
It is imperative that teams (like us) that are paying for perpetual licenses have adequate time to plan and prepare for the coming framework changes.
Use AutoMappers ProjectTo extension?
Without logs, I can't give you guidance to specific failures, but when I've encountered this issue, it's typically been an exception in the startup process.
In my cases they have almost always been related to the appsettings files. Is it possible the environment variable is not set correctly in your hosting environment, or the correct appsettings file is not being used?
Do you have the ABP pdb files?
The AbpUserConfigurationBuilder does an awful lot of work. It would be interesting to see which part of it is creating this impact. If I had to guess, my guess would be the permission and localization building.
If you don't have the ABP pdb files to debug through the ABP source code, you could always create your own implementation of the userConfigBuilder, and implement your own GetAll method exactly the same as ABP does (calling the base class methods), and then user a performance profiler to see how long each of the individual calls is taking.
<cite>TravelSoft: </cite> Hi Alper,
aspnetzero shouldn't do anything.
Let me explain.
When lazy loading is not activated, one must eager load. And thus write getallincluding and etc on their repositories where needed. So i have various protected methods in different appservices and managers that build my iquerable.
At current version of aspnetzero, lazy loading is not implemented. I am wondering will that change? This might not affect your code much, but will affect mine.
For example. At the current stable branch of my project, a dev in my team chose to reuse DTO's even though some navigation properties are not needed. those properties are at this point null. When activating lazy loading(because i like lazy loading) automapper will force ef to load those properties and changing the expected result. I figured out how to prevent this with an extra line of code where needed, but i don't really want to do that. I know this is not a good design choice, but due to some critical deadlines we won't update those dto's until we have more time on our hands.
But i still want to update our version of aspnetzero to the latest version before we modify those "badly designed" api calls in the near future.
So my real question is. Will in a future update of aspnetzero lazy loading be used and thus migrating to a new version be more time consuming(for us)? On that question i have ofcourse 2 follow up questions.
- if zero won't implement lazy loading, i'd like to know why. Not saying they should, just like to know what the motives are. Maybe i'll come to the same conclusion i also shouldn't implement lazy loading.
- if zero is planning to modify their appservice, so they use lazy loading, or just activate lazy loading by default. i'd like to know why they haven't already. Are some key features broken of EFCore lazyloading or the team just didn't get around to it or...
Just to be clear. I'm not saying anything is wrong with the current clean version of aspnetzero, or that anything should be modified.
I hope i made myself a bit more clear with this response.
As a customer, my opinion is that they absolutely should not use lazy-loading by default, and leave it up to the developer. Lazy-loading is the single worst aspect of entity framework, and it really upsets me that they caved and implemented it in EF core. It is singlehandedly responsible for nearly all EF performance issues in production websites.
