I'm working to create a C++/CLI dll from an ATL COM object dll. Is this type of move possible, and what would need to be done to migrate the classes from the ATL com object to the C++/CLI dll wrapper.
Related
Team,
The following code returns empty/null to myobj, in my classic ASP page while trying to invoke a dll component.
Set myobj = Server.CreateObject("MODULENAME.cCLASSNAME")
This is related to a DLL which is placed alongside this asp page under \Bin. The DLL is an Interop COM dll custom developed by a former colleague and currently there's no access to the code.
The DLL components are appearing in the regEdit under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ which makes me assume it is registered. However when I try to re-register using regsvr32, it shows that it was loaded but couldn't find DLLRegisterServer method. I use regAsm to register the component.
Any alternate approach that can be done here? Am I missing something?
If the file name starts with "Interop" or "AxInterop", it is likely a wrapper to a COM DLL, not the DLL it's self. The COM DLL must be registered on the system and then a dotNet application will use/create that wrapper so you can make calls to it.
What you need to do is find the DLL, not the Interop because you are not using dotNet in Classic ASP. Make sure it is registered on that computer (using regsvr32 without error) and then this should work.
Last note/hint, that dll created by ex-coworker was done in C or VB (not dotNet) right? If done in dotNet, it is not COM and you need to research "How to call a managed DLL from unmanaged code".
I know I can register a .NET dll as an assembly and call a function within my sql query. But I'm getting confusing statements as to using a c++ or c++/cli dll for the same purpose.
The link below describes a way to just do that:
http://msdn.microsoft.com/en-us/library/vstudio/hc912f03(v=vs.120).aspx
but then I'm getting the following error message:
CREATE ASSEMBLY for assembly 'libname' failed because assembly 'libname' is malformed or not a pure .NET assembly. Unverifiable PE Header/native stub.
Another document actually states that only pure .NET modules can be used.
http://blogs.msdn.com/b/psssql/archive/2013/02/23/unable-to-register-net-framework-assembly-not-in-the-supported-list.aspx
So I'm wondering what is true and if possible how to use a c++ dll with SQL Server 2012?
I have tried to wrap my c++ dll with a c++/cli wrapper compiled with /clr:safe but to no success.
This article has some workarounds about creating the dll. After creating c++ dll, a C# dll is created to wrap the c++ dll:
https://lennilobel.wordpress.com/2014/01/29/calling-c-from-sql-clr-c-code/
I am a .net developer who has never touched c++. I don't want to either :)
Unfortunately, I have to work with c++ module in .net 4.0 and I am clueless.
Is there a tool that can generate a .net assembly for a given c++ module?
If not, what are my next steps to successfully call these c++ libraries?
There are many ways:
COM Interop
Tlbimp.exe (Type Library Importer)
How to: Generate Primary Interop Assemblies Using Tlbimp.exe
The Type Library Importer converts the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly.
PInvoke/DllImport
Calling Native Functions from Managed Code
The common language runtime provides Platform Invocation Services, or PInvoke, that enables managed code to call C-style functions in native dynamic-linked libraries (DLLs). The same data marshaling is used as for COM interoperability with the runtime and for the "It Just Works," or IJW, mechanism.
C++/CLI
Mixed (Native and Managed) Assemblies
How To: Migrate to /clr
This is more advanced because it will most probably require the C++ module to be updated and re-compiled.
Mixed assemblies are capable of containing both unmanaged machine instructions and MSIL instructions. This allows them to call and be called by .NET components, while retaining compatibility with components that are entirely unmanaged. Using mixed assemblies, developers can author applications using a mixture of managed and unmanaged functionality. This makes mixed assemblies ideal for migrating existing Visual C++ applications to the .NET Platform.
I need to develop some classes that should be callable from VB6 with Managed C++ (C++/CLI).
I've developed first a sample in C# and I can use the assembly through COM without problems
just using the setting "Register for COM interop" and "Make assembly COM visible" (and using the attribute [ClassInterface(ClassInterfaceType.AutoDual)] to make methods available at VB6.
After that I tried to translate the sample to C++/CLI without success. I've created the same class with the [ClassInterface(ClassInterfaceType.AutoDual)] attribute. I've set the "Embedded IDL" setting to specify the output TLB but the TLB is not generated automatically. If I use the tlbexp util over the generated DLL I get a tlb that can be imported at VB6 but when I try to create an instance I get an "ActiveX compoennt can't create object (429)"
What more do I need to do with the project to let it run?
Thanks in advance.
Not much to go on but you never mentioned registering the assembly. The C++ IDE doesn't have the "Register for COM interop" option. From the Visual Studio Command Prompt, run Regasm.exe on the assembly to get it registered. You need the /codebase option if you don't put the assembly in the GAC. And the /tlb option generates the type library, making tlbexp.exe unnecessary.
I have a C++/CLI assembly that wraps a native 32-bit dll.
The assembly is used both from .Net and COM (office).
Now I have a customer that runs 64-bit office.
Is it possible to create a C++/CLI assembly that uses a native 32-bit dll and exports a 64-bit com interface?
No, you can't mix code with different bitness in one process on Windows. You need to force 32-bit code into a separate process or convert that DLL.
The latter can likely be achieved by using COM+ (or DCOM which is mostly the same). This is what we usually do with native C++ code. I'm not sure about how easy it is with C++/CLI assemblies.
In a manner of speaking, yes.
Continue to compile the C++/CLI code as 32-bit so it can use the native library using C++ interop.
Then you will have to configure it to load as an out-of-process COM server when acting as an Office 64 plugin. With native COM code, midl automatically generates the 64-bit proxy. There should be some similar capability to create a proxy when registering .NET classes marked COMVisible.
The 64-bit COM interface will be contained in the auto-generated 64-bit proxy DLL, so this doesn't violate the rule that the bitness of all modules in a process must be the same.