Evolution-Recruitment
asked on
Better Release / Development Strategies?
Our main application is a VB6 app, which now uses .Net COM components.
I have developed the COM wrappers separate from the core .Net libraries. ALL the code in the COM libaries refers to the .Net library methods of the same name.
eg: EvoDataAccess.RunSQL has the actual code, the COM layerEvoDataAccessCOM.RunS
I created an application that copies over to the local machine the latest VB6 exe and all the DLL's (COM and .net) and registers the COM libraries and any OCX files that the VB6 applciation uses.
This works fine on client machines, but we also have an instance were we have over 20 users connecting to a Terminal Server (TS) via RDP (remote desktop).
On the TS the same "release" application creates a copy of the EXE as AppName<WindowsUserName>.e
The COM files are not so easy. Is there any other way to update the COM files without the need for the TS users to exit the application and potentially not able to use the program for 15 minutes? The current method is to get all the user out of the VB6 application...replace the COM and .Net libraries...register the new libraries...if all goes well the users are back in withihn 15 minutes. If everything goes wrong...something goes wrong with the COM files, it is potentially hours for a rollback because every mention of the classes in the registry needs removal...worst case....best case rollback replace the new COM files with the old ones and regsiter.
We cannot go the pure .net route yet and to remove the COM libaries will loose us vital functionality only capable through .net
Does anyone have a better way to release and/or develop VB6 apps with .Net COM components?
I have developed the COM wrappers separate from the core .Net libraries. ALL the code in the COM libaries refers to the .Net library methods of the same name.
eg: EvoDataAccess.RunSQL has the actual code, the COM layerEvoDataAccessCOM.RunS
I created an application that copies over to the local machine the latest VB6 exe and all the DLL's (COM and .net) and registers the COM libraries and any OCX files that the VB6 applciation uses.
This works fine on client machines, but we also have an instance were we have over 20 users connecting to a Terminal Server (TS) via RDP (remote desktop).
On the TS the same "release" application creates a copy of the EXE as AppName<WindowsUserName>.e
The COM files are not so easy. Is there any other way to update the COM files without the need for the TS users to exit the application and potentially not able to use the program for 15 minutes? The current method is to get all the user out of the VB6 application...replace the COM and .Net libraries...register the new libraries...if all goes well the users are back in withihn 15 minutes. If everything goes wrong...something goes wrong with the COM files, it is potentially hours for a rollback because every mention of the classes in the registry needs removal...worst case....best case rollback replace the new COM files with the old ones and regsiter.
We cannot go the pure .net route yet and to remove the COM libaries will loose us vital functionality only capable through .net
Does anyone have a better way to release and/or develop VB6 apps with .Net COM components?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER