Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
If I am looking to reference a .NET dll from PowerBuilder (10 or 11.5), which of the following is the best practice?
1) Register the dll as a COM Object, and use the COM Object via an OleObject
2) Upgrade to 11.5, and convert to PB.NET so that I can actually have blocks of C# in the PowerBuilder code
3) Another method
What are some things I should be aware of with these approaches?
I haven’t done anything with PowerBuilder, but this is the technique we followed (pretty successfully) with a project that could not immediately be migrated from VB6.
1) We created a shim/facade with COM references to expose the .NET items we needed. (We also specified the GUID’s using attributes so we had complete control over compatibility changes.)
2) We referenced the COM objects in our VB6 code (as you would in the PowerBuilder code) using the built in object handling (OleObject in your case).
3) As items were migrated (in our case to C#), they referenced the underlying .NET classes instead of the COM shim. (We tagged the shim with Obsolete tags to ensure that nobody used it accidentally.)
4) After all references to the shim were migrated, we removed the shim. (We actually did that in two phases. In the first phase, we left the shim in but modified it to throw exceptions and log what information it could about the calls. That way we would have an idea about where any calls to it were being made from. After confirming that there were no problems, the shim was removed in the next phase.)
The advantage of this to us was that the migration could occur incrementally. We chose not to expose the underlying .NET objects directly because there was still some risk of them changing and we needed the COM interface to be as stable as possible.
Upgrading to PB.NET is certainly a possibility… but I don’t know how complex that migration will be. You may find the time necessary would make the migration a major project (it certainly would have been for us).
Other methods which we considered, but rejected as inappropriate for our needs were:
Wrapping the .NET components in another application (a “service”) and talking to those components via socket communication.
“Shelling out” to utilities using the .NET framework and transferring the information via (for example) a file based mechanism.
Things to be aware of include:
The threading model in use on both sides of the link. (We hosed ourselves at first because one part of the system ran MTA instead of STA – see this question for more information.)
What an exception on the .NET side will look like from your application. It may be a very unhelpful “generic” error, and may even appear to be in the caller instead of the .NET code. We added logging on the .NET side which gave a more verbose record of any exception before re-throwing it and letting the caller handle things as best it could.
I hope this helps. Good Luck!