I've researched this, but have yet to find a viable answer. I've run into serious problems when trying to upgrade to MVC 3. Without going into a lengthy explanation, I simply need to revert back to MVC 2. Due to restrictions in discussing work projects, I can't list all the "why's", but this is a requirement. I add this in because I saw a similar thread in which all of the answers revolved around why this should happen and suggestions to make changes so MVC 3 could stay. I can't do this.
I used the upgrade utility, so I assume many changes were made that I'm not aware of. I finally got the application to build after changing the project references to System.Web.Mvc version 2, but the page won't load, giving this error:
The view at '~/Some/Shared/View.ascx' must derive from ViewPage, ViewPage, ViewUserControl, or ViewUserControl
I can of course Google this and fix it, but I'm afraid that I'm going to encounter myriad build or runtime errors after doing it, and was hoping for an easier way to revert. Any help in doing this would really be appreciated.
As with any kind of upgrade, it's always best to plan in contingency for any issues that may occur, and back your work up prior to upgrade.
Hindsight, however, is not what you're looking for. Do you not have source control? Can you not roll-back to a previous date or change set? If not, you're pretty much going to have to go through every issue one at a time, and regression test your entire application. I don't know of any software that can revert to a previous major version (i.e. usually includes major breaking changes) without quite a bit of hassle...
Just bite the bullet and put it down to a learning experience, and make sure you get the project in to source control and implement a backup system ASAP. Even my personal projects are backed up to SVN on my NAS!
Related
I have an old Delphi application and i want to migrate it to the newest Delphi version. The problem is that the application is huge and migrating whole app at once would be too complex. I wonder what is the best approach to do this... Maybe form by form, placing a form into a dll and then using older forms in the new Delphi app and replacing them one by one (after clients confirm one form is working ok to continue with the next one). Not sure if this would be possible at all...Any other ideas?
I presume that based on your comments you do not have comprehensive test cases. In that case, you are simply in a world of pain, and there is nothing that will truly mitigate that. Without test cases, any approach you take will generate errors and bugs that will take you quite a while to catch them all. Build that into your expectations. In fact, with those as your expectations then you need to schedule a large testing phase and maybe that is a good approach. Upgrade all at once and test over the course of a few months.
You could first identify all 3rd party components that will eventually be needed and upgrade them to the latest version one at a time. That way you can at least identify bugs in a controlled manner per 3rd party component. Again, since you are relying on manual testing, this also will be error prone, but maybe you can focus on areas that use the upgraded component preferentially.
here my advice.
Before you start migrate, do a refactoring of your existing source-base.
1.) Remove un-used stuff.
2.) Try to move as much as possible to standard delphi components.
3.) Remove "un-used" units from your uses-statements.
4.) If needed, try to do some layering (App-UI,App-Logik,DB-Layer,Libraries)
5.) Look for 3rd-Party Components/Libraries, which might be not needed anymore in the latest Delphi Version, because the functionallity is now included in Delphi. If you spot such components/libraries, try to encapsulate them.
Now you have a new version of your software (still in the old delphi). Test it as exact as possible (Unit-Tests would be perfect).
If this is done, then you start to migrate to newer Delphi. I recommend to do it in one go (instead of dll and one by one).
I do not think there is enough information presented to give you specific advice.
My answer would be to bring in knowledgeable experts to look at your code, talk to your staff, look over your documentation and tests, and then present you with smart options. This can likely all be done via Zoom/Skype online. If you think about how much money you are going to end up spending on the conversion, and how much money you will spend on fixing problems because you went off in the wrong direction (and how many customers you could lose due to bugs/performance issues) this would be an extremely cheap investment.
There are a number of firms with Delphi experience that could help you. (I do not work for one and this is not an ad.) There are some well-known Delphi consultants that would likely have some free, or small flat-fee type, initial conversation.
If you are using a version before the Unicode switch in Delphi 2009, there are a number of online resources to assist. Delphi Conversion Unicode Issues
If you want some real-time advice and chatting about specific issues, check out a Telegram server dedicated to Delphi programming with nearly 800 members. There are nearly always some Delphi experts online answering questions. https://t.me/delphidevelopers You should be able to get some consultancy contacts from that server.
I know a lot of questions have been asked about VB6 migration (and I've read most of them), but I'm still not entirely certain on what the best way to go about this is.
We have a client that we built an order tracking application for about a decade back and they came to us this week saying they were having some issues with it. The app was written entirely in VB6, which has been something of a hassle as tracking down the necessary tools to work with a project so old took some considerable effort. In an effort to make any future maintenance less of a headache, my boss wants to pitch the idea to them of updating the app to .net and wants to know what exactly that would entail. I've never done anything like this before, but what I've read (both here and elsewhere) suggests that Microsoft's "auto-update" from VB6 to .net simply doesn't work very well and I'd pretty much have to rebuild the app from the ground up.
To get to the crux of my question: is this the case? Would I pretty much just need to rewrite it, or is there another means of going about this that could/would save me a lot of time/effort?
Any insight would be greatly appreciated.
VB6 and VB.NET are radically different. The syntax has changed, and so has the underlying structures, forms, custom controls, and almost every single aspect you can possibly think about.
A complete redesign and reassessment of needs and functionality is imperative. With .NET the plethora of new libraries and features supersede the antiquated VB6 libraries, OCXs, etc. Also if you feel bold, you can migrate your code to C# and other CIL languages aside from VB.
Out of hand, the Microsoft migration tool will not do much. Moreover, it also depends on whether you have your business logic well separated from your GUI. Otherwise, it will make it even harder. Depending on the size of your application, it might make it quite expensive. Another possible solution you might consider is to run your app in a virtual environment or on a remote app http://technet.microsoft.com/en-us/library/cc730673(v=ws.10).aspx that will ease the deployment pain.
I have also researched this topic.
Try the smart rewrite solution that converts 95% of the code automatically.
first, run your app through the assessment wizard to determine estimated costs and resources needed.
http://visualwebgui.com/Gizmox/Solutions/InstantbCloudmoveb/tabid/744/Default.aspx
I have a large ruby on rails 2.3 which was now a disaster because of the slowness and many bugs. I'm the only programmer and every day I've done debugging and tearing my hair off because of this. The users are already using the product but so many bugs and data are scattered.
I was employed without prior knowledge of project development and management. Now I'm suffering of having more overtime and a crisis on my codes to be fixed.
And also I've created this app while learning rails so there are codes there that became stranger to me.
What should I do?
What are your suggestions?
What books do I need to read about more?
Please I need some help.
Thanks.
I would love to recommend you upgrade to Rails 3. Especially since there are many newer features and some things are simplified, and it would ease future maintainability.
However, unfortunately, I am hesitant to (or rather simply cannot) actually recommend that given that you already have much more on your hands.
In this case, the best thing you can do is to start writing tests. If there are so many bugs, I have to assume that either you have no tests or your have an incomplete test suite. Tests will help to give you confidence that you do not break anything when you try to fix something else.
The default rails test framework can be found at the Ruby on Rails Guides. Having said that, many people prefer the RSpec testing framework. There are indeed shortcomings of the default Rails testing framework (notably the fragility of fixtures - try get a factory gem, and other features such as mocks and expectations, and nested contexts).
You should read up on the testing frameworks, and maybe try it a bit. Pick one testing framework early on however, and start testing everything!
Perhaps when you become more confident in your test suite and have fixed the most important bugs, you should think more about a path to upgrading Rails - because all the gems will march on, and gradually drop support for Rails 2.3, which means you will be using increasingly old gems which may no be well supported anymore.
From what I understood, you are asking for project managment tips and tools how to get a rails project under control.
I believe first thing you need to is stabilize the project. To do this, you will need to minimize the bugs and chart the required work.
I see two complementary approaches for this:
use a task/bug tracking tool
start using cucumber for testing
Task/bug tracking
This is very important, because you will need some kind of list that itemizes all bugs.
Sometimes users discover a bug, and suddenly you have to drop everything, because at that moment, that single bug is the most important bug ever, and needs to be solved immediately.
However, if you would ask them outright if this means the bugs you are fixing are more or less important, the answer could be different.
So it is in your advantage if there is a clear way to let the user participate in that decision process. If there is a shared bug-list, users can also follow the current state (what you are working on), they can indicate/choose which bugs are more important for them.
Secondly: having a list of items(work/tasks/outstanding bugs/...) will also help you planning the work.
There are a lot of options to some kind of bug-tracking, but some easy/pragmatic/free suggestions are
checkout trello
use the issues from github
Tracking the bugs/tasks will give you the feeling you gain control of your project, and furthermore: it will make this also more visible to your client.
Cucumber
When fixing bugs there is always the danger to introduce new bugs, definitely in a project that is originally not your own.
In a project where there are next to no tests, I always propose to start with cucumber. Cucumber has a few advantages:
it tests your application/website from the outside in: no need to understand the code fully, you just need to know what the application should do. If I click this link, it should take me to that page.
it is really easy to write tests in cucumber, and you get test-coverage really quickly
as a bonus, your test-code is readable, which you could show your clients/users, and they would actually understand what is covered by the tests (and could correct/improve it).
Upgrading or not?
I personally believe your first step should be stabilizing the project and minimize/remove all bugs. Whilst upgrading to rails 3 would be a huge improvement, it is not a straightforward process. There are good guidelines, but if you do it now, you will have no idea if a bug was introduced during the upgrade, or existed before. First get your code quality in order, and then do the upgrade.
Hope this helps.
Actually the thing you are asking is completely depending on how much refactoring you need to clean up the whole project. If you have enough time in your hand to clean it up completely. I would suggest following steps:
Getting Ready
Get the visualization of the whole project. What is required and what is not required.
Define your resources and relation between them properly.
Use proper RESTful routing.
Decide the test tools and frameworks like cucumber, rspec, factory girl etc.
Plan of Action
Decide (if possible, as a team) that what are the minimum or necessary changes required.
Isolate all the components in different groups so that each group can be refactored individually. Smaller groups are preferred.
Decide test cases.
Break down tasks into as much as small size possible.
Make sure to keep your test coverage more than 90%.
This process will take around 4-5 months for a medium scale project for a team of 4 members.
Let us know if you have any specific confusion.
What to read: http://guides.rubyonrails.org/v2.3.11/ Start with chapters about debugging and performance testing.
Forget about upgrading to Rails 3 for now, at this moment it would only introduce many more bugs and probably lots of problems with legacy gems and plugins. And don't forget that you need ruby 1.9 in order to upgrade to rails 3 - yet another batch of problems.
Adding tests is a good idea, as ronalchn suggested. I'd recommend to start with unit tests. You might have to rewrite code a lot in order for it to be testable. (In other words, instead of trying tests to fit current legacy code, it's usually better to refactor the code to make it testable.)
Unfortunately there is no quick fix in your current solution. If you seriously consider an upgrade, it will take time to fill in the missing tests if you haven't been writing them, pick up the testing frameworks on top of Rails 3, and work out the necessary data migration once you are ready to flip the switch.
The other option is to continue with Rails 2.x, which isn't completely unfathomable although the support avenues will be much more limited. You still need to work in the tests as a first priority and understand the various nuances that are present in the existing application.
For your scenario (one-man racket with little to no prior experience), I feel that sticking with what you have and improving the testability up to the point where you would feel an upgrade is worthwhile, would be the prudent action. No matter which course of action you would take, be prepared to put in quite a bit of work in the short-to-middle term (but such is the case of accumulating technical debt).
I am currently working on a large project. It is already lunched but the problem is users are already using the app and having very erroneous results. They don't complain much but each and every day I am receiving emails on errors and improvements.
I would appreciate some help in deciding weather to debug the app or just create another one. I'm working on a rails 2.5 app with old plugins.
And I'm the only one doing all this. T.T
Its really tempting on a project like you describe to toss out old code and rewrite, but its almost always a mistake (see http://en.wikipedia.org/wiki/Second-system_effect. links at end regarding rewrites are invaluable, especially http://chadfowler.com/2006/12/27/the-big-rewrite).
I'm guessing you don't have any real test suite in place, or it'd be easier to track down problems and you'd probably have a smaller project as well-tested projects tend to be well-factored (though not always). That's going to make it very difficult to reimplement and have any assurances that you've replicated all the functionality and that any dependencies work well with the "new and improved" code.
And if your users are getting erroneous results, I'd venture to say you don't actually know what the problem is, so a rewrite isn't going to fix that.
When I take over a project like this, step one is to write a suite of characterization tests, documenting the way I think the system is supposed to work AT THE PRESENT TIME. Often in doing so you'll uncover a piece of functionality that doesn't make sense or is inconsistent with the rest of the system—that may well be where your problem is. Once we're through that phase, we can start refactoring the ugly parts, cleaning up views, moving logic to someplace it belongs, removing dead code, etc. But those tests are really important to have if you want to keep the system functioning.
Finally, set reasonable expectations for yourself. Projects like this don't turn into messes overnight—you can't fix them overnight either.
Fujisan I am in the exact situation as you are. I think it is best to first debug the current rails app and then think about rebuilding it. If you are rebuilding the rails app it takes more time than expected. I started out like this:
Created a separate database and repository which has the same code and data that pulls from the live website. I use this website to work with the bugs and not on the live site.
First started off knowing what models are present and started with user model. It is best to use the rails console and dbconsole in this step if you havent used them before. It is easy to find the dependencies from the console with ruby.
Just tweaked around the models and found the relations between different models. After the models looked at the controllers. Now once I have an idea of what is happening in the application I started with a sketch of the purpose of each model and what it is doing and how and why the dependencies are made.
FInally went with working on the bugs and suggestions. The major hurdle was with gems. When the website was created by seniors the gems were very active and now they are all orphaned. This makes it hard to get answer to any of the bugs that are persisting because of those gems.
Railscasts are your best friends!
I hope that helped. Good luck!
I was thinking about switching one of my projects (and after that subsequently other projects too) to Spark View Engine but after todays research I ran into problem of a lack of Intellisense for Visual studio 2010. Not only that but it seems that the project is not maintained regularly.
So I'm left with a feeling that I should not choose Spark at this time yet. However, apparently NHaml has the same "issues" too.
I know it is discussed in more detail here ASP.NET MVC View Engine Comparison
but I would still like you thoughts on what to choose or just stay with WebForms view engine for now?
I love Sparks, compared to the WebForms view engine. All views get so incredibly clean, compared to the normal one. Intellisense or not, I'd still take Sparks. Easy choice. You still get runtime errors when something is missing, and when you get used to not having Intellisense there, it's not that much of a problem. Debugging might take those five extra seconds, but hey - readability and clean views before marginally quicker debugging of (mostly) simple syntax-issues.
I've used Spark for a project through four months now, and I'll never go back to the default one. Never had any serious problems with it once you get the hang of it, and it's absolutely worth it. You'll know when you see it in action for real :-)