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.
相关问题
- 'System.Threading.ThreadAbortException' in
- how to use special characters like '<'
- C# to VB - How do I convert this anonymous method
- Converting byte array output into Blob corrupts fi
- Scaling image for printing
相关文章
- vb.net 关于xps文件操作问题
- Oracle equivalent of PostgreSQL INSERT…RETURNING *
- Checking for DBNull throws a StrongTypingException
- Using the typical get set properties in C#… with p
- Directly signing an Office Word document using XML
- Android - Google Play filtering out xxhdpi
- Load a .NET assembly from the application's re
- C# equivalent of VB DLL function declaration (Inte
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.