Can Delphi 4 and\or 5 application functionality (.exe) be integrated into a C# application?
I've been tasked with rewriting a new application which will be based off of existing Delphi 4/5 written application, which are currently held together with a Batch Processing Script that no one at my company understands.
As an interum solution, I've been asked to investigate whether a C# GUI\wrapper can be placed on top so it's easier to maintain and run.
I know that Delphi 6 applications can be called within a C# application using reflection but I'm not entirely sure how.
So back to my original question can a Delphi 4/5 application functionality be called within a C# application?
Thanks in advance.
The underlying premise of the question appears to be that a C# wrapper around a Delphi core is easier to maintain and run, and if that is not true, then the idea of creating the wrapper becomes not-very-useful. I believe it is a wrongly-conceived notion.
Imagine that I made an application that can talk to a telescope. It does it perfectly. In that case, I might be able to extract just the telescope-communication part and put it in a DLL and then write a user interface in C# that uses the Delphi DLL just to do the communicate-with-telescope task. However, unless your Delphi application was already structured in a nice way, and unless a task like this telescope-communications library already exists, you won't find it very easy to extract any part of a Delphi application, and use it from C#. If that situation existed, I would use native Delphi DLL function exports and invoke them from C#. This is not using the existing delphi executable, and requires many hours of work to refactor part of a Delphi application into something that could be used from C#.
Another answer mentions COM Servers, and while that is possible, it is not going to make things easier; Like the old joke about regular expressions; When you have a problem and try to solve it by using regular expressions, now you have two problems. The same becomes true when you try to use COM Servers to hide your existing application and write a whole new UI on top of it using C#. It would actually take more technical skill to improve, debug, and continue to develop it that way, than to keep developing it either purely in delphi or purely in C#. It's a negative savings of effort.
You have given no information about what the Delphi application does, but let's assume that it's a line-of-business or vertical market application that reads some file format, or does some communication protocol, or even connects to some old database, that you don't want to rewrite.
If by making the C# UI you mean, to never show the Delphi application user interface and replace it with a C# one, it is nearly certain that your idea is not going to make anything any better, and can only ever make things worse. Your deadlock either comes from not having skilled delphi developers, or else it comes from not having clever developers who can figure out what an existing application does.
The solution is usually a human solution when you are in this situation; either to hire a skilled delphi developer and bring the application forward into the modern Delphi era (Delphi XE2) or to hire a skilled non-delphi developer and port the application to some other language. Anybody who would suggest writing a "wrapper" over top of the delphi application who thinks that will make it "easier" obviously feels incapable of rewriting the existing application.
I don't know enough about what your delphi application does, to be sure, but it sure sounds to me like "fear driven" decisions. Wrapping old code is almost never a good idea, and is most often, just the creation of more problems.