0

I have a Delphi client (exe) and .NET COM dll which I am trying to run without the need for registering the dll. I have followed the steps here and my Delphi client compiles fine. However, I'm not a Delphi expert and I'm unable to figure out how to consume the object in Deplhi. Taking the Skype4COM.dll example linked to, how would I access the dll and it's methods from Delphi 7? Thanks in advance.

Community
  • 1
  • 1
user1365081
  • 1
  • 1
  • 1) if you have a COM .dll, why not just get with the program and run "regsvr32 mydll.dll"? 2) If you actually have a .Net .dll, how do you hope to run it from a Delphi7 Win32 (unmanaged) .exe? – paulsm4 Apr 30 '12 at 05:40
  • Currently we register it programmatically via "regasm mydll.dll" but we are investigating a registration free approach. Why wouldn't I be able to run it from Delphi 7? The MSDN walkthroughs demo how to do it via C++ and VB6. – user1365081 Apr 30 '12 at 05:46
  • Not quite sure what problem you've got. Is it (a) when you register the DLL your client can consume objects OK, and you want to know how to set up the registration-free stuff, or (b) your client is not able to consume the objects at all, even when you register the DLL? – Ciaran Keating Apr 30 '12 at 08:12
  • It's (a). The dll is registered and my client can consume it without any problems. We want to move to side-by-side deployment, therefore we've unregistered it, set-up the manifests detailed and compiled the project. The existing code looks something like this: **ReportFramework := CreateCOMObject(CLASS_ID) as IReportFramework** but I'm assuming I need to replace this as CreateCOMObject looks in the registry (or the GAC) for the dll. – user1365081 Apr 30 '12 at 08:45
  • If you set up the SxS (side-by-side) manifests correctly for Registration-free COM, you don't have to change your code at all. That is the whole point. SxS redirects `CoCreateInstance()` (which `CreateCOMObect()` calls internally) to the manifest instead of the Registry/GAC. Your app's code never knows the difference. So make sure your manifests are correct. – Remy Lebeau Apr 30 '12 at 15:02
  • As Remy says, if you get the manifests right then that's all you need to do. However, getting the manifests right can be tricky. Some things that have tripped me up in the past: the server assemblyIdentity name must be the same in both client and server; that name should not include the .dll extension; the client manifest must include any other assemblies you depend upon, such as mscomctl.ocx etc.; the server manifest must not include UAC directives. Unfortunately I can't help you with the Delphi stuff, particularly how to create and embed the manifest, because I don't use Delphi. – Ciaran Keating Apr 30 '12 at 22:59
  • You'll find /windows/system32/sxstrace.exe to be invaluable. It will tell you where the runtime is looking for assemblies, and what problems it finds. You'll still need to use your own detective skills to make the connection between the error messages and your manifest errors, but at least you'll know where to start. Good luck. And be very patient! – Ciaran Keating Apr 30 '12 at 23:03
  • Thanks for the feedback. That was my hunch but I went off on a tangent. I have managed to get delphi working with a very simple side-by-sie dll but my real world COM has lots of references to other components including crystal reporting and in-house dlls. I'm having trouble embedding the manifest. Thanks again, I'll probably be back quite soon. – user1365081 May 01 '12 at 05:34

1 Answers1

0

This is not an answer, but I want to include a code sample and this is the only way I know how on Stack Overflow.

In case it may help you, here's a sample of how we included a reference to the MS Flex Grid control in one of our VB6 projects that we deployed in SxS. The client is AbbottMST.exe, the COM server is MSTEngine.dll, and this is a cut-down sample from the client manifest file, AbbottMST.exe.manifest.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32" name="AbbottMST" version="4.0.0.7"/>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity type="win32" name="MSTEngine" version="4.0.0.4"/>
        </dependentAssembly>
    </dependency>
    <file name="msflxgrd.ocx">
        <comClass clsid="{6262D3A0-531B-11CF-91F6-C2863C385E30}"
            tlbid="{5E9E78A0-531B-11CF-91F6-C2863C385E30}"
            progid="MSFlexGridLib.MSFlexGrid.1"
            description="Microsoft FlexGrid Control, version 6.0 (SP6)"
        />
    </file>
</assembly>

Note that if you include the manifest then you must deploy it as side-by-side. For this project we needed to have both a normal registered version for Windows 2000, which doesn't support SxS, and a side-by-side version for XP. The version of the EXE with this manifest bound to it will not run in a non-SxS installation. (There might be some magic incantation that we don't know about, but that was our experience.)

Ciaran Keating
  • 2,793
  • 21
  • 19
  • Thanks Ciaran. Just so I'm understanding you, my setup is as follows: My client is Delphi7, let's call it **TestStub.exe**, my COM server is in C#; **ReportFramework.dll**. Now ReportFramework.dll has a bunch of references to Crystal Reporting via the GAC. In the comments above you say that the "client manifest must include any other assemblies you depend upon", so would I need to reference the Crystal dll's in my **TestStub.exe.manifest** (like you've done with msflxgrd.ocx) along with ReportFramework if I wanted to run them side-by-side? – user1365081 May 08 '12 at 23:10
  • No, you don't need to mention the Crystal Reports assemblies in the manifest, because they're .NET references (since you say you reference them via the GAC.) You only need to include COM references in the manifest file. I'm not 100% certain about that, because I haven't tried what you're doing, but I'm fairly confident. All of this conversation about side-by-side has been related to COM, trying to connect your Delphi COM client to your .NET assembly's COM primary interop assembly. – Ciaran Keating May 09 '12 at 03:48