I have to admit the last time I programmed in Java was a data structures class in high school. So please be kind to this Java noob.
I have spent a good deal of time putting together a C# COM library at work. This library relies heavily on some new .Net technologies (WPF being the big one) so translating it into another language is not really an option. I have tested consuming this library from C++ through the COM interface and that was simple enough. I wanted to also prove that this same library could be used from a Java program.
So the problem that I have run into is that I can not find a free or even inexpensive way to use COM objects from Java. I guess the other solution would be to find a way to directly integrate the library. Does anyone have any input on what might be the best way to accomplish this? I am using Eclipse for my java environment. Below is an example of what my C# codes exposure looks like. Thanks for any direction you can provide.
//Example C# Object Code
[Serializable,
ComVisibleAttribute(true),
Guid("Long Guid String"),
ClassInterface(ClassInterfaceType.None),
ComSourceInterfaces(typeof(IFooBarStructure)),
ProgID("My Application")]
public class MyFooBarObject
{
public MyFooBarObject(){}
public string DotNetMethod(){ return String.Empty; }
}
You can use JACOB
From the site:
JACOB is a JAVA-COM Bridge that allows you to call COM Automation components from Java. It uses JNI to make native calls into the COM and Win32 libraries.
Sound like the kind of thing you're looking for.
If you have a little bit of money to spend on a commercial product, I recommend that you take a look at Intrinsyc's J-Integra for COM or J-Integra for .NET products. I used their COM product to access a 3rd party ActiveX control (the Bloomberg data access library) from Java code for a project I worked on a few years ago, and it worked very well. They have a reasonable trial / demo policy, and they are quite responsive to support requests.
If you can access your library through C++, you can access it through JNI. JNI is pretty easy to do, just read the guide carefully especially section 8.6 where it talks about the differences between C and C++
The direct Java/.NET integration can be done with OOJNI. Google "Object-Oriented JNI for .NET".
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
Related
I want to start making VSTi's, more specifically, midi ones - those who don't produce any sounds but just output midi data to other vst plugs (arpeggiators, chord tools, etc).
Now I've just bought books for C# thinking it would be a nice language to begin with (not just for vst programming), but everyone keeps saying C++ is the way to go, and VST.NET seems to be for C++....just seems everything is going against me on my C# road?
I have the "programming thinking" in my head but it was years ago since I programmed, Visual Basic, Turbo Pascal, and such. So I'm at a pretty clean start.
What's your advice here, sell my new C# books (or hide them in the bookshelves) and aim for C++, or is C# still ok? I've always thought C++ is alot more complicated than C#, to learn.
By the way, say the VST.NET SDK for C++, can it be used for C# in some way?
VST.NET is not for C++. Where did you get that idea? Go to the code of VST.NET and check out the samples. That will make things clearer - I hope.
Hope it helps.
Marc
Author of VST.NET and MIDI.NET
Steinberg's VST plug-in architecture has been around a long time, first released in 1996. .NET of course would take another 6 years so of course a lot of sample code is in C++. VST v3 uses COM to make it easier to develop plug-ins in languages other than C++.
There are two kinds of COM, the "pure" kind that's based on the IUnknown interface. And the "practical" kind that's based on IDispatch, otherwise known as OLE Automation or ActiveX, these days just called Automation since the name recognition for "ActiveX" no longer instills confidence :)
The C# language works very well with the "practical" kind. Which supports type libraries, a file format that describes the types implemented by a COM server. Very easy to use in a C# program, you simply add a reference to the type library and it acts like just a normal .NET assembly. VSTs however use the pure kind, you don't have the handy type library available to import the interface declarations.
Writing plug-ins in C# is still possible, you have to re-declare the VST interface types in the C# language or use a C++/CLI wrapper to bridge the gap. Pretty painful to get this right, but it has been done before. Like in this open source project. Or this one. No idea how good they are btw, not an endorsement. The first link is for VST.NET. It is a managed wrapper, not for C++. After it is compiled anyway, it uses C++/CLI to take care of the native interop. The second wrapper isn't exactly usable anymore since it requires the Steinberg SDK. Which was discontinued just recently. Ominous sign of course.
I'd like to second Obiwanjacobi. I've been using VST.Net for several months, and it is excellent.
There's certainly an argument for using C++ because it does allow finer grained control of CPU optimization. But, it's a myth to say that C++ code is necessarily faster than C# code. C# does a lot of the hard work for you like memory management and so on. Basically, when someone says C++ is faster than C# they are not really comparing apples with apples. But, nonetheless, language is a personal choice.
I thought I'd add this link because if you are going to create VSTs, you will need controls. Here is a set of controls in the beta phase. They are designed for VSTs. They are skinnable and light weight.
https://bitbucket.org/MelbourneDeveloper/vst-controls-.net
If working with one specific dll, use p/invoke to create a wrapper, implementing functions as detailed in the VST SDK.
If using a generic method for a set of VSTs, create a mixed mode ref class wrapper, passing the filename as an argument - you need to do this in C++. This class marshals data between managed and unmanaged memory.
Since VST3 is the latest VST standard, and is COM compatible, instantiate using COM. For some ideas, see How do I go about instantiating a COM Object in C# by CLSID?
The reason is simple. C++ is one of the lowest level high level languages. C# and Java are often the best tools for a web app or a business app. Never for a multimedia app where the size of the footprint is exponentially and inversely proportional to its performance. ;)
I want to create a deskband COM object for my pet project. I don't have any experience with COM and a quick search revealed that ATL will simplify things. I was wondering if there are any better ways to create a COM component today. Better in the sense less boiler plate, use of C# instead of C++ and any other things you may think of.
If deploying or relying on a .NET framework installation on the client machine is not an issue for you, than C# is much easier than C++ (although you will probably have to redeclare interfaces, IID, etc... in C#, using P/Invoke). If reducing dependencies is an issue, than C++ with ATL is better.
Just create it in C# and expose as a COM component, see this guide:
http://msdn.microsoft.com/en-us/library/zsfww439.aspx
The only reason I would consider C++/ATL is if I were connecting to any C/C++ libraries. Other than than I can't think of a strong reason to use C++ over C# (assuming your skill level is equivalent in both).
I can only recommend C++ in conjunction with Microsoft's ATL library.
I used some code generation tool written in C++ that helped me to get rid of quite a lot of boilerplate code. This tool generated code that produced more C++ friendly interfaces (like the code that gets generated in the tlh/tli files when you #import a type library in Visual Studio. My code generator produces similar code, only for COM servers.
If you are interested, send a mail to DerTopper at web dot de. Put something like "COM code generator" in the subject line, so that you won't fall through my spam filter.
Regards,
Stuart
Currently we have couple projects that are written in Delphi 6. Because of specific components that use in these projects (components also written in Delphi 6) it is not easy to convert it in newer version.
As I prefer .NET development and our new products are developed in .NET, I would like to develop new functionalities using these technologies. C# will be programming language.
My question is: How to integrate new functionalities developed in C# with current code in Delphi? Is this good idea at all and what can be possible issues? If someone have similar experience it would be to hear advantages and disadvantages.
I heard for integration in way to develop .dll with C# and use it from Delphi code.
TnX in advance!
Nemanja
You can use COM (ActiveX) both ways.
So Yes, you can make a DLL in C# and mark it as COM-visible and import it into Delphi.
But you cannot use simple (not COM) DLLs this way.
My first port of call would probably be looking into WCF (written in C#) and have Delphi talk to it.
The dll is not a bad idea, but I just think putting it in WCF is more scalable + portable.
COM would probably be my choice. However, if for some reason you wanted to avoid COM you could take a look at the very nifty Unmanaged Exports by Robert Giesecke.
Unmanaged Exports is an MSBuild task that essentially allows you to export static functions from your .Net assemblies to be consumed as ordinary native DLL exports.
You may want to check out Hydra from RemObjects. It permits native and managed code to be used in the same application.
http://www.remobjects.com/hydra/default.aspx
I have an application in C# that currently authenticates to LDAP. We want to extend functionality to support IBM's Tivoli Access Manager, which is comprised of a Policy Server, and an LDAP server (and other modules as well). Unfortunately authenticating with the LDAP server for our customer is not acceptable, thus we must bind with the policy server instead.
The TAM's Policy Server has 2 APIs for authentication, one in Java, and one in C
My question: What is the better language for C# to interop, C or Java?
Keeping in mind: maintainability, and cost of development.
Thanks everyone in Advance.
Seems to me that C is the easier language for C# to inter-operate with, as there's a native interface in .NET to allow "unsafe" access. To communicate with Java, you have to go though JNI to get into Java, or use J#, or otherwise jump through hoops to communicate from C# to Java and back again.
I've not done any C# to Java communication (except across a socket or across Web Services), but I was on a team that used JNI to communicate from Java to COM via C++ code. We ended up having to throw away the JNI solution as too unwieldy. We rewrote the C++ component in C# and used a nailed-up socket for communication between the two components. This worked fabulously.
From this experience, if you are already using C#, then I would use the C API from C#. This is easy to do.
I've had good success with Managed C++/CLI for interfacing with C/C++ in the past, can't speak much on interfacing with java.
Also if you are going for straight C you can export the function calls directly to C#.
I would think that the API you are interfacing is nothing but an API. One front-end is Java, and the other is C, but you probably aren't interacting with Java code, probably just C.
That said, I suppose it would be whichever interface seems simpler. I'm guessing that C is, but if there is some great Java binding software that lets C# access Java libraries easily, it might be better.
Chances are they both link to C code right beneath the API.
I like Eddie's answer, but I would temper it with this observation - it depends on the skill set you ave in house. If you;'ve got a bunch of Java pros, then it makes sense to use Java. If you have a bunch of C-programmers, then the chouice is obvious.
One other comment though : are you sure TAM doesn't do .NET?
You shouldn't need to do any bridge between C# and C or Java. As Cheeso referenced, TAM has had a supported .NET API for a while now -- see here for information.
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke.
Does anyone have a good solution for integrating some C# code into a java application?
The code is small, so I could re-write in java, but I would rather reuse the code if possible. Don't repeat yourself, etc.
Also, I know I can expose the C# as a web service or whatever, but it has some security/encryption stuff in there, so I would rather keep it tightly integrated if possible.
Edit: It's going to be on a server-based app, so "downloading" another runtime is irrelevant.
You would use the Java Native Interface to call your C# code compiled into a DLL.
If its a small amount of C#, it would be much easier to port it to Java. If its a lot, this might be a good way to do it.
Here is a highlevel overview of it:
http://en.wikipedia.org/wiki/Java_Native_Interface
Your other option would be to create a COM assembly from the C# code and use J-Interop to invoke it.
http://sourceforge.net/projects/j-interop/
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
If it's short, I think you're better off re-writing the code in java. Downloading one 50Mb runtime is bad enough.
There is an IL to Java Bytecode compiler GrassHopper which may be of use to you. I've never tried it though.
I'd look at rewriting your code in Java though
EDIT: Note that Grasshopper seems to be no longer available.
We used JNBridge for this, and it worked great. It handles Java->.NET and vice versa, all in-proc.
If you do not want to rewrite hadle it as an Inter-process communication and choose one of following:
Named pipes
Sockets
SOAP
I would rewrite it if it's not too much trouble.
The web service would work, but it seems like that would be a lot of overhead just to reuse a little code.
http://www.infoq.com/articles/in-process-java-net-integration suggests running CLR and JVM in the same process space and passing calls back and forth. It sounds very efficient. I'm going to give it a try and integrate it into Jace if it works well.
If it is a piece of code that is exposable as a command line utility, I just make the other host language use a system call to execute the utility.
If your C# app needs to call Java, compile a special Java main that takes appropriate command line args and returns text output.
It the oldest, simplest method.
You can call your c# classes (compiled in a dll) via a bridging library, various libraries are available, every one with his characteristics. JNBridge generate proxy classes that you can call to manage the code in java classes. JCOBridge let you load your c# classes and use it from java using the invoke mechanism, also javonet let you import java classes and call java code using the invoke mechanism. All the explored solutions are commercial solutions that let you call java code from .NET and vice-versa with graphical user interface integration and other amenities.
Links:
jnbridge java-.NET bridge Developer and Deployment license schema with 30 day free trial
jcobridge java-.NET bridge Developer and Deployment license schema with unlimited Trial
javonet java-.NET bridge Research and Professional license schema with 30-day unlimited Trial after sign-up