I've been tasked with re-writing an old winforms app so that it works in .net core 3. I've ran into a brick wall where the original app uses OleDB to query some large .dbf files, and there's no equivalent in .net core. Has anybody had to do similar? If so what was the best approach?
I'm stuck with the .dbf files unfortunately as these are created by a 3rd party application (That I think was created using VF Pro many many many moons ago??)
I ran into a similar problem some time ago, needing to read DBase files and finding no C# support. I ended up writing the DBase.NET (GitHub) library - it may help you out.
After a bit more research, oledb library has been ported over to .net core 3.0+...
https://learn.microsoft.com/en-us/dotnet/api/system.data.oledb.oledbconnection?view=netframework-4.8
However it looks like it's still not completely stable when dealing with VF Pro judging from this git thread:
https://github.com/dotnet/runtime/issues/981
I came across this DbfDataReader
Related
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.
I own a copy of vb2005 professional.
I need to migrate a vb6 project to vb.net
Is there any difference in terms of effort to migrating to these
editions of vb.net
thanks
I think it's slightly easier to target the later versions. I believe the PowerPack 3.0 was added for Visual Studio 2005: it included extra support for emulating the VB6 Printer object and shape controls.
Anyone who's read my other answers about VB6 migration should stop reading now because I've said this before... but I think it's relevant, so I'll say it again anyway.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. People may advise you to just rewrite from scratch in .Net. Be cautious about this - you say your codebase is big, which is a danger sign for rewriting. Microsoft UK say
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
I'm rewriting a lot of VB6 currently and what I've found so far is that the previous developers had to use a lot of third party and custom modules to implement what they need when a lot of it has been included in the base class library for .Net since then.
From what I've seen there's no easy way to migrate from one to another. A lot of effort goes into these migrations. The best thing to consider is whether you want to try to go line by line or examine the code, document core functionality, evaluate how well the software has worked over it's lifetime and then engineer a new design.
That's what I've ended up doing because a line for line rewrite is nearly impossible and a large pain. Compiling libraries and modules into COM to bring the functionality into .Net applications is a lot of effort and kind of a "McGyver" approach. That's why I just documented everything well, understood the process, then wrote as .Net software.
Specifically, what functionality are you trying to maintain? Have you written in .Net before?
In my experience the "migrate" is really a rewrite so it doesn't make any difference what version of Visual Studio you use. I'd use the latest.
Mono appears to have really come a log way since the last time I really used it. I'm interested in doing some ASP.Net development using Mono. I have used .netTiers/CodeSmith at work and really enjoy the speed with which code generation gives you a clean working data access layer. The question is has anybody used any code generation with Mono? I am open to learning something like SubSonic or NHibernate if those work better with Mono.
Thanks in advance for any help.
I have used subsonic with mono. I've used it on mono 2.0, on which SubStage (GUI front end for subsonic ) does not work, but you can generate code using command line option. It works very well with mono. I don't find any problem while using SubSonic generated code in mono.
I have not NHibernate on mono. NHibernate is very complex, I tried to learn it, but give. While SubSonic is very easy, it take me less than 1hr to learn SubSonic.
If you are interested in Linq, I suggest to you give a try to DBLinq , DBLinq team is working with Mono team to implement Linq to Sql in Mono.
This link describes it pretty well. Not entirely sure I understand it, but the end result is good performance.
http://www.mono-project.com/Linear_IL
We do have people using CodeSmith to generate code that runs under Mono. I talked to one guy who was creating a Mono Framework with CodeSmith.
Thanks
-Blake Niemyjski
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 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.