com-interop

Expose dll for COM Interop

↘锁芯ラ 提交于 2019-12-03 07:05:12
I thought I knew how to do this, but obviously not so I'd appreciate some help! I can't get my dll to register so I can instantiate it in a VBS, or elsewhere. I wrote the following sample class, checked "Make assembly COM Visible", checked "Register for COM Interop", then built it. When I try to instantiate it from VBS I get the "Activex component can't create object" error. This is the class code: using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Smurf { public class Pants { public string Explode(bool Loud) { string result; if (Loud) result =

Does COM interop respect .NET AppDomain boundaries for assembly loading?

拈花ヽ惹草 提交于 2019-12-03 07:03:11
Here's the core problem: I have a .NET application that is using COM interop in a separate AppDomain. The COM stuff seems to be loading assemblies back into the default domain, rather than the AppDomain from which the COM stuff is being called. What I want to know is: is this expected behaviour, or am I doing something wrong to cause these COM related assemblies to be loaded in the wrong AppDomain? Please see a more detailed description of the situation below... The application consists of 3 assemblies: - the main EXE, the entry point of the application. - common.dll, containing just an

How to expose nullable types via COM

假如想象 提交于 2019-12-03 06:41:35
I have been struggling with this problem for a day and a half, hopefully someone can help me. Let's say I have structures like this in C#: public struct Part { public double? x; // or System.Nullable<double> x, doesn't really matter } (these structures represent database tables, converted from Linq to SQL code created by SQLMetal) I need to be able to expose these structures, containing nullable types, to COM so that they can be used in another application (C++). But I cannot figure out, for the life of me, how to do this. I thought I could create classes to encapsulate the nullable types:

How does Visual Studio's debugger/interactive window dump the properties of COM Objects in .NET?

不羁岁月 提交于 2019-12-03 06:39:30
In this related question , I noted that Visual Studio's debugger is able to enumerate the properties of System.__ComObject references, which is "a hidden type used when the wrapper type is ambiguous" -- e.g., the type of object you get when you obtain it from another COM object and don't instantiate it yourself: Additionally, if you simply write a COM object's identifier into the Immediate Window, its properties and values are similarly dumped: Note that this is separate from VS2010's " Dynamic View ", which I believe uses IDispatch and COM reflection to enumerate the properties of COM objects

How can I wrap a COM object in a native .NET class?

醉酒当歌 提交于 2019-12-03 01:54:06
I'm using an extensive existing COM API (could be Outlook, but it's not) in .NET (C#). I've done this by adding a "COM Reference" in Visual Studio so all the "magic" is done behind the scenes (i.e., I don't have to manually run tlbimp ). While the COM API can now be "easily" used from .NET, it is not very .NET friendly. For example, there are no generics, events are strange, oddities like IPicture , etc. So, I'd like to create a native .NET API that is implemented using the existing COM API. A simple first pass might be namespace Company.Product { class ComObject { public readonly global:

Registration-free Interop between a 64-bit COM dll and a C#/.Net application

我们两清 提交于 2019-12-02 12:36:25
问题 I am trying to get registration-free COM interop between a 64-bit COM dll and a C# app to work. In the answers to a previous question of mine, I got help that allowed me to successfully call a HelloWorld method on the 64-bit COM dll for C#. However, this was only possible by registering the COM dll globally using regsrv32.exe. Based on this answer to a related question, I think that I need to set the Isolated flag on the reference of the COM dll to true. However, this leads to the following

Registration-Free COM Interop: Deactivating activation context in finalizer throws SEHException

余生颓废 提交于 2019-12-02 07:21:04
I am currently working on a mixed managed / native work chain and need to create an activation context for registration-free COM support (see Embed a Registration-Free COM manifest into a C# dll with native/managed environment ). The following snippet is part of a larger class inside a C# DLL, which holds a reference to a COM Wrapper and establishes the required activation context: using System; using System.Runtime.InteropServices; using System.Diagnostics; namespace FirstClient { public class FirstClientDLL : IDisposable { ~FirstClientDLL() { Dispose(false); } void IDisposable.Dispose() {

COM->.NET - can't access overloaded method

情到浓时终转凉″ 提交于 2019-12-02 06:57:02
I'm trying to access a .Net library (The Image Resizer) from COM (jscript). I've tried both IDispatch and class interface generation, as well as [ClassInterface( ClassInterfaceType.AutoDual)] on the class in question. There is a method with 3 overloads: Bitmap Build(object, ResizeSettings settings) void Build(object source, object dest, string settings) void Build(object source, object dest, ResizeSettings settings) Calling Build("file",s); //works The following both generate "Wrong number of arguments or invalid property assignment" (JScript runtime error) Build("file","file", s) Build("file"

Does .NET define common HRESULT values? [duplicate]

匆匆过客 提交于 2019-12-02 04:32:19
This question already has an answer here: HRESULT Enumeration C# 4 answers I'm creating a COM class in C#, which will be called from unmanaged C++. I want to use ThrowExceptionForHR but I'd rather not have to hard-code HRESULT numeric values. I was expecting there would be some enum of common HRESULT values in .Net somewhere? Put another way, where can I find named symbols which map to HRESULT values to pass into ThrowExceptionForHR ? Update: MS talk about it in this page: HRESULT Information in Managed Code . They reference VSConstants class Microsoft.VisualStudio.VSConstants but when I try

Registration-free Interop between a 64-bit COM dll and a C#/.Net application

痞子三分冷 提交于 2019-12-02 04:31:18
I am trying to get registration-free COM interop between a 64-bit COM dll and a C# app to work. In the answers to a previous question of mine , I got help that allowed me to successfully call a HelloWorld method on the 64-bit COM dll for C#. However, this was only possible by registering the COM dll globally using regsrv32.exe. Based on this answer to a related question, I think that I need to set the Isolated flag on the reference of the COM dll to true. However, this leads to the following build error: Problem isolating COM reference 'ComLibInteropLib': No registered classes were detected