We Keep Coding

C++ SDK intergration into C# program

I am have been developing C# applications for a some time now, however recently I have been given a project requiring computer vision. As such my company has opted to purchase a licence for an API/SDK for a particular computer vision package. This API/SDK is however provided in:
C++, ActiveX
and Direct Show based API/SDK for integration.
My question is weather C++ libraries come in the form of .dll files or some other form?
If so what options exist to integrate the c++ API/SDK into a C# WPF program in order easily build an interface and utilise its functions? and would this be considered bad practice to mix different languages?
Would it be easier to simply develop the whole program in c++?

There are two types of libraries in C++: dll and lib.
Dll files are dynamically linked (aka only required during runtime) whereas lib files will be linked to be part of your programm.
The library probably comes as one or multiple dll files with supporting lib files for easier access of the methods (otherwise you would have to manually look for the methods in the library when using c++).
For using them from C# you have two options: building C++/CLI wrapper or import the methods using the DllImport attribute.
The wrapper method can not really be recommended. I would only use it if there is a two way communication going on between c# and c++ (and by two way I mean more than just passing basic parameters to c++ an returning basic values).
The DllImport attribute is probably what you're looking for. Information on that can be found in the MSDN ( https://msdn.microsoft.com/en-us/library/aa984739%28v=vs.71%29.aspx ).
Whether you want to write c++ yourself is up to you. If you want to create a UI and not do too much perfomance critical stuff in your own code I would just stick to C# where you feel at home ;-)

Can a Delphi 4 and/or Delphi 5 executable be integrated into a C# application?

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

Writing COM servers for the windows API in C#, where to begin?

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 .

Interacting with java code from C#

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.

Clarion: Possible to use a C# Assembly?

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)