My environment currently has a Windows 2003 server running terminal services. That server has the visual studio 6 IDE installed. It also is responsible for running a very old ( and poorly built ) VB6 application. I'm currently testing methods for deploying a Windows server 2012 running the RDS role to our employees. One of the major hurdles has been making that legacy VB6 application available to the 2012 RDS server. Up to this point I've only found success in having an RDS client connected to the 2012 server then run a RDP session to the 2003 server to execute the legacy app. I'm trying to make the process of running that legacy app more seamless to the users. Is there a method where I could have a more seamless execution of that legacy app for the RDS clients of the 2012 server? I've been looking at Microsoft's App-V product but am still unsure if this will accomplish what I'm looking for.
App-V virtualizes the application. Use App-V when the application you want to use runs on your host OS, but doesn’t interact well with other applications on your host OS.
MED-V uses a virtual machine to host your application. Use MED-V when the application you want to deploy does not run on your host OS.
Whether VB6 is supported or not on Server 2012 and Server 2012 R2 is a rabbit hole. Regardless of it is or not, I would personally not want it installed on my server because it is ancient. Therefore, I would prefer a Med-V solution as opposed to installing VB6 directly on my shiny new server.
Well,,,I'm ancient. I still program in VB6 although moving across to VS2010 yet still using the Jet Engine!!!
You need to ensure the appropriate DLLs and OCXs are in and registered in the Windows System directory. Done using an install set. They can be copied and manually registered (regsvr32)
My stuff works on the latest 64bit Servers as VB Applications (GUI) and also VB6 code linked with Apache and PHP...100% robust, never a problem. Never.
I am slowly migrating to VS2010 as seemless as possible. VS2010 screens are crispier than VB6 else no difference. Still using DAO. ADO is mega slow. SQL Server...maybe, but, don't forget, it's all ones and noughts and I was programming when there was no such thing as a "database".
If you want an "install set" then get contact me at firstname.lastname@example.org