I have a Compact Framework 2.0 application written years ago in VB.NET using VS2005. The application uses a local SQL compact database (.sdf) file. The application has been running on HP iPAQs for years.
I want to look at making this available to Windows Phone users. Any suggestions for the easiest way to do this? When I say easy I mean quick I suppose, the client is not interested in paying for it, so if there was a crude way to implement/achieve it I would be prepared to go that route.
The alternative is building a new Windows Phone app, my first. Which would be fun, but not very good for the balance sheet! Thanks all.
Probably the only option available is going to be a wholesale rewrite of the application. If you were strategic in your original design and kept the business logic and UI separate, then that code will transfer pretty easily, but the data access code will have to be rewritten and all of the UI code will have to be rewritten.
Related
I make a game using vb.net & wpf. But I want this run on Windows/Linux/Mac.
How can I do it?
I'm sorry my english is really bad :D I use Google translate.
Implementing a solution for multiple platforms is not an easy task and you need to be familiar with all the platforms you plan to support, starting with trivialities such as different path schemes and ending with checking every reference you require by your project settings for its compatibility to the target platform.
Please have a look at http://www.mono-project.com. When you install the mono package to your system, you can run your compiled .exe as it is from the shell under certain circumstances.
Obviously, you need to decide whether you try to create one application that runs on all target platforms OR if you want to create platform specific applications all referencing to the same game engine.
If you stick very close to the framework not using external references, chances are higher to achieve the former. If the main logic of your game can easily be compartmentalized into a dedicated project, the latter is the way to go.
In general, cross-plattform compatibility is more easily to achieve if your application backend consists of a console application to be accessed by a webbrowser installed on the system - using a web frontend though. But as long as you do not require accelerated graphics, this should be feasible.
I have an application that is written in VB.NET, using the System.Windows.Forms.Form as the front-end GUI.
It runs perfectly on my Windows machine however recently there is a business requirement to convert this application to run as a web application so that people could view them in their blackberries when they go to the URL.
Is there any quick way to perform such a conversion or I will have to translate the code line-by-line for such cases?
Any help is appreciated!
Thanks!
Is there any quick way to perform such a conversion
No, not that meets your requirements. You can build custom winforms controls that can be hosted in internet explorer, but that won't help users accessing your app from a blackberry.
will I have to translate the code line-by-line for such cases?
No, it's much worse than that. Many of the things you do in a Winforms app just won't translate to the web well. You'll have to re-write and re-think a lot of your existing code. Essentially, you're not only re-building the app from from scratch, but you're doing it for a platform with which you have no prior experience. In other words, it might even take longer than building the original.
I know it's not what you were hoping to hear, but thems the breaks.
I would like to hear of the experiences of classic vb developers who migrated their applications to delphi rather than vb.net. How has it worked out? Are you glad or sorry that you didn't move to vb.net?
I am not really a vb developer but rather a Delphi developer who was forced to maintain some vb apps for a while. I tried to migrate one vb app to vb.net and after that experience I never tried it again. I successfully migrated several vb apps to Delphi. It wasn't easy and it became a pain in the lower back to find native Delphi replacements for some of the OCXes that had been used (I will never again rely on a third party library for which I do not have the source code.), but it worked out OK.
But as said above: I am an experienced Delphi developer, so I didn't have to learn Delphi at the same time as migrating a vb app. That certainly made it much easier.
I just spotted this on DelphiFeeds:
Delphi for Visual Basic developers
Help to migrate VB applications (knowledge and skills) to Delphi
I had a good friend who moved from Classic VB to Delphi a while ago (back before .NET). He was really happy with the move.
The company he worked for made applications in VB, and they put together a special team (2 developers) to create Active X controls in Delphi for the rest of the company to use. Additionally, when there was something that they couldn't do in VB then the Delphi team would do it. That was when he was introduced to Delphi.
He said it didn't take long before the Delphi team could prototype applications in Delphi faster then the rest of the development group (he never said how large, but way more then two) could. The company never made the switch to Delphi from VB because someone was under the impression the VB was a better solution despite the evidence that Delphi was more powerful and faster.
A few years are I was working with another student on our placement year. We worked for a very large manufacturing company. One of his projects was to create a classic VB app to interface with multiple cameras on a production line and analyse the data in real time. In classic VB this was a shambles - it took on average 1.5 minutes to process a single frame from a single camera (7 cameras at 24 fps) there was no that he could optimise it.
He eventually took the plunge in to Delphi and re-written that app and works fantastically. I've recently been in contact with a few friends who still work there and his app is been running smoothly for 3 years now.
I've worked in both VB and Delphi, and Delphi is (IMO) much less frustrating/limiting. You should be able to use ActiveX / OCX controls as needed (though I agree w/other comments re: avoiding there where you can, and being sure ot have full source code). Apps we've migrated from VB to Delphi (two) have gone well.
I did try in two instance to migrate from VB to Delphi but unfortunately I had to abort midway in one app as it used a lot of third party ActiveX (most from ComponentOne and a few from CodeJoke). We had to abort midway as we could not find any VCL components having equivalent functionality to the ActiveX used in the project.
It was a nightmare for us. Thank god we aborted midway and switched to C#. It was unbelievable that we could get all the features in .NET component to the ditto!
The app we managed to convert, went well off but we had to get rid of a few features that we had implemented in the original software as they required more work in Delphi.
I'm looking at rewriting an eMbedded Visual Basic app I wrote years ago. I'm unsatisified with it because of various problems clients keep having with it now and then over the years, mostly along the lines of the app not loading anymore because a required dll/activex control has gone missing! This is so frustrating and naturally difficult to debug when a client is using it far away. In alot of cases reinstalling the app doesn't fix the problem.
My preference would be to rewrite it in C# since I'm comfortable with C# and DotNet, but I'm also open to other platforms like blackberry or iTouch/iPhone so long as the platform can support maps and GPS. I'd start rewriting it in C# now but I can't be sure that I won't have the same problems in .net.
Has anyone else had similar problems with eVB apps which have gone away/persisted when moving to CF DotNet? Or would you suggest a different platform again?
Edit: Note that I wish to move away from eVB anyway, but if I move to CF DotNet I want to make sure I won't have the same missing dll/control problems.
I recommend .NET CF strongly, especially if you already know C# and .NET. Mono has been ported to the iPhone, so it is possible to write apps that will run on Windows Mobile and the iPhone. No Mono for Blackberry (yet, if ever), so that's a definite limitation. I personally can't stand Blackberries (I have both a Blackberry and a WM smartphone and the Blackberry makes me want to hang myself), but they do have a huge user base.
You should have migrated away from eVB years ago, but that's water under the bridge. If you want to continue targeting Windows CE/ Windows Mobile I'd recommend going to the CF - language is irrelevant, use what you're comfortable with.
There's no way to guarantee that whatever your "missing DLL" problem is won't happen again, since we have no idea what DLL went missing. If it was a 3rd party control, then you're at the mercy of the market. If the provider survives, it's likely their control will.
If you want to target iPhone/Blackberry then Java is more likely to be your language of choice - the tools I'm not as familiar with. Eclipse for Blackberry - iPhone may have their own tool.
As for Silverlight, you might look at it, but so far it's just way too slow to be a viable platform, at least on any WinMo device I've ever seen. We've delevered many, many CF apps for all sorts of verticals and have never had any usability problems (though we've been doing it a long time and know every limitation and what we should and should not be trying).
I suggest you take it one step further and look at Silverlight. One of the premises is that it's a more long-term-stable, portable, lightweight download and install, and it hasn't gotten krufty yet.
I think it has the potential to be the next VB for embedded. One of the difficulties with CF is that I've found it to be an insufficient subset of the real thing.
Another option is NS Basic/CE. It's highly compatible with eVB, so you will be able to keep most if not all of your code. The product has been continually updated so it runs on current devices.
The installer that NS Basic/CE creates includes all the dll files your program requires, so they will be included on installation.
I have a small diagnostic VB.Net application ( 2 forms, 20 subs & functions) written using VB.Net 2008 that targets Framework 2.0 and higher, but now I realize I need to support Framework 1.1. I'm looking for the most efficient way to accomplish this given these constraints:
I don't know which parts of the application are 2.0-specific.
I could reconstruct the forms without too much trouble.
I need to support SharpZipLib
My current idea is to find and install VB.Net 2003, copy over my code and iteratively re-create the tool. Are there better options?
Your app sounds small enough that I would create a fresh project/solution in a separate folder for the 1.1 framework, copy over the necessary files, use the "Add Existing Item" option, and then build. All the problems will bubble up to the surface that way.
A rather "ugly" approach, but it'll show you everything you need to fix up front.
Probably not. If you don't understand which bits are 2.0-specific, you're probably going to have to go the trial-and-error route. However, you can probably save yourself quite a bit of work if you go looking for generics beforehand. In my experience, those are the most numerous 1.1-incompatible bits that tend to make it into my code.
If you can gets your hands on VS 2010, you can (finally) target multiple frameworks. So within one project, you should be able to compile your 2.0 project to 1.1 and see what breaks.