Hello @devSF! And welcome to Ext.NET forums!
There's a lot between Ext.NET 1.7 and 4.7.1, so several concepts will have a different approach now. In particular, between versions 1.x and 2.x, the server-side structure changed the most.
Although there's no single "recipe" on upgrading from one version to the other, it should not be so difficult; would just take some time to get a hang of how the code changed and how tasks should be completed.
Basically, the overall structure will be the same. Some keywords change, some new keywords arise.
There are some approaches you can take to assess how a particular component has evolved, and why something no longer works.
1. Visual Studio's intellisense. As soon as you add the legacy code to a recent project, you'll get red squiggles indicating that particular parts of the code no longer resolves to valid references. With Visual Studio's IntelliSense, you can browse thru the options and see if you find the equivalent new one by resemblance. This usually works best after some experience with the new version.
2. Online documentation: Sometimes, you know what you want to do, or what it used to do, but don't know how to tell the code to do it. The documentation would help mapping syntax and semantic, and for that, you have two main sources of documentation:
-
docs.ext.net, mainly for the server-side logic
-
The Sencha Ext JS docs. The current version of Ext.NET, shipped with Ext JS 6.6.0 is based on this comprehensive online documentation from Sencha.
- Microsoft docs: because sometimes what we miss might be just in the core C# libs.
3. Refer to the Ext.NET changelogs. This can show what feature and when it changed the way needed to be handled.
-
Version 1 changelog
-
Version 2 changelog
- From version 3 onwards, we based on github, so you can see a pretty extensive changelog if you just search the github issues:
-
v3 fixed issues,
fixes including breaking changes
-
v4 fixed issues (so far),
fixes including breaking changes
- There is also this user-contributed topic with a text file containing all changelog down to version 4.0:
Text File with Full ChangeLogs & Breaking Changes
Although the change between versions is very big, the difficulty in migration is directly related to how complex the application to be migrated is. Some edge cases will exist, but some other aspects will run smooth that you won't even notice it changed.
Overall, I would recommend you not to big-bang convert the project from Ext.NET 1.7 to Ext.NET 4.7.1. I'd suggest you to create a new project and migrate the pages and functionalities one by one, so each case can be handled without the influence of other pages not running, but it is totally up to you to decide which path to take.
Hope this helps!
