I have an application developed in VB 6.0 and VBA that uses latest Office 32 bit version. But since this application is 32 bit, it does not run on systems where 64 bit Office versions are installed. What is the best strategy I have to adopt to port this application to 64 bit. We have a mandate to use VB.NET and minimal (as much as possible) code modification from VB/VBA to .NET 64 bit. Please suggest the best option I can use so that I can leverage all best practices for this porting.
The answer of #Prof.Falken is fine, and porting to VB.NET may be a good idea for itself, but this does not guarantee that you get easily a 64 bit version of your application. If your .NET port will use 32 bit ActiveX components for which you have no 64 bit replacement, then this won't help. Here are some topics listed to be considered:
http://office.microsoft.com/en-us/word-help/choose-the-32-bit-or-64-bit-version-of-microsoft-office-HA010369476.aspx
In our workplace, systems administration decided not to install 64 bit Office on any of the new 64 bit Windows machines since here are too much applications in use (also from third party vendors) which would run into trouble else. And currently we don't see much benefits for us from the 64 bit Office version nowadays.
Here I found another link which might be interesting for you:
http://www.pcpro.co.uk/news/enterprise/356173/microsoft-warns-users-off-64-bit-office-2010
Depending on what the code looks like, one or both of these may be a good way:
a) Port it to VB.NET, or another language altogether.
b) Keep it in VB6, but replace EVERY place it talks to Office, with a wrapper call. This wrapper call talks to a VB.NET application, which in turn talks to Office.
The upshot of method b, is that it makes is possible to keep all the business logic in the old VB6 program untouched. Whether this is suitable or not depends on what the program looks like, what the programmers are experienced with, and so on. The old VB6 program and the new VB.NET could talk to each other through for instance COM or XML-RPC.
Related
I am attempting to write a dll in VB.NET for use with our various in-house apps and macros, to simplify maintenance of code that is duplicated across the various apps.
These legacy programs range from 32 bit VB6 and VBA to newer 64 bit VBA. Based on answers I found here and elsewhere I have been able to make a COM-visible dll work in either the 32 bit apps or the 64 bit apps, but I cannot figure out how to make both work at the same time on the same machine.
Can anyone explain the steps involved? Layman's terms, please, as I am not a professional programmer and am new to .NET.
If I have an application that is written in .net Compact Framework (and runs on Windows CE) and is theoretically compatible with Windows Embedded Standard O/S, would it still be compatible if it makes use of OpenNETCF functionality?
Things like running .exe files with help of OpenNETCF for example. I am assuming that OpenNETCF uses P/Invoke under the hood, which might make the application incompatible with other OS than Windows CE.
I don't use P/Invoke in my code, but I can't asnwer for sure whether OpenNETCF does or does not.
.net compact framework 2.0 and windows embedded standard
OpenNETCF does use P/Invoke extensively.
It is effectively a wrapper for some core OS functionality in Windows CE and its derivatives, that is not otherwise implemented in the Compact Framework. In practice this means extensive P/Invoking of coredll.dll; the basic OS module for Windows CE.
Windows Embedded Standard is Windows XP. For this reason I would not expect you to be able to use OpenNETCF.
Depending on the version you're using you may be able to get hold of the OpenNETCF code here (or buy the latest of course), and see what's going on under the hood. Also, what you may find is that the calls you are making to the OpenNETCF are actually implemented anyway when compiling for Windows Embedded Standard.
One way to approach this is to make another project to target this platform, containing exactly the same code files, but no reference to the OpenNETCF, then work through fixing the compile errors.
You can add a Conditional compilation symbol to either the CE project or the Windows Embedded project then fix the errors like so (This example is not for OpenNETCF, but you get the idea):
public static string ExecutingAssembly
{
get
{
#if WindowsCE
return Assembly.GetExecutingAssembly().GetName().CodeBase;
#else
return Assembly.GetExecutingAssembly().Location;
#endif
}
}
Obviously you will then have to create a build for each platform as the outputted assemblies will now be different.
As Chris points out, the SDF makes heavy use of coredll P/Invokes. That's not to say everything does, but it's certainly a minefield. I tend to have a CF project and a FFX project and places where I have overlap I use aliasing, like this:
#if WindowsCE
using Thread = OpenNETCF.Threading.Thread2;
#else
using Thread = System.Threading.Thread;
#endif
Then in the code you just do your normal
var thread = new Thread(...);
And things work out.
Now ages ago we did start an interesting side project of creating a coredll "shim" for the desktop. What that means is that a p/invoke to "coredll" on the desktop would actually call that DLL, which would in turn marshal the calls off to kernel32, user32 or whatever. Our testing for what we implemented (and there's a fair bit there) showed that it worked just fine, so if you're using a limited subset of APIs, just dropping it on the PC might make the CF assembly "just work".
Someone asked me today if it was possible to port a visual basic application to Linux or similar platform, I assumed it was .NET so I suggested to use Mono, but noticed that on their vb support page they only talk about vb 8 (.NET)
Does mono support non-.NET vb? In fact I'm not sure what he is using, I think vb6, I'm not sure of the versioning at all though.
No, VB6 is an entirely different beast from VB.NET. Mono is basically there to run (via JITting, interpreting or AOT-compiling) IL - the Intermediate Language that VB.NET and C# compile down to. (Of course it also provides the libraries and compilers.)
Running VB6 requires an entirely different execution environment, basically.
No, but you could take a look at gambas
Gambas is a free development
environment based on a Basic
interpreter with object extensions, a
bit like Visual Basic™
We are in the process of creating active-x controls used within our application.
Since Microsoft stopped supporting classic Visual Basic, is it wise to use Visual Basic to develop the Active X control or the latest VC++/ATL/MFC libraries provide more feature where we can create controls faster by leaving Visual Basic flexibility?
We will not be able to use .NET/VB.NET/C# since the application is supposed to work inside containers and containers may not support latest .NET runtime.
Any other language is best fit for Active X control development other than VB and VC++?
I, personally, would recommend using Delphi for this. It is still actively developed, and has the control you get with C++, but a rapid development environment more like VB.NET.
#nobugz: If you are really interested what is ActiveX in Delphi, look at docwiki. Normally it is 100% source code (yours + VCL, VCL is also available as sources) with autogenerated COM wrappers. So all potential security problems are also in source code. If you find a security problem in VCL, please send a bug report to Quality Central.
Here is a good example on how to create ActiveX Controls with C# .NET
http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx
By all means VB6 is the best language. After reading your question I feel that you are a VB6 developer. If you know VB6 and use it then why hesitate using it for producing ActiveX controls.
I program in Delphi as well as VB6 along with VB.NET and C# but creating ActiveX controls is the easiest in VB6 compares to all other development tools.
If you are hell bent on not using VB and if you are looking for an alternative then try out PowerBasic (commercial - very costly) or PureBasic (commercial but affordable) Get it from here or better still MinGW (a GNU C++ compiler).
I have to say that VB6 with a good book like Developing COM/ActiveX Components with VB6: A Guide to the Perplexed you will be up and running faster.
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.