Is it possible to use a C# assembly from Clarion? If not. Is it possible to run a simple console application written in C# and read the output from it back into Clarion? In both cases, how would you do it? In the case of the assembly, would you have to do something special with it for Clarion to get access to it? In both cases, how would you do it in Clarion?
The reason is we have two methods written in C#, which is used by an application written in C#. But we also need to use that same method in a Clarion application. And we really don't want to write the methods again for Clarion, since they are a bit complex...
Unless you need to display a .Net UserControl in your clarion program I would recommend using the technique described here:
Robert Giesecke - C# Project Template for Unmanaged Exports
On the Clarion side you then just link and use the .Net assembly as you would any other unmanaged DLL. I have found it convenient to load the DLL at runtime with the LoadLibrary API too.
A Clarion program will not easily or nicely call a C# DLL, though the reverse is not necessarily true.
In a project of mine, I decided to go with a minimum of coupling between a Clarion program and a C# assembly by using TCP/IP.
The idea is to have the Clarion program connect to the listening port of your mini-server, send a request and receive a reply, in the same way that a function is called with parameters and a result received.
It is easy to add a class in your C# assembly to act as a TCP/IP server. On the Clarion side, there are a handful of good templates that offer TCP/IP functionality. We have been using CapeSoft's NetTalk template for years and it is virtually rock-solid.
Depending on the urgency of your requirement, you might consider this route.
-Ray.
What is Clarion? Is it an unmanaged application? If it is, then the "something special" you would do to your assembly is called Com Interop: http://msdn.microsoft.com/en-us/magazine/cc163494.aspx
Clarion is a programming language. Don't know it myself. Parts of the old system where I work is made with it, and we are working on porting it to C# .NET. So for a while they have to live side by side. We found a work around so it is no longer needed though. But thanks for info :) Maybe we will need it further down the road instead. Although I hope not... hehe.
For those curious: en.wikipedia.org/wiki/Clarion_(programming_language)
Related
Clarification. There is a C++ exe and a C# exe. The C# exe is a wrapper for a C# dll. I need the dll to call a logger function in the C++ code (so that only one log file is produced). Currently there is a c++/CLI bridge which allows the C++ exe to call methods in the C# dll.
Apologies if this is a poor question. Its possibly a case of I just don't know what to search for / results for what I am searching for isn't of much use.
I have an application written in C++. It calls a tool written in C#. It appears the executable for the tool is just a wrapper for a c# dll.
The tools purpose is to analyse and display data. The main application calls it for example to have it open a new file. The tool has never had to call anything in the C++ code before so this has always been one way. It appears to be implemented via a C++/CLI bridge. The bridge calls the functions in the tool api.
It is now required for the tool to call some methods in the C++ application. I have no idea how to go about implementing this. My c# / C++/CLI experience is somewhere between poor and non-existent. I started by attempting to clone the C++/CLI bridge and "reverse" it, but since the C# code is in effect a library calling it from the bridge is fairly simple.
However, i'm not really sure (if its even possible) how to call the C++ application from a bridge.
So far the only workable solution I can think of is to have the c# code output to a file (or hopefully shared memory) then the c++ code check it periodically. This isn't close to ideal.
Any advice would be appreciated.
Thanks
Ok, i think i'll throw in a suggestion here.
Depending on what your goal is:
1) Goal: execute some of your c++ logic from c# code.
Solution: this one is fairly simple. You extract logic of interest into separate C++ project, build it as a library and then use it in both applications. As you said, there are plenty examples on how to call c++ dll from c# code.
2) Goal: froce your c++ application to execute some of it's logic from C# application.
Solution: it all comes to setting up an interprocess communication. There are quite a few approaches, that are listed here. I suggest using NamedPipes but you are free to pick w/e you are comfortable with.
Edit: Judging by your edit you probably want the second solution.
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.
A Delphi .exe can be run from C#. But I guess this is not your point.
You can either use a COM server, which is standard but needs the COM object to be registered on the computer (by running regsrv32.exe). Not so easy to deploy.
Or you can define the Delphi code as a library, then load and execute the .dll from the C# code.
If you prefer to access C# objects from Delphi 4 or 5 (that is access C# RTTI), you'll have to use some low-level unit like Managed extensions for VCL - .Net interop for Delphi Win32. Which is quite complete, and works with old versions of Delphi (whereas something more high-level than Hydra will not support Delphi 4 or 5, sadly).
Edit
Another possible easy communication is GDI messages. You can send GDI commands from your C# code to control the Delphi application, but using PostMessage() API calls.
Sure. C# can call any .exe. Just use Process.Start:
http://www.dotnetperls.com/process-start
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx
Delphi 5 supports implementing COM server functionality (don't know about earlier versions, D2 definitely did not).
If you have the sources available,
add a type library and a COM implementation of the interfaces defined in the type library,
register the executable (typically done automatically on startup thanks to Delphi magic)
follow the steps on MSDN: Exposing COM Components to the .NET Framework
I have a (header only) C++ library that I am looking to port to C#. It is a wrapper of the win api which I have made for a certain purpose. I want to port it to C# because I want to develop it further using C#. What is the most efficient (and easiest?) way to port it. Please note that I do not want something hectic because I don't want to spend more time porting the library than it took to make that library in the first place. So is there a way?
It depends very much on how big your lib is, how it is structured, how your memory allocation looks like, how much you made use of libs not available in C# (like the C++ std lib), how much C++ template programming you have used etc.
Different strategies may be
try to port (parts of) it automatically by some code generator of your own
do not port it to C#, instead use C++/CLI (something I did very successfully in the past)
do it manually because the C++ concepts you have used so far don't map well to C#
"Header only" does not seem to make a real difference. In fact, things may technically get a little bit easier when you have just one C++ file for each class to be ported to one C# class file.
A couple of ways I can think of.
Manual conversion to C# dll with possible code generation help of T4.
Change your c++ library to a managed dll so you can use it in your c# project.
Of course, you might use interop with your c++ library in your C# project. But in that case, I am not sure about purpose of your c++ library since you said it's a wrapper.
Since you already have c++ library that you can fully control, I would try to go with #2 first.
I'm just looking for a best way to re-use code written in c#, in my c++ projects. Creating a com\service doesn't look like a best option for my needs. How difficult it is to export c# code into a dll and use it in c++? can i get some suggestion or example? is this usual requirement or ? Please help me.
i use win7, VS2008, win7sdk
Thanks & Rgds, ~calvin
Executing managed code from an unnamaged executable is possible, though not quite easy. You can look into this article for an introduction and this book to go further.
I personally would avoid this kind of things in most cases and, if possible, switch the C++ project to C++/CLI to obtain an immediate compatibility with .Net assemblies for a minimal cost.
You can't export C# code into a native dll afaik. At least without very much pain in your buttocks. You should have thought beforehand and write the reusable part in C, thus creating a native DLL which could be used from all languages.
Also, you could try managed C++ - I personally hate it... but there you go
In case you need to use code written in C# C++, then you need to first see what all data types you would be passing from your C++ code to C# code.
1. Basic data types like int, enum etc can be passed from unmanaged to managed code.
2. in case you want to pass on class object, than you need to use marshalling.
If you can't use COM (if the .NET code is already written for example), then you can host the CLR, but this is a long road...
See these other articles
How to load CLR into process and Create a C# DLL That Can Be Imported in a Delphi App Using stdcall - Possible?
I just got handed an SDK made of C++ dll, lib, exe, and various .h files. I presume it is meant for C++ developers. The sample projects they provide with their documentation are all written in C++. I am able to spin them up with Visual Studio 8 (2005) and run them. They do control the device as advertised. However the project this needs to be used by is in C# .Net 2.0 and that is unchangeable.
My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution. My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.
I've used COM objects in C# solutions before so once this is made, I can continue on from there without a problem.
However, I don't know what to do to make the COM object from the 2 .dll files, 1 .exe, 1 .lib file, 1 .xml file, and the 12 .h files. Is there a resource available to tell me what to do to make this happen?
My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution.
That's true, however compiling it as a COM object is "difficult" (by which, I mean that you can't do it) unless it already implements the COM APIs (if it doesn't then you need to implement the COM APIs before you can build it as a COM object).
There are books (for example, Essential COM) which explain how to to create COM objects using C++, but it's non-trivial (for building COM objects there may be better books than Essential COM, and better/easier tools than C++).
I think you and/or your boss have 3 options:
Ask the vendor to give them to you as COM objects
Design a COM API that would wrap the SDK's API. Create a COM project (in the language of your choice) which exports this API. Implement these APIs by invoking the underlying SDK methods. To do this you may need someone who knows C++, or be willing to spend much, much longer than "an hour" on this project.
Forget about using COM; instead, build the SDK as a DLL, and use PInvoke to invoke it from .NET code.
My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.
Based on what you've said I don't know of any way to make that happen.
Tell your boss if it would take him less than an hour to wrap it up, he should certainly do it: it would be a more efficient use of both your time.
I would also suggest ATL (not using attributes), but this is something which can take some time to get right if you're not experienced.
My boss says it should take less than
an hour to "wrap" there SDK up as a
COM object, even for me with no
knowledge of C++ compiling.
That may be true for an experienced C++/COM developer, but not for a beginner. I think your best bet is to use ATL. Take a look at the MSDN tutorial.
And do not use attributes.
This doesn't quite answer your question, but...
One option instead of trying to make a COM object is to use P/Invoke and just call the methods in the DLL.
This thread on the MSDN Forums documents how to make a DLL to call using P/Invoke.
Of course if you need access to a whole class (and make an instance of said object), this isn't going to be helpful.
It's good that the code compiles and runs for you. That said it's totally unfair to assume you can do this in an hour.
Have you checked to see what is actually being built by Visual Studio. There could be a chance that it is already building a COM object.
Investigate how the code is being called. I assume you have a .exe that you can run to test the code. Step through this in the VC++ debugger (it's similar enough to debugging C# code) and try to identify any API calls that match with your docs/expectations. This knowledge will be helpful if you try to go the P/Invoke route.
Something else to consider is SWIG. This is typically used by Python developers to wrap C/C++ code and provides some support for C#.
The managed C++ route is probably more advisable for experienced C++ devs because you need to understand a lot about memory allocation, for all but the simplest code.
I (well, really my lead and I) will first try using p/Invoke (via the DllImport feature of System.Runtime.InteropServices) against the SDK's dll the company provided. I'll let you know how it goes.
I think what you really want/need is C++/CLI, that way you can just build them directly into a managed assembly. The idea is that you write a pretty plain wrapper that looks like kind of a cross between C# and C++ and then it does the rest.