AS the new v.7 version of asp.net zero is released, is there any best way to update a current solution based on v.6.9? Would be nice to have some kind of help/checklist to follow if possible how to upgrade if possible.
17 Answer(s)
-
0
Hi @webking
There are no automatic steps but you can check https://github.com/aspnetzero/aspnet-zero-core/issues
-
0
I'd like some insight into this as well or a best practice guide on how to go about upgrade to new vesrions.
-
0
I'd also like to have a best practice guide or something similar
-
0
For a product that is supposedly under support, i cant image why there is not an upgrade guide.
The only reason, i can see is lazyness on the part of the developers.
-
0
There are several things to understand about ASPNETZERO. It is built as a framework to create your Web app on top off and as an upgradable product. They've done a ton of the heavy lifting for you with authentication, authorization, etc. They don't say that there is an upgrade path (although there are some ways to branch that you can find in this forum).
In the case of 6.9 to 7.0 it is a very big UI change since they updated the underlying Metronic theme system (www.keenthemes.com) from the 5.x version to 6.0. That means you would need to change lots in the layout.cshtml files across the entire application.
-
0
Thanks @outdoored :).
@commondesk, Actually AspNet Zero is not designed as an easily upgradable product since we deliver the source code. We really care about your comments and want to provide a better service. If there were automatic steps to upgrade from v6.7 to v7.0, we would make a tool or something like that to do it for you.
I can offer you using Git to merge our changes into your solution but probably there will be many conflicts. You can still take a look at below links:
-
0
**@webking **
It was a bit of a manual process, but my upgrade was done by:
- Starting with a clean copy of 6.9.1 - straight from downloads section (or in my case from my first git commit)
- Downloading clean copy of 7.0.0
- Using BeyondCompare and performing a full diffmerge to identifty the differences between the two.
- Using that diff report as a guide, manually applying the changes to a branch of my code. Luckily I made few changes to pre-existing code so this was a fairly straightforward process.
- Doing some global search and replaces for the naming convention changes from Metronic 5 to 6. basically m- to kt-, etc.
All told it was about a full days' work.
-
0
@outdoored and @ismcagdas
I will have you note that I did not say, an automation script or an automation tool, i said an upgrade guide.
A guide is documentation. The documentation would describe the process for upgrading, such as the steps provided by @dnard82 but would be fully expanded and professionally written. BTW, thanks for your comments @dnard82.
The guide, would describe all of the changes that occurred between releases, it should describe additions, changes and deletions, and how the changes would impact your current code base.
Many other frameworks such as Servicestack provide release notes:
https://docs.servicestack.net/releases/v5.5 https://docs.servicestack.net/release-notes-history
Compare that with your "Change log"
https://docs.aspnetzero.com/documents/aspnet-core-angular/latest/Change-Logs
Here is an example of how Servicestack talks about how there upgrade has broken things in older versions
https://docs.servicestack.net/releases/v4.0.40#servicestack-changes
In my 30+ years as a professional developer and business owner, I've used many many frameworks for products that I've built and sold to company's.
Until you have professional documentation and a process for upgrading, you do not have a professional grade product. That's fine, but non-professional products don't ask $2500 a year for a licences.
We all know whats going on. Your team is now building a new product and don't want to invest in providing real support around this product.
Because of your naive attitude to software development, I hope to move away from ANZ as soon as i have the developers and time to do so.
-
0
I would, respectfully, disagree with the assertion that ANZ is not a professional level product. What they sell is source code plain and simple and they are up front about what they are selling. Having built a lot of software over the past 20 years and paid other developers a lot of money to write code for me, there is no way that I could get the breadth of what the ANZ folks have built by paying an outside developer just $2500. From scratch would be in the Tens of Thousands of dollars US range. I am happy for what I have paid for since it was much less expensive than anything else I could have paid a developer to code. The quality of the code is also very good. I've had multiple top developers work with it and they have been impressed with the code quality.
I too wish that upgrading was something that was an option because when they release a improvement, I am left in the dust which is disappointing. But that does not mean that ANZ is not a professional grade product. In moving from the MVC Jquery version to the Net Core Jquery version I spent a lot of time documenting where my code fit in with theirs to make an upgrade process more feasible. I believe that there are some things that they could do with their code that would make it easier to upgrade:
- Things like making certain classes partial so that we can derive our own separate class files. Case in point - the DbContext.cs. I could have all my entity code in a separate class and simply overwrite the ANZ DbContext file from a new version if I didn't have to put all my stuff in their DbContext.cs (Of course I could do this myself but then I'd still have to go in and edit their new DbContext each time to be a partial every time).
- Publishing a list of code changed files for each version number would make it a lot easier to know where to look than dnard82's BeyondCompare check of every single file.
- Some things are in Nuget packages, and knowing what version of each Nuget package is associated with a new release would also be helpful.
- Finally, publishing any SQL Migration Scripts for backend database changes (like when they went from datetime to datetime2 would really be useful for me to be able to keep my database tables in line with the FullyAuditedEntity. (Yes that is in the .Migrator, but it should be part of the documentation for each version)
-
0
thanks @outdoored for your opinions. since we deliver the source code and developers are free to modify it, it's hard to automatically upgrade to newer versions. but I suggest you to fork the repo from GitHub and use GitHub Desktop tool to compare changes. So that you can see the changes easily. Some common files like DbContext usually conflicts with the newer versions. In that case, you can manually merge it, or you can insert your custom code from an outer class with a single line. As a result, yes it's hard to upgrade! We saw this handicap and redesigned this behaviour in the new framework abp.io.
-
0
@alper, Yes its hard to upgrade, but all i'm asking for are notes on what problems are associated with upgrading. If its as easy as you say, it should be a 15 minute exercise for an intern to write the documentation. But instead of listening to my suggestions, its shoot the messenger.
Many company's offer access to their source code in GitHub. But that does not mean the company does not have a responsibility to assist in helping users upgrade.
My problem is not with the product, my problem is with the support i'm receiving for $2500 a year.
For far less money, ServiceStack provides far better support and better documentation, and the product is vastly more complex.
I suggest that you review how ServiceStack and other approach the problem of upgrades and releases.
-
0
@**outdoored, **
The point is that ANZ should be thanking us for taking the time to improve their product, by providing suggestion. Instead they deny the changes are needed. The reason goes back to the fact that the company is managed by developers who are only intrested in the next product.
Things like making certain classes partial so that we can derive our own separate class files. Case in point - the DbContext.cs. I could have all my entity code in a separate class and simply overwrite the ANZ DbContext file from a new version if I didn't have to put all my stuff in their DbContext.cs (Of course I could do this myself but then I'd still have to go in and edit their new DbContext each time to be a partial every time).
I wrote about this awhile ago. Instead of partial classes i suggested to have base classes and use inheritance.
https://support.aspnetzero.com/QA/Questions/6814
- Publishing a list of code changed files for each version number would make it a lot easier to know where to look than dnard82's BeyondCompare check of every single file.
Exactly. This is why i said they were lazy. I found that the "meld" product on linux does the same thing. It appeared to be easyer to use than "BeyondCompare"
- Some things are in Nuget packages, and knowing what version of each Nuget package is associated with a new release would also be helpful.
- Finally, publishing any SQL Migration Scripts for backend database changes (like when they went from datetime to datetime2 would really be useful for me to be able to keep my database tables in line with the FullyAuditedEntity. (Yes that is in the .Migrator, but it should be part of the documentation for each version)
<br> <br>
-
0
At the very least I could use an upgrade guide from 6.x to 6.x. Let us know if this is something you will consider helping your customers and community out with.
Thanks!
-
0
@ismcagdas In general I would recommend that you split the default generated / main solution up into smaller modules. The main solution tends to grow quickly in terms of complexity and size, and upgrades become increasingly more difficult and unmanageable. Smaller modules means you could also do your releases for particular modules, meaning smaller, more manageable merges.
Good candidates for seperate modules:
- Identity & Authorization
- Payments, accounts, subscriptions and editions
- Auditing and Logging
- Localization and Internationalization
- Main
-
0
@commondesk
The point is that ANZ should be thanking us for taking the time to improve their product, by providing suggestion
We absolutaly do, thank you for that. The main problem for upgrading is not the server side part. It is very easy most of the time. The problem is the UI part.
@papayt
As I said before, it is hard to prepare such a document but we will be happy to help you all if you face problems.
@mightyit
You are absolutely right. We came to same conclusion and we are working on https://abp.io/ and it provides such a modularity by default but probably it will not be available in AspNet Zero.
-
0
Hi @ismcagdas,
Do you plan to integrate the new ABP framework into ANZ or to build a totally different product?
-
0
those are totally different products with different architecture except being .NET Core. Even some code is similar, there's no way to integrate it. You need to manually copy the business code to the new framework. Also you need to rewrite the front-end.
