Had a system with v2 running well. Swapped out the Visual Studio reference for the v2 DLL to the v3 DLL. Rebuilt the project. Errors.
I used to have things called "MyYahooCollection", now I only have "MyYahoo" and "MyYahooTable". The collections seem to be gone.
What did I miss?
I am using SQL Server 2005 on the back-end and am implementing ActiveRecord.
Thanks.
Subsonic 3 is NOT compatible with Subsonic 2. If you've got a Subsonic 2.x project, you can't "just" upgrade it. It will not work. Rob described that tradeoff pretty early in the alpha phase of 3.x.
Because 3.x uses LINQ for much of the overall approach and moves away from the *Collection objects toward more IEnumerable and List objects, it requires a much bigger refactoring to use it to replace a 2.x implementation.
v3.x isn't entirely backward compatible with v2.x. The collection classes aren't really needed any more. v3.x uses List instead of *Collection (the old v2 *Collection classes derived from this already).
Related
We have a Symfony 1.4 application and want to upgrade to Symfony 4. Is it possible or do we have to reprogram the application?
We asked a software company near us and they told us that we have to reprogram the application.
Symfony 1 is a completely different codebase using different concepts both inside the framework (or application) and with some libraries. For example it uses Propel (Active Record-approach) rather than Doctrine (Data Mapper-approach) for mapping php-objects to a database. The difference between Symfony 2 to 4 is considerably smaller, because they share the same underlying codebase and are therefore closer to each other. Upgrading can still be a lot of work because of deprecations (changed and removed parts of the code), but overall the upgrade process can be done inside the same application. Besides that, you can choose the newest version available and I would argue, if you are starting now/soon, even Symfony 5 beta would be a good candidate.
Basically, if you want to upgrade Symfony 1 you will do a migration to a new system and it will not make much difference if you move to for example Zend Framework 3/Laminas vs. Symfony 4. At least you can directly "upgrade" from Symfony 1 to 4, instead of gradually upgrading from over versions 2/3. It will require a whole lot of manual work, though. Essentially you are migrating between different applications. The Symfony docs have some general advice on how to start a migration project like this: https://symfony.com/doc/current/migration
Basically the approach would be to wrap a new application around the old one (a concept commonly called strangler application) and then move functionality to the new application, e.g. route for route, and falling back to the old application when the new functionality does not yet exist. The main reason for choosing an older version of Symfony, say 3.4, would be restrictions on for example the shared PHP version being used. There are other ways around it, but that would mean substantially more work.
Symfony Framework developer here:
Symfony does provide upgrade steps between versions. e.g:
https://github.com/symfony/symfony/blob/2.1/UPGRADE-2.1.md
But upgrading from 1.4 to 4 is BIG and will require tons of work.
I agree: writing the whole app from scratch will be faster from my experience.
Upgrading can take years for stable outcome (depending on your application size of course)
Have a look here:
https://symfony.com/doc/current/setup/upgrade_major.html
The difference between Symfony 1 and 4 might be to important, therefore you might consider starting a new project and take some of your previous code for a nicer and cleaner project.
Upgrading from 1.4 to 4 is a miracle .
Even if you can upgrade to the version 2 and then 3 untill here it's
could be nice , but the version 4 is totally different , so i can
advice you to rewrite your code directly instead of wasting time
updgrading from version to the upper one.
Disclaimer: I wrote and maintain an open-source tool that handles automated instant migrations called Rector.
Since 2018 these migrations are much easier with help of abstract syntax tree (AST). This technology allows to change one pattern in unlimited amount of files at speed of readfile/printfile.
E.g. 1000 controller from Symfony 1 to Symfony 5 will takes similar amount of time as 1 controller. All you need to do is write migration rules. Some of them are ready in Rector, e.g. Symfony 2.8 via Symfony 5 - see Rector sets on Github.
You can learn more about migration of old Symfony Applications
Upgrade symfony 2.8 or php 5.4 first?
How to Upgrade Symfony 2.8 to 3.4
How we Upgraded Pehapkari.cz from Symfony 4 to 5 in 25 days
For anyone still interested in this task, migrating a Symfony 1.x app to a modern Symfony 4.x and up (including Symfony 5.x), we faced exactly this same task with our company and I found this GitHub project that details how to do it using the Strangler Fig design pattern and the Legacy Route Loader approach that Symfony suggests on their website:
https://github.com/dkusmierek/symfony_migration_example
I can vouch that this DOES work, although there are some tweaks here and there you will need to make to make it work for your specific environment. But it should be enough to get you 90% of the way there.
I'm having trouble getting a overview of the different SQLite libraries to be used with .Net Core and/or Standard.
It seems there are primarily two:
MS: Microsoft.EntityFrameworkCore.Sqlite
sqlite.org: System.Data.SQLite
Is the MS library completely independent of the sqlite.org's libraries? And if so, which one is recommended to use?
I prefer simplicity....it seems I just need two dll's if using sqlite.org.
There are two main SQLite packages for .NET Core/Standard. They are independent and use separate native binaries.
Microsoft.Data.Sqlite
System.Data.SQLite
The former is provided by Microsoft, the latter by SQLite.org. I prefer the Microsoft one but unless you're looking for specific functionality (SQLite.org's supports encryption, Microsoft's supports fts5, etc) either one will probably work fine. They both implement System.Data.Common and so the APIs are almost identical. SQLite.org's can load arbitrary extensions which Microsoft's cannot (though with the latest release it was looking like SQLite.org's couldn't load fts5 which I know worked with previous releases).
I would recommend using Entity Framework Core or another similar third-party database abstraction package unless you absolutely can't use modelling for some reason (EFCore still lets you run the occasional low level query if you need to). It's quicker to develop, and easier to maintain the code.
Microsoft.EntityFrameworkCore.Sqlite provides support for Sqlite in EFCore, using Microsoft.Data.Sqlite. So you would want to use that in this case. The internet says you can also use System.Data.SQLite but it looks like Microsoft.EntityFrameworkCore.Sqlite still tries to load the underlying native binary from Microsoft.Data.Sqlite for some purpose, though it does appear to use System.Data.SQLite for the actual database operations. Not sure exactly what's going on there.
Microsoft.EntityFrameworkCore.Sqlite is for Entity Framework Core ORM is more complete but heavier.
The System.Data.SQLite.Core can use with Dapper ORM SQLite and Dapper but I use the Microsoft.Data.Sqlite.Core with SQLitePCLRaw.bundle_e_sqlite3 and Dapper ORM, I think I had problems with System.Data.SQLite.Core.
Use without is hard and I not recommend.
We had developed an Umbraco based site for one of client way back using version 4.7.1.
Now when the client is demanding more additions to the existing project our development team has suggested the up gradation of Umbraco from 4.7.1 to 7.1.
Main challenges we face are
Have to completely redo the project.
Some of the packages used at that time are obsolete.
Convince the client for up gradation.
The team is not entirely sure of the benefits of up gradation, i mean client does not possess much technical knowledge .
Can anyone help on this.
Help will be much appreciated.
I have upgraded Umbraco installation from version 2 all the way up to version 6, and if you followed the upgrades, that would be fine.
Version 7 on the other hand is completely new and requires a different approach for datatypes, custom sections, etc..., and will require extensive rewrites.
The Umbraco upgrade (files and datbase) might not be such an issue, this is usually well tested by the umbraco team, but the extensions you wrote might pose some serious hurdles.
Upgrading to version 6 would be an option, though the benefits will not be that visible for the client. It is more stable, and has a lot of support from the community.
Upgrading to version 7 would also mean the editors need to get used to the new interface (which might be an issue, depends if you have 1 or 100 editors), lots of code rewrites (missing packages and datatypes), and a phase where the developers need to get used to a different coding style in the Umbraco 7 back-end (all done with angularjs).
Version 7 looks very nice though, and clients might be inclined to go for it and spend the money. If not, and you are on a budget and time limits, you should move as far as version 6.
It's always tempting to go for the latest & greatest version. Personally I'm waiting for v7 to get bedded in for a year to let other people work out what needs patching and I'll be developing new Umbraco projects in v6 certainly for 2014.
Given how bad the experience of v5 was I don't think the great reports of v7 are enough to tempt me this year.
On upgrading, the reality is, (http://umbraco.com/follow-us/blog-archive/2011/11/14/the-upgrade-myth.aspx) as Niels Hartvig put it - upgrading Umbraco is a myth. To go up from 4.7 to 4.11 is certainly do-able; I've done it following this guide (http://our.umbraco.org/forum/getting-started/installing-umbraco/36855-upgrading-from-472-to-4111).
But to try to upgrade from v4 to v6 or v7 is going to take longer & result in a worse site than building a new site from scratch. A lift-and-shift job that involves the switch to MVC from asp.net forms alone is going to take more time than a new site will take to build.
The real options you have are:
Justify a new build in v6 or v7
Build on what you have in v4
Depending on your budget, expertise & priorities either option could be a good one.
You should be able to upgrade from 4.7 up to the end of the 6 branch without any major issues, I performed a similar upgrade recently. If your site uses lots of packages or custom data types, I wouldn't bother jumping to 7, as most of them won't work with the new API.
The main issues that you are likely to run in are the change in version of ASP.Net, and you'll almost certainly have to update some of your 3rd party packages along the way. I documented my upgrade here.
If they desperately want 7, I'd consider a rebuild from scratch, as a LOT changed between 4.7 and 7. The main benefits of upgrading to the end of the 6 branch are that you get a big improvement in back office performance (especially when you have multiple editors working at once), an improved media library, and a number of nice bug fixes. Most of the changes are under the hood though, so your client might only notice the snappier response of the back office and the media library, so it could be quite hard to justify the cost to them.
Would be glad to see some feedback from you in using async ctp in developing or even production.
We are starting big project and pay much attention to async programming model, so we are going to make our code 4.5 features ready buy using async ctp.
So have somebody faceoff some problems with it?
P.S. we can't use 4.5 beta in case of azure and visual studio aspects/
I would advise you against using the CTP in production, because it contains at least one serious bug. It never was meant to be used in production, it's just a technology preview.
The beta does not contain this specific bug, but I still would be very careful when using it.
Also, depending on what features of the CTP you are going to use, you might need to make changes to your code to make it work under .Net 4.5 beta (or, presumably, the final release), because there were some changes between the CTP and the beta.
Well, I looked deeply in decompiled methods with async/await syntax (the oonly feature we need from async ctp) and it just compiler magic (maybe very few runtime changes) that creates new class where all await statements starts in different threads. So I think it's quite safe to use it until 4.5 release.
This question is similar to my earlier question.
I have used ASP .Net in Visual Studio 2005 about 4 years ago. How long would it take to get back up to speed with the latest versions?
That depends on how much you "used" it. An experienced developer should have no trouble updating his knowledge of the 3.0 to 3.5 Framework changes and language specific changes. The largest introduction, I'd say since then has been LINQ, giving the ability to query data from the language level rather than SQL.
But if you're not an experience developer and don't have a good foundation in the previous version, most of what you'll be learning will be the Framework 3.0 and VS2005.
So, ultimately, if you're just going from VS2005 to 2008, it shouldn't be much trouble at all.
Not very long. The major addition to VS 2008 is support for Linq, but you don't have to use this (or any of the new features).
The IDE is extremely similar to VS 2005.
Essentially, 2005 targets the 3.0 framework, and 2008 target the 3.5 framework, but these are both just expansions of the 2.0 framework, and not new versions (unlike the change from 1.1 to 2.0).
If you were already proficient in it earlier, then you'll be able to jump into it very quickly again. The core concepts haven't changed much, so you should feel right at home.
If you were able to produce and application back then, you can probably still build exactly the same application now.
As has already been stated, .NET v3.5 is merely v2.0 with extra bells and whistles, like LINQ and AJAX. These are tools in a broader toolkit, and there is no requirement that you must use any/all of them.
So start where you left off. Refresh yourself, and once you are back in the swing of things, have a look through some of the latest enhancements, and pick out one or two that you think will be useful to you. One step at a time!
Everyone else is correct that it should be easy. I'd just add that the ListView control is one of the additions, so be sure to check that one out.
It depends on what you want to use ASP.NET for.
If you live in the HTTP Request/Response world, it will take time. Most of that time will be spent trying to shift documentations which completely ignore the Requrest/Respone world in favor of ViewState and other similar items.
If you want to go ViewState way, not too long, since Microsoft's website is overflowing with tutorials on it.
Take a look at some of the starter kits like Kigg, DinnerNow, and DropThings . You'll get an idea of MVC, WCF and LINQ. Ignore that sinking feeling and get to work learning!