I am trying to use this code in a Unity project, but it seems the implementations of COM Interop in Mono/.NET differs, which causes the code to fail or crash. Running the code in .NET works fine, but running it with Mono 2.0 (outside of Unity) fails in the same way as in Unity, suggesting it is a problem with Mono in general and not Unity.
If I compile and run the code as-is, it fails because the type cast from MMDeviceEnumerator to IIMMDeviceEnumerator fails. When decorating all interfaces with [ComInterop], the cast succeeds, but the call to GetDefaultAudioEndpoint crashes Unity/Mono with an Access Violation.
It is hard to find good documentation of COM Interop on Mono in general - and particularly so regarding such an old version. Is it at all possible to get this running?
Wrap the COM functions in C funtions and call the C functions via P/Invoke instead. This can be done in two steps:
Create a VC++ project that wraps the functions you needed in wasapi. Expose them via a module define file or __declspec(dllexport). Build the code into a dll that exposes the functions you need.
In your Unity3D project, access them via P/Invoke.
Here is an example. In your case, just use the COM code in the C/C++ part to do what you want.
Mono 1.0 and Mono 1.1.xx do not have support for COM.
Stop trying with Mono, Mono is for platform independence and COM Interop is Microsoft only. Use open source SDKs for Video Playing or better invoke apps from command line like vlc to play, encode etc.
Related
I did look at the following question, however, it doesn't resolve my issue.
- Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found"
Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found"
The problem I am facing is that a new DLL created w/ C# has to literally work within a legacy POS system running in Windows XP .NET 4.0 that was originally created with Visual Basic 6.0, which automatically created all of the proper entry-points (such as DLLRegisterServer) within the DLL assembly. However, these ActiveX COM entries, since they are no longer used, are not created with C# in Visual Studio 2012/2013. So, my question is, How can I create a Windows XP .NET 4.0 (VB backward compatible) ActiveX COM DLL with C# in Visual Studio 2012/2013, to replace the original VB DLL ? Can these entries be entered manually (& successfully compiled) in the C# DLL (i.e., using ???.??? STDAPI DllRegisterServer(void) { return true; }) ?
Your terminology is a little confusing: there is no such thing as "Windows XP .NET 4.0", but it sounds like you want to use .NET 4.0 on Windows XP. That would be OK. Note that your POS must be running Windows XP SP3. Note that .NET 4.5 and above are not supported in Windows XP. Your new DLLs must be compiled under .NET 4.0 or earlier. There are special complications if your POS software already uses .NET for anything else. I'll assume here that you are using .NET 4.0 and that the POS doesn't otherwise depend on .NET.
You do need to install on the POS machines an appropriate version of the .NET runtime (the version under which your DLL has been compiled is the best choice). But after that - yes, of course RegAsm will allow you to register a COM DLL (not RegSvr32 however; RegSvr32 doesn't know how to register a .NET DLL). As I mentioned in a my previous comment, the details in the registry will necessarily be different from the details for the VB6 DLL.
The installers for the different supported .NET runtimes are available from Microsoft. There are two options:
The ".NET 4.0 Client Profile installer" is currently available here:
http://www.microsoft.com/en-us/download/details.aspx?id=24872
The "Full .NET installer" is currently available here:
http://www.microsoft.com/en-us/download/details.aspx?id=17718
If you can help it, you want to compile your DLL using the ".NET 4.0 Client Profile" option, which is a subset of the whole runtime with only the most commonly used features. The Client Profile is significantly smaller. You will know immediately if your application is compatible with the Client Profile simply by trying to compile it with that option. If you are using something that is not included in the Client Profile, your DLL will fail to compile. In that case, try first to see if you can accomplish the same functionality without using the non-client-profile feature. If you can't, then use the full runtime.
Now the hard part: you don't specify if your DLL exposes a bunch of custom interfaces, whether it only consumes interfaces declared by the application, or a combination of both. You also don't specify how the POS software knows about your DLL and whether it uses Automation (IDispatch) like VBScript would or "custom" interfaces, and you don't say who declares the interfaces. Setting up the appropriate interfaces in C#/VB.NET can be a tricky problem because VB6 doesn't exactly make it easy to look at the details.
You can pull the most critical information from the existing DLL by registering it and looking at the resulting classes via the "OLE View" tool. The rest of the details will depend on how the main POS application uses your DLL. The full details of what to do can be complex and are well outside of the scope of any one single answer in Stack Overflow.
So basically you are trying to create dotnet based COM component. Set your project property as COM visible and Register your assembly using Regasm
regasm myDotnetCOM.dll
OR
regasm /codebase myDotnetCOM.dll
Now you can use CreateObject for this COM component.
Ahead of Time Compilation or AOT is a feature of the Mono runtime code generator.
mono --aot program.exe
This will generate a file called "program.exe.so"
How can i load this shared object file in php script and access the class objects and methods. ?
Thanks
The native library still needs to be loaded inside an AppDomain (i.e. the Mono VM/runtime) in order to run, it is not a native library as such.
If you must I'd suggest looking at
whether php supports COM interop (I don't use php, but I'd reckon the chance exists). This would be good since you could use that and profit from OO interface exposure
Use Swig which has support for C# some time now
Alternatively, use mkbundle, and/or create a native shared library that embeds a Mono VM. The shared library wrrap around the C# interface using a "C" native API's.
The Phalanger project should be able to do this. You can compile your php code with mono and also integrate with .net from php.
I am developing a managed lib (using Microsoft Web Services) and I am
including it into a c++ project. The project doesn't use /clr option,
so when I include my library's header file VS2005 show me an error
saying I have to use /clr option. Doing this I have a incompatibility
with /EHs command line option (error D8016), but changing from EHs to
no exception handling not solving problem and keep showing me same error .
Any suggestion is welcome.
Thank you in advance.
If you have unmanaged C++ code and want to use managed code, you have a few options:
Change your unmanaged code to C++/CLI, by use of the /clr switch.
Write a C++/CLI wrapper library. It could DLL-export unmanaged functions which you call in your unmanaged code.
Skip the wrapper library and directly DLL-export unmanaged functions via this library.
You can't use a managed lib from an unmanaged c++ application. Since you add the /clr option, your c++ application becomes managed too (just for the record :) )
Here's what might help you: http://msdn.microsoft.com/en-us/library/ffkc918h.aspx - the restrictions of the /clr option.
It is possible to write managed c++ adapter, that will call the C# library, and call this adapter from unmanaged c++ program as you would usually call a normal c++ library. You will compile your adapter library with /clr and your main c++ program without /clr if for whatever reason you want to keep it unmanaged.
You can embed a mono environment and start an AppDomain. mono's runtime API will allow you to instantiate classes and call members on them. It will be clumsy, but is will work
http://www.mono-project.com/Embedding_Mono
Note that Mono is a full .Net 4.0 compliant CLR and it can work with the Microsoft core libraries on Windows.
On windows and Unix it can work with the Mono corlib/class libraries. There are areas not covered in Mono, but they seem to get sparse. You can use the MoMa tool to spot whether your application uses incompatible/incomplete APIs.
Or you can just use the Microsoft .NET framework, assuming you're on windows anyway!
I developed a MATLAB function, and I'm looking for a way to call that function from another C# application and pass some parameters to it and get the results in the C# program.
I heard that I can use Dynamic Data Exchange (DDE) or COM objects, but have can I do it?
There is nice example in the MATLAB Central.
It shows three ways on how to communicate with MATLAB:
COM
MATLAB .NET Bulider
MATLAB compiler
COM (I do not have any experience with it)
Cons: MATLAB is required to be installed on the target computer.
MATLAB .NET builder compiles your MATLAB code to the .NET assembly and you can use it directly.
Pros: MATLAB is not required to be installed on the target computer
Cons: It's expensive
MATLAB compiler compiles your MATLAB code into a C/C++ library or EXE file. You can use it through P/Invoke.
Pros: MATLAB is not required to be installed on the target computer
Cons: It's expensive, a lot of P/Invoke.
There is a third option: delegates. Starting MATLAB -> load .NET assembly -> execute .NET function with delegate handle to a MATLAB function.
There is a great example on this site on setting up everything. You can use MATLAB .NET deployment tool.
You need to
Install MCR (Matlab Compiler Runtime).
Deploy your Matlab function to .NET Assembly using Matlab Deploy
Tool. This will create a .dll file.
Add .dll reference inside your .NET project.
Add reference to MATLAB.NET.
The advantage of this method is that the target machine does not require MATLAB to be installed, but on the downside the execution is quite expensive.
I have a DLL written in C# which is acessed by a native EXE (written in Delphi) via COM. Now I was asked to make it work with Mono (on Windows, not Linux) instead of Microsoft .NET Framework.
Is it possible to be done? If it is, how can I do it?
Possibly, yes.
Mono has had COM-callable wrappers for a while. Check: http://www.mono-project.com/COM_Interop.
Probably the easiest thing to do is to download SharpDevelop and try to compile your existing code for Mono.