I have a pet project that is an online game, the entire game engine is written in C# and I would like to know if there is anyway I can call the functions of this existing assembly (.dll) from a solution built using Node.JS, Socket.IO, Express etc?
The game engine itself is pretty complete; tested and robust. I am hoping there is some neat way of exposing its functionality without too much overhead.
UPDATE:
To answer my own question a little..
I have ended building my own web socket server (based on the most current web socket protocol document). It is written in C# and compiled using Mono so that it can be hosted on a Linux box running mono and therefore (with a few tweaks) I can use my existing game engine.
UPDATE 2
A project that does exactly what I was originally looking for now exists - http://tjanczuk.github.io/edge/#/
UPDATE 3
Edge.js supporting node's last versions and .net core with a new edge-js package.
Support for Node.Js 6.x, 7.x, 8.x, 9.x, 10.x, 11.x Support for .NET
Core 1.0.1 - 2.x on Windows/Linux/macOS. Support for Mono runtime
4.8.x - 5.x.
Can be installed from https://www.npmjs.com/package/edge-js
Check out the edge.js project I started (http://tjanczuk.github.com/edge). It provides a mechanism for running .NET and node.js code in-process. Edge.js allows you to call .NET code from node.js and node.js code from .NET. It marshals data between .NET and node.js as well as reconciles the threading models between multi-threaded CLR and single threaded V8.
Using edge.js you can access islands of pre-existing .NET code from node.js, which seems to match your scenario.
I've been recently faced with the same challenge (requirement to call C# code from node.js javascript). I had 1000s of lines of complex C# code that I really didn't like to port to javascript.
I solved if as follows.
The relevant C# code is basically 1-2 classes in a DLL assembly
Defined a COM interface which is a subset of the C# class's interface and implemented that interface in the C# class. Thus, the DLL became an in-process COM server.
Implemented a node.js extension DLL that instantiates my C# COM class using standard Win32 COM API and routes method calls from node.js javascript to C# code using the COM interface.
This solves the problem if one only wants to make calls in one direction. I also had the requirement to make calls from C# to javascript. This is a lot harder. One has to:
Implement a COM object in the node.js extension DLL (ATL helps here)
Pass an interface reference of this COM object to C# code (COM Interop)
Route calls via the COM object to V8 objects in node.js
Maybe if I have some extra time, I might make an example project out of this.
If all you want to do is spin up a lightweight HTTP server while still programming with C# and .Net you should give Kayak a chance. It is a lightweight HTTP Server for C# and behaves kind of like node.js in that sense.
kayakhttp
Update:
If you are looking for a lightweight HTTP Server to handle web requests you have a couple alternatives today:
ServiceStack (recommended)
Microsoft WebAPI
NancyFx
To my knowledge all the above work on some version of Mono, so you can still host them across both Windows and Unix based systems.
.Net addons can be written, in short you write a regular native addon and add .Net calls via CLI/C++ calls to .Net dlls.
In practice you usually create a C# dll library which you then call from a CLI/C++ node addon project. There is a bit of delicacies such as making sure that the actual node add on definition file is compiled without CLR support so node can load it correctly.
You can check out: https://github.com/saary/node.net
for an example of how this can be achieved.
The following answer is out of date, but still helpful for understanding of Node.js from first release
Node.js is now also available natively for Windows at nodejs.org. No cygwin requirement or otherwise.
First of all, at the moment there's no native Windows port of Node.js, there's only a cygwin version (but I suspect you already knew that).
There was a node module floating around somewhere at the GitHubs that provided wrappers for calling into native libraries, but iirc, that only worked with .so libs.
Therefore, if you want to use a C# DLL, you will first have to write a native Node.js extension as the interface:
https://www.cloudkick.com/blog/2010/aug/23/writing-nodejs-native-extensions/
From that extension you have to load the DLL and wrap the calls from Node.js to the C# code, that means you have to write some low level C/C++ code and convert C# values to V8 stuff.
I only have experience with C++ and V8, it's a bit hard to get started since the code examples are a bit sparse, also wrapping C++ classes is not that trivial. But I did wrote small JS game engine kind of thing, that uses a C++ OpenGL backend, it's unfinished (and there are hardly any comments) but it might give you some ideas.
Note: There are some projects in the wild that provide somewhat automatic generation of wrappers to V8, but those are C++ only.
So to conclude, I think it will be quite adventurous getting the C# wrappers to work, but it should be possible.
Edge.js supporting node's last versions and .net core with a new edge-js package.
Support for Node.Js 6.x, 7.x, 8.x, 9.x, 10.x, 11.x Support for .NET
Core 1.0.1 - 2.x on Windows/Linux/macOS. Support for Mono runtime
4.8.x - 5.x.
Can be installed (npm i edge-js) from https://www.npmjs.com/package/edge-js
You might have some luck with this project, which is a port of Node.js to .NET. I haven't used it myself, but with a native .NET implementation you theoretically should be able to do what you need to.
You might also want to go the other direction and try to port (aka: recompile unless you're hooked deep into Windows) your C# game engine to Mono and see if you can then build wrappers off of that.
I know it's an old question, but wanted to throw in a current answer. With IIS 7.5 and .Net 4.x Websockets are supported, though use of the SignalR library will likely be the path of least resistance. It's similar to the socket.io library for NodeJS.
As to accessing .Net code via NodeJS, your best options are Edge.js, building a mixed native assembly with C/C++, exposing your .Net code either via a command line application (best to use pipes for input/output) or via a service (TCP or other).
I find Edge.js to be very limited, and not offer much over a piped console interface.. and feel that a service may be best for a more complex interface. At which point you may be best doing the rest of the project in .Net, unless you have an investment in NodeJS that supersedes said difficulties.
Related
I am trying to write some plugins to work with the Terminal Services Session Broker Plugin Interface. I am very fluent in C# but I have not done any C++ since the late 90's. For the plugin I am writing I plan on communicating with a database and I would prefer to use System.Data.SqlClient to talk to it as I know it's ins and outs fairly well. I have the Windows SDK which has provided my with the .idl file for the interface (tssbx.idl). The SDK also provides a C header file (tssbx.h) and a C source file (tssbx_i.c).
I have never written a COM server before, and I have been having a lot of trouble finding resources on learning how to read a IDL file and turn it in to C#. Everything I find says "Use TlbImport" but that requires things like the block library to be in the IDL which tssbx.idl does not (nor its dependents) implement.
What would be my best option:
Find a tool for C# that is the equivalent to MIDL for parsing a .idl file in to a .cs file.
Learn IDL (I have been having trouble finding good guides to learn it) and write the whole thing in C# by hand.
Write a helper dll using the C files provided and have that call in to my C# dll for my .NET parts.
Re-learn C++, use the provided .h and .c files, and use the CLR to make my .NET calls.
Some other option I have not thought of.
The way to do what you're trying to do is to translate the IDL definitions into C# interfaces, then implement those interfaces as C# classes. You apply the appropriate attributes (mostly ComVisible, ClassInterface, and ProgId) to the classes you want to expose to COM, and use the regasm tool to register your assembly as a COM server.
Translating IDL into C# is actually not that complex; for the most part it maps pretty directly from IDL keywords to C# keywords and/or MarshalAs attributes. I have a series of blog posts on how to do COM interop w/out tlbimp, including one on how to read IDL. I don't know of any tools, specifically, that do a good job of this, but if its part of the Windows SDK you should always check pinvoke.net first in case someone else did it for you.
As far as your other options, 3 and 4 both amount to about the same thing. You cannot call managed code directly from unmanaged code unless it's done via COM Interop or a mixed-mode C++ library. In the first case, you'd still have to solve all of the problems of getting your C# assembly registered with COM for your C dll to call, so you may as well skip the middle-man. For the second, you are basically doing manually the same things that the runtime's interop code does for you, and using a language you're less familiar with to boot, which seems like a net loss to me.
Be aware, though, that loading .NET assemblies into an unmanaged context isn't always possible; for example, managed shell extensions are explicitly not support in Windows 2008. I don't know if the TSSBX interface will allow you to load managed assemblies as COM objects or not, so you'll have to be aware of that possibility. If you can't, then none of your options are going to work, and you'll have to avoid using the .NET Framework at all and use some other database access technology and write the entire project in unmanaged C++.
I am posting this as an answer because it is too long for a comment
From what I gather writing such plugins in .NET might raise problems later on - esp. in a scenario where more than one .NET-based plugin has to be loaded and the two (or more) plugins use different .NET versions (such problems has been expressly mentioned in the context of shell extenstions - I am just taking the reasons from that scenario as a basis for my suspicion...).
As to your option IDL itseld can't implement anything - it is an interface description language.
I would suggest using something similar to option #3 with some modification:
Implement the .NET part as a Windows Service and communicate between the C and the .NET via IPC - I would recommend using shared memory which is extremely fast and well supported with .NET4 .
I have a Java API in jar file with some dependencies from other jar files.
Is there any way to call a specific method from this API, like using PInvoke from .NET?
Here you go :) I've used it myself and was very please with the implementation.
IKVM: Using Java API's in .NET Applications
(1) If you just want some libraries
from Java.
(2.1) If you have access to
the code.
(2.2) Last resort,
dynamically load the Java into .Net
(interpreter)
I don't think it will be an easy task to interoperate .net and java. May be you could use sockets, and use them to send messages from one environment to another. It is just an idea, though.
EDIT:
I have found some libs that say they can do this:
http://www.jnbridge.com/
http://www.codeproject.com/KB/dotnet/Espresso.aspx
You can use CORBA to "call" java methods from .NET.
For .NET here you can find some CORBA libraries.
Java SDK includes CORBA capabilities so you don't have to download 3rd party libraries.
We've written a Java program which we are looking to use and interact with from C#. What are our options? Optimally it would be possible to compile the Java application as a library (.DLL) that we could reference from C# perhaps using P/Invoke. This, however, doesn't appear to be an option according to the first few searches online.
We opt to be able to use ASP.NET to built a search engine powered by the Java code, so if this opens up for any other options please let us know.
Sorry, you cannot call java code / classes Directly from C# code.
One way of doing this is to wrap up your java classes in a java Web Service and call classes indirectly through that web service interface in your C# code.
Another way is using
javareg.exe which exposes java classes as COM. You can find it at following location:
C:\Program Files\Microsoft VisualStudio\VIntDev98\bin\javareg.exe
Following posts might help as well
Calling Java Classes Directly from
.NET (uses runtime bridge)
Calling Java from Microsoft.NET
The simplest approach would probably be to publish the functionality of your java library as web services and add a web-reference from your asp.net application.
Java isn't meant to be embedded in another program, so you need a bridge. The most simple solution is to use a socket: Create a Java process which listens for commands on a socket. In the C#, send the commands to the socket and read the answers.
The main problem here is serialization but if you use XML, it's not such a big pain anymore. Try the built-in XML serialization (see this article) or custom frameworks like XStream or Simple.
It is certainly possible to wrap Java in a .dll, and has been a part of the core Java platform for over 10 years. JNI (Java Native Interface) has an interface for embedding a JVM in your code, meaning you can run Java classes using C-style linking. Note that this will require that you write a simple C wrapper, there are samples within:
http://java.sun.com/docs/books/jni/html/invoke.html#11202
As some of these other posts suggest, sometimes it's desirable to be less tightly coupled, so you may want to consider using another design. One option would be a simple database, where the Java application regularly polls for requests from the C# code. If you want tighter coupling, for things like call-backs, you can look at distributed interfaces.
I am planning to use Drizzle in my next C# Mono app. Since there is no C# client available for Drizzle, I thought I would have a stab at writing my own by converting the Java client, and then making it work with DBLinq.
Having seen the Java client, I realise that it's a longer job that I had anticipated, and I don't have the time. Besides the Java client is not all that mature yet.
Since there is an official Drizzle C client library (libdrizzle), writing a C# wrapper might be the best solution. Are there any tools available that can assist in generating the code for this?
You should also have a look at the drizzle-interface project on Launchpad.
Within that project, SWIG is used to generate wrappers for various languages such as Python and Ruby. All the SWIG related files are part of that project so it might be worth having a look there. Might make what you are trying to achieve a lot easier.
Additionally, Drizzle speaks the MySQL protocol, so most MySQL clients should work just fine.
SWIG is very helpful when it comes to automatically generating .Net wrappers for C libraries, you should definitely try it first.
I have a C++ Windows application that can be extended by writing C++ plugins, using an API that is exposed by the application. There is also one plugin that translates the C++ API to Python (e.g. plugins can be written in Python).
I want to allow users to write plugins in C# in addition to C++ and Python. Since I'm not very familiar with the .NET world, I'm not sure how to implement the C# plugin system.
What would you recommend to use for this kind of plugin system (host is C++, plugins in C#)? What do I need to learn in order to achieve this?
There are a couple of prior posts that may help you out:
Interfacing using a simple API
Communicating between C++ and C# via DLL interface
Expose your API using COM objects and interfaces and you'll open up your application to many development environments, including C#.
Actually as well as the COM suggestions. If you really want to add 1st class .NET plugin support, its possible to host your own CLR process. There is a very interesting article here about it.
http://msdn.microsoft.com/en-us/magazine/cc163567.aspx
I've done this in various ways in the past. I found that C++/CLI was the best option for building a bridge between .Net and unmanaged C++ (though, as noted by other posters, COM in another option).
The ways I've done this in the past include:
Generating C++/CLI API wrapper code from my C++ API using reflection. Of course, native C++ has no reflection system, so we rolled our own. The generated C++/CLI code was then compiled into an assembly that the C# plugin would reference.
Generating a Dynamic Assembly from my C++ API using reflection (ie, using the Reflection.Emit stuff). The resulting assembly could be used in-process for scripting languages or you could even compile C# code against it at runtime. The assembly could even be written to disk to be used statically. The downside here is that you probably can't emit better IL than a compiler, so unless you need the dynamic generation, don't go down this path.
Hand written C++/CLI API wrappers. If the API is not very large, writing a wrapper by hand is easy enough.
In the end you will have an assembly for C# plugins to compile against. Now you need to load the plugin assemblies at runtime. To do this you must host the CLR.
Hosting the CLR is not difficult, though I've only done it once and that was a number of years ago - perhaps times have changed. If you are not comfortable with hosting the CLR, then push as muc hof your app code as possible into DLLs and then write a small C++/CLI app that brings up your unmanaged UI. Now the CLR is hosted by the small C++/CLI app.