if this possible to write a com control or activex in C# and use it in MFC ?
Yes. First, you need to create COM object. Below is a very simple example.
[Guid("123565C4-C5FA-4512-A560-1D47F9FDFA20")]
public interface IDoSomething
{
[DispId(1)]
string Name { get; }
[DispId(2)]
int DoSomething();
}
[ComVisible(true)]
[Guid("12AC8095-BD27-4de8-A30B-991940666927")]
[ClassInterface(ClassInterfaceType.None)]
public sealed class DoSomething: IDoSomething
{
public DoSomething()
{
}
public string Name
{
get { return ""; }
}
public int DoSomething()
{
return 4; //random number
}
}
After that you need to regasm your assembly. The regasm tool will add the necessary registry COM entries:
regasm.exe /tlb component.dll
/tlb is necessary to generate the type library to be imported in your MFC application.
Once your assembly is registered, you can call DoSomething in your MFC application like any other COM objects.
Check this link for more information.
This is a bit outside my normal territory, as I don't interact with .NET Interop technology all that much.
It is possible to create what's called a COM Callable Wrapper around your C# control/class to make it accessible to any COM-aware program. I won't duplicate Francis B's answer because it's fairly complete as it stands.
The big question is whether a visual C# control works seamlessly within an MFC window. That's not something I can answer, but my best advice would be to prepare for a bumpy road ahead. Please see http://bytes.com/topic/net/answers/430618-c-control-mfc-window-frame for more detail.
Related
My project requires me to use C# to provide a user interface to C++. One of the C++ function I call does a bunch of work and provides periodic progress updates through another "object." Here's a example of what I mean.
C++
class AppDelegate : public ProgressDelegate
{
void AppDelegate::UpdateStatusText(const char* text)
{
// Go() will end up calling me at some point.
OutputDebugString(text);
}
void AppDelegate::ShowMessage(const char* text)
{
// Go() will end up calling me at some point.
OutputDebugString(text);
}
};
int CppWrapper::Go()
{
return cppInstance->Go()
}
CSharp
void UpdateStatusText(String text)
{
//update UI
}
void ShowMessage(String text)
{
//update UI
}
What I want to do is take updateStatusText and ShowMessage and pass the text over to C# to update my UI. My question is how do I expose the appropriate C# methods so that they can be called by my C++ code? Note that modifying Go is not an option for me.
Maybe this example can help you:
Write a Managed DLL
To create a simple managed DLL that has a public method to add two numbers and return the result, follow these steps:
Start Microsoft Visual Studio .NET or Microsoft Visual Studio 2005.
On the File menu, point to New, and then click Project. The New Project dialog box opens.
Under Project Types, click Visual C# Projects.
Note In Visual Studio 2005, click Visual C# under Project Types.
Under Templates, click Class Library.
In the Name text box, type sManagedDLL, and then click OK.
Open the Class1.cs file in Code view.
To declare a public interface that has a method to add two numbers, add the following code to the Class1.cs file:
// Interface declaration.
public interface ICalculator
{
int Add(int Number1, int Number2);
};
To implement this public interface in a class, add the following code to the Class1.cs file:
// Interface implementation.
public class ManagedClass:ICalculator
{
public int Add(int Number1,int Number2)
{
return Number1+Number2;
}
}
Register the Managed DLL for Use with COM or with Native C++
To use the managed DLL with COM or with native C++, you must register the assembly information of your DLL in the Windows registry. To do this, follow these steps:
Call the Managed DLL from Native C++ Code
// Import the type library.
#import "..\ManagedDLL\bin\Debug\ManagedDLL.tlb" raw_interfaces_only
Change the path of the type library if the path on your computer differs from this path.
To declare the namespace to use, add the following code to the CPPClient.cpp file:
using namespace ManagedDLL;
Complete Code Listing
//Managed DLL
// Class1.cs
// A simple managed DLL that contains a method to add two numbers.
using System;
namespace ManagedDLL
{
// Interface declaration.
public interface ICalculator
{
int Add(int Number1, int Number2);
};
// Interface implementation.
public class ManagedClass:ICalculator
{
public int Add(int Number1,int Number2)
{
return Number1+Number2;
}
}
}
//C++ Client
// CPPClient.cpp: Defines the entry point for the console application.
// C++ client that calls a managed DLL.
#include "stdafx.h"
#include "tchar.h"
// Import the type library.
#import "..\ManagedDLL\bin\Debug\ManagedDLL.tlb" raw_interfaces_only
using namespace ManagedDLL;
int _tmain(int argc, _TCHAR* argv[])
{
// Initialize COM.
HRESULT hr = CoInitialize(NULL);
// Create the interface pointer.
ICalculatorPtr pICalc(__uuidof(ManagedClass));
long lResult = 0;
// Call the Add method.
pICalc->Add(5, 10, &lResult);
wprintf(L"The result is %d\n", lResult);
// Uninitialize COM.
CoUninitialize();
return 0;
}
Reference:
How to call a managed DLL from native Visual C++ code in Visual Studio.NET or in Visual Studio 2005
Alternatively, what I used to do (before I switched to using P/Invoke method to call from C# to C++) was to have 3 projects (as StraightLine has mentioned) but I'd have C#, Managed C++, and Native C++, and have the Managed C++ be my bridge/proxy to talk between the two (Native C++ and C#). It made it more easier to work on my Native C++ side that way. One caution is that some of the STL (mostly containers) are not supported by managed or sometimes, behaviors of std::string (Managed C++ version) would cause exceptions when used in Native C++ std::string, so do pay attention to which STL libraries are Managed C++ supported.
Also, as StraightLine has mentioned, the bridged code (in my case, Manaaged C++) would have to have a wrapper which will marshal from Managed to Native and vice versa (i.e. your "const char*" to System.String, if your char is 8-bits, etc)
You would have to build relevant C# code into an assembly, then reference that assembly inside C++ CLI project. Inside your C++ CLI wrapper, you will make calls to functions exposed through this C# assembly, also you will make calls into native C++ code.
The C++ CLI project can contain native C++ code, just make sure that the CLR switch is not enabled for native files. So, you would have 3 projects -
C# project for GUI which will invoke main. Also references the assembly used to expose C# functions to be called via C++ interop.
C# assembly that exposes certain managed functions (thus callable from C++ CLI)
C++ CLI project which will wrap and also contain native code.
I am working on an extension for a project that will allow hosting the CLR inside the core application. With this I plan to allow this extension to manage managed extensions that it loads/unloads inside itself. That being said, I need to use separate AppDomains to ensure unloading is possible.
Currently, I am able to get the domains setup and get the plugin file loaded but at that point I'm stuck. I'm not sure how to call functions inside the domains loaded assembly at will and so on.
Here is my loading setup so far, minus error checking and such:
ICorRuntimeHost* lpRuntimeHost = NULL;
CorBindToRuntimeEx( L"v4.0.30319", L"wks", 0, CLSID_CorRuntimeHost, IID_PPV_ARGS( &lpRuntimeHost ) );
lpRuntimeHost->Start();
// File data read from disk.
// Dll file just CreateFile/ReadFile and insert into pluginFileData.
CComSafeArray<BYTE> pluginFileData;
IUnknown* lpUnknown = NULL;
lpRuntimeHost->CreateDomain( wstrPlugin.c_str(), NULL, &lpUnknown );
CComPtr<_AppDomain> appDomain = NULL;
lpUnknown->QueryInterface( &appDomain.p );
CComPtr<_Assembly> appAssembly = NULL;
hResult = appDomain->Load_3( pluginFileData, &appAssembly );
I have a class library that all plugins must reference and use in order to be considered a plugin. Which so far is nothing more than a base class to inherit:
namespace FrameworkAPI
{
public class IFrameworkPlugin
{
public override bool Initialize(IntPtr interfaceObj)
{
return false;
}
}
}
And then an extension would reference that class library and use that as its base:
namespace ClassLibrary1
{
public class Main : IFrameworkPlugin
{
public override bool Initialize(IntPtr interfaceObj)
{
// Return true to stay loaded.
return true;
}
}
}
What I am stuck at is how to do a few things:
How can I obtain the main class but as the base to invoke methods in the base that allow the main class to still handle?
How can I ensure that the main class inherits the base so I can ensure its a valid plugin file?
How I can freely invoke methods from the C++ side to fire events in the C# plugin.
For the firing events, the C++ plugin will call more things in the C# plugins once they are loaded, such as rendering events, command handling, etc.
Most of the examples I find online are specific to requiring the entire C# side to be static which I don't want. Also most do not use separate AppDomains and rather all execute in the default. I don't want this since it limits being able to unload a specific plugin.
If any other info is missing and needed feel free to let me know.
I resolved this issue by using a COM exposed interface for the C# side of things.
I have placed the FrameworkAPI inside a separate DLL and exposed it's main interface to COM then reference it in the plugins that will use it.
With it compiled with COM enabled, I can import the .tlb generated file to use the interface in C++ easily.
This is example code in java.
Shared interfaces:
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Compute extends Remote {
public Object executeTask(Task t) throws RemoteException;
}
Task (this will be passed as parameter):
import java.io.Serializable;
public interface Task extends Serializable {
public Object execute();
}
Server:
import java.rmi.Naming;
import java.rmi.RMISecurityManager;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class ComputeEngine extends UnicastRemoteObject implements Compute {
public ComputeEngine() throws RemoteException {
super();
}
public Object executeTask(Task t) {
return t.execute();
}
public static void main(String[] args) {
setRmiCodebase();
System.setSecurityManager(new RMISecurityManager());
try {
Compute engine = new ComputeEngine();
Naming.rebind("//localhost:1099/Compute", engine);
System.out.println("ComputeEngine started.");
} catch (Exception ex) {
ex.printStackTrace();
}
}
private static void setRmiCodebase() {
String codebase = System.getProperty("java.rmi.server.codebase");
if (codebase != null)
return;
// set codebase based on location of this clsas (is it in jar or filesistem?)
}
}
Client:
import java.math.BigDecimal;
/**
* Calculates Pi to arbitrary number of digits:
*/
public class Pi implements Task {
public Pi(int digits) {
this.digits = digits;
}
public Object execute() {
return computePi(digits);
}
public static BigDecimal computePi(int digits) {
// compute Pi
}
}
Client main:
import java.math.BigDecimal;
import java.rmi.Naming;
import java.rmi.RMISecurityManager;
public class ComputePi {
public static void main(String[] args) {
setRmiCodebase();
System.setSecurityManager(new RMISecurityManager());
try {
Compute comp = (Compute)Naming.lookup("//localhost:1099/Compute");
Pi task = new Pi(100);
BigDecimal pi = (BigDecimal)comp.executeTask(task);
System.out.println(pi);
} catch (Exception ex) {
ex.printStackTrace();
}
}
private static void setRmiCodebase() {
String codebase = System.getProperty("java.rmi.server.codebase");
if (codebase != null)
return;
// set codebase based on location of this clsas (is it in jar or filesistem?)
}
}
As you can see, code (not just data) from client is transfered to server and executed there and result of computation is returned. Server does not know that class Pi exists, it only knows about Task interface.
I need something like this to work in .net environment (C# if it is important). WCF would be nice, but I am looking for the most straightforward solution, so WCF is not compulsory. I am not sure even what keyword to use to google documetation or solution for this.
Any help will be appreciated.
Afaik .NET doesn't support this out of the box - you can do remoting but that won't (as is) let you run code from the client on the server. I think you would have to implement something that transfers the dll containing the code you want to execute to the server, and then probably load that dll in a separate AppDomain (because you can't unload dll's unless you load them into a separate AppDomain), and then have a way to specify the class to run.
.NET does not natively support "sending code" to be executed on another computer. Typically the necessary code would be compiled to assemblies and pre-installed on the server before it is called by the client. This is true of both remoting and WCF. You could have a two-way remoting situation where the server calls back to a method on the client via WCF, but I suspect this is not what you want. The only way I'm aware of to really run dynamic code on the server is to generate dynamic code, send it to the server as a string, and then have the server compile it to an in-memory assembly on the fly and then execute it. If you are interested in doing so, take a look at my answer to a similar question:
Autovivified properties?
However, it's not exactly something I would suggest in most cases. I would suggest you rethink your design, first, to see if there is any way to do what you need in a typical ".NET way".
What You want is .NET Remoting.
Here's link to article showing how to migrate from RMI to .NET Remoting.
But according to this MSDN article this is a legacy technology and You should use WCF.
Edit:
You can't "just like that" get .NET Remoting functionality with WCF.
Here you can read discussion about porting from .NET Remoting to WCF.
But if you don't know WCF at all You shoud start here. And You probably won't get your results fast :).
This MSDN page has more or less this exact use case you described. You just need to modify the ServiceContract
http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
You would probably only need to modify this part:
[ServiceContract(Namespace = "http://UE.Samples")]
public interface ICalculator
{
[OperationContract]
double Add(double n1, double n2);
}
// Service class which implements the service contract.
public class CalculatorService : ICalculator
{
public double Add(double n1, double n2)
{
return n1 + n2;
}
Instead of scalar values put your executeTask method with parameter of your own class there.
I don't believe .NET has a built-in solution for transferring executable code from client to server. Assuming the security constraints allow it, you might consider sending interpretable code such as Python or JavaScript which could be executed server-side via IronPython or IronJS respectively. If C# is a requirement (and you still have access to the source code), sending the source and compiling server-side (via Roslyn or the Mono's evaluator).
Title explains. I have native C++ dlls that I'm writing C++/CLI wrappers for, which will in turn will be imported in C# as reference.
The problem is that in C# I don't see the classes I have in wrapper (imported from DLL).
What keywords should I use and HOW to re-declare my native C++ objects to become visible in C#?
Ok, tutorial. You have a C++ class NativeClass that you want to expose to C#.
class NativeClass {
public:
void Method();
};
1) Create a C++/CLI project. Link to your C++ library and headers.
2) Create a wrapper class that exposes the methods you want. Example:
#include "NativeClass.h"
public ref class NativeClassWrapper {
NativeClass* m_nativeClass;
public:
NativeClassWrapper() { m_nativeClass = new NativeClass(); }
~NativeClassWrapper() { this->!NativeClassWrapper(); }
!NativeClassWrapper() { delete m_nativeClass; }
void Method() {
m_nativeClass->Method();
}
};
3) Add a reference to your C++/CLI project in your C# project.
4) Use the wrapper type within a using statement:
using (var nativeObject = new NativeClassWrapper()) {
nativeObject.Method();
}
The using statement ensures Dispose() is called, which immediately runs the destructor and destroys the native object. You will otherwise have memory leaks and probably will die horribly (not you, the program). Note : The Dispose() method is magically created for you.
I have a VB6 project(windows application) and I have to redevelop a module in the existing VB6 project in C#.net.
The module that I develop in C#.net should be a dll and should contain some windows forms. I was able to successfully call a c# console applicaiton dll from my vb6 project but I am facing issues when i try to call a C# class library with winforms from my VB6 project.
This is what I have done for my Proof Of Concept - This is a class file in my C#.net class library project.
namespace TestDll
{
public interface IClass1
{
void DisplayMessage();
}
public class Class1:IClass1
{
void IClass1.DisplayMessage()
{
MessageBox.Show ("Displyaing message");
}
}
}
I have a form in the same nemspace and I plan to instantiate Class1 and use its object on the page_load event of the C# winform.
In my VB6 project I want to display the form I have in my C#.net dll. I am calling it by this code -
Private Declare Sub DislayMessage Lib "TestDll.dll" ()
Private Sub Command1_Click() //On button click event of the VB6 windows form
DislayMessage
End Sub
I get an error - "Can't find a DLL entry point in DisplayMessage in TestDll.dll"
I am not sure how to solve this error. I am even skeptical if this is the way a C#.net dll which contains some winforms should be called from a VB6.0 windows applicaiton.
Should I instantiate Class1 in my VB6 code? How do I resolve this error?
Is my approach correct? Are there better ways to do this?
TIA.
You have to make your class COM-Visible. Here's how I would change your code:
namespace TestDll
{
[Guid("FB8AB9B9-6986-4130-BD74-4439776D1A3D")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
[ComVisible(true)]
public interface IClass1
{
[DispId(50)]
void DisplayMessage();
}
[Guid("74201338-6927-421d-A095-3BE4FD1EF0B4")]
[ClassInterface(ClassInterfaceType.None)]
[ComVisible(true)]
[ProgId("TestDll.Class1")]
public class Class1:IClass1
{
void IClass1.DisplayMessage()
{
MessageBox.Show ("Displyaing message");
}
}
}
Note the [DispId(50)]. You want to specify the dispatch ID for your COM-visible methods, properties, and events. If you don't, the compiler will do it for you and you may end up breaking compatibility every time you compile. The number doesn't matter so much as it doesn't change between compiles.
You might want to check out Building COM Objects in C#. It's a pretty good getting started tutorial.
Some highlights:
Exposing the VC# objects to the COM
world requires the following …
* The class must be public
* Properties, methods, and events must be public.
* Properties and methods must be declared on the class interface.
* Events must be declared in the event interface.
Every Interface needs a GUID property
set before the interface name. To
generate the unique Guid , use the
guidgen.exe utility and select the
Registry Format.
The only way to do it is to expose your C# class as a COM object (also called a CCW - COM Callable Wrapper), and create an instance of that COM object in your VB6 code.
This should help you get started:
http://www.bing.com/search?q=C%23+CCW&go=&form=QBRE&qs=n
There some excellent help on msdn here:
https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/com-interop/