I do not find what is different between versions 1 and 2 of signalr.
Is there a really value add to work with signal r 2?
On nugget gallery, i only see signalr. There are no distinction to work even with version 1 or 2.
Main differences:
SignalR 2 implements OWIN
Also lot of bugfixes and security issues eliminates.
For SignalR 2x you need .NET 4.5 and for 1x .NET 4.0
See release history
https://github.com/SignalR/SignalR/releases
(Nuget loads always the newest version in the case you do not define something other)
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 have been reading a while on the subject and I came across an article which left me a little bit lost on software versioning/releases.
If you follow it you will see it's just a list of all Symfony releases with their respective dates. What prompted me to ask this question was the fact that I could not get why/how, for example:
Symfony 2.8.37 released | April 2, 2018
while
Symfony 4.0.6 released | March 5, 2018
Symfony is just the example, my question applies to software versioning in general looking for an explanation to the above.
I am (am I?) positive that 2.8.37 is older than 4.0.6 so this most certainly has nothing to do with me comparing them wrong, surely there is a fundamental aspect about the versions release process I'm unaware of.
Finally, just to be sure, if I were to compare two versions, how would I go about it, I don't need a computer-language-specific-solution, just an algorithm in general to compare two given versions like you could do even using paper and pencil (I know, what a heathen).
Typically, 2.8.38 would be a security or other patch to 2.8.37; and 4.0.6 is a patch to 4.0.5, where 4.0 is a newer, more powerful base version that requires a different license or runs only under Windows 10 or some other reason why some people would like to stay on the old version.
The patch to the current version would be published faster, and then the team adds the important security patch to the older versions.
Symfony has very good support for old versions of their framework. Basically Symfony 2 was released and went through various version changes similar to 2.1 -> 2.2 etc. All the while maintaining compatibility with previous Symfony 2 projects.
Further down the road Symfony 3 was released, and while a Symfony 2 project could be updated to a Symfony 3 project it involves some work and there can be project breaking coding changes required. Then Symfony 3 progress 3.1 -> 3.2 etc.
Just because Symfony 3 is out and available doesn't mean that all work or bug fixes are done on Symfony 2. So there will still be releases of Symfony 2, in addition to releases of Symfony 3. Here is a visual view from the Symfony Page to show the version overlaps.
This is common with most software, for example Microsoft Windows 10 is the current version but Microsoft still provides patches for Windows 7.
So begins from 0.75.1, Rebus no longer supports ASP.NET 4?
My question will be:
Is 0.75 a stable release for .NET 4 project?
Are we going to continue get bug fixes (if any) for .NET 4 target project?
Thanks
As of 0.75 Rebus has targeted .NET 4.5, which was a requirement to support the usage of async/await in the library.
I'm not an expert on ASP.NET and whether the version follow the versions of .NET, but Rebus will work as long as your host process targets (at least) version 4.5 of the framework. If ASP.NET 4 is only available for projects that target .NET 4, then that implies that you cannot use versions > 0.72 of Rebus.
And then an answer to your questions:
You should pick the latest version of Rebus, but that requires that you target (at least) .NET 4.5. If that is not an option, you should pick Rebus 0.72 (which is the last version available that targets .NET 4).
No (*)
As for the (*) above, I'd like to make the following fairly long and elaborate point: Generally, you can't count on getting bug fixes for the free, open-source software you have downloaded and are using, freely, without having paid a cent - at all!
If you want to be able to reliably count on getting bug fixes for your free software, I suggest you get a support contract with a company that is willing to provide that service. My employer provides that service for Rebus in case you're interested.
With that said, I'll add that I am a pretty helpful person, and I do a lot for people to have a nice experience with Rebus, but I am sure that you can understand that I cannot promise to provide bug fixes for the old versions.
I will be around for helpful advice if you run into something, but - as I am developing Rebus mostly in my spare time - you can probably understand why I need to concentrate my efforts on the current version.
I'm thining about using symfony 2.0 for my new project. It's only preview a release at the moment, the final release is due in March which is around the same time I expect my project to go live.
Are there any reasons why I shoulnd't be using 2.0?
Reasons? Yes you shouldn't use it because Sensio who "make" Symfony tell you not to.
Even though it close to thier slated march release they could still make wholesale changes to the api which would leave you stranded and with a lot of rewriting on your hands. 1.4 is very stable and well documented and will be supported until at least 2012 and so unless there is something in the S2 technology that you cannot deliver you project without then stick with 1.4.
I was in two minds myself as i am developing app that will not get release until April or later and so was tempted. My plan is to build the apps in 1.4 but to build stripped down skeletons that match the 1.4 builds to see how they perform and to then build into later in 2011 when 2.0 has notched up a few revision numbers, and stabilised, and got a better body of documentation behind it.
The documentation for Symfony2 is really lacking at the moment, and seeing as it's so very different from symfony 1.4 (well of course, it's a total rewrite) it's rather hard to just pick up and use in its current state.
I'd say use 1.4 for now, and when the documentation picks up, give 2.0 a try. 2.0 does look exciting though, I can understand the temptation!
Can anyone tell me main steps to consider while migrating 1.1 to 3.5 windows based application?
What are the steps need to consider at initially while planing for migration?
as per i know this applicatin i need to migrate like wsf and wpf and soo on.
You'll need to upgrade the projects to .NET 3.5 Framework and then build the solution. Fix any compilation errors (there will likely be a few), and then you will need a large QA effort to make sure you didn't break anything. It's really more of just a time sink than anything you need a specific plan for.
If you can manage it, see if you can write unit tests for your app, and then after the upgrade, make sure all those unit tests pass.
http://www.codeproject.com/KB/books/net2_cs2_newfeatures.aspx
http://www.simple-talk.com/dotnet/.net-framework/.net-3.5-language-enhancements/
I guess you should look through new features and check whether a change in code is necessary for that new feature.
With the amount of effort involved and the changing to newer technologies like WPF, I think you are better off doing a re-write of the application in 3.5. We have had some ugly upgrades done at my place of work that may compile and run as 3.5 but are really just hacked 1.1 applications.