Asked  5 Months ago    Answers:  5   Viewed   436 times

I composed .Net 3.5 dll with single method, which is to be called by Delphi .exe. Unfortunately it does not work.

The steps: 1. Create C# 3.5 dll with the code:

public class MyDllClass
    public static int MyDllMethod(int i)
        MessageBox.Show("The number is " + i.ToString());
  1. Go to Assembly Properties --> Assembly Information and checked the "Make Assembly COM-Visible"
  2. Used RegAsm.exe to register my dll

This throws Delphi exception which indicates it cannot connect the dll. What are the steps required to enabled usage of C# managed dll from unmanaged code.

Does any one familiar with good example about the subject?

Thank you



After massive investigation I found the solution: it's all about registration parameters. The flag /codebase must be added to the regasm command.

Many posts out there suggest to use Guid and other COM attributes on the C# Com exposed object, I managed to deliver COM functionality using the ComVisible(true) attribute and regasm /tlb /codebse command.

The code:

public class ServicesTester
    public ServicesTester()

    public void TestMethod()
        MessageBox.Show("You are in TestMEthod Function");

and as I mentioned I used regasm.exe /tlb /codebase to register it

Monday, July 12, 2021
answered 5 Months ago

I found the reason for my failed attempts by utilising a tool called; Microsoft(R) P/Invoke Interop Assistant as suggested by an answer on this thread.

I utilised this tool to input some of the C function prototypes and get it to generate the required C# prototype on my behalf. The C prototype looked like the following;

long __stdcall TransProjPt(LPSTR psGridFile, long lDirection, double dEasting, double
dNorthing, long lZone, double* pdEastNew, double* pdNorthNew, double* pdEastAcc,
double* pdNorthAcc) 

When entering this into the Interop assistant tool, it showed that rather than using longs (as I had done in my original question), these should be declared as an int. It produced the following output that meant my code above now worked as I'd hoped. Yay.

    /// Return Type: int
    ///psGridFile: LPSTR->CHAR*
    ///lDirection: int
    ///dEasting: double
    ///dNorthing: double
    ///lZone: int
    ///pdEastNew: double*
    ///pdNorthNew: double*
    ///pdEastAcc: double*
    ///pdNorthAcc: double*
    [System.Runtime.InteropServices.DllImportAttribute("<Unknown>", EntryPoint="TransProjPt", CallingConvention=System.Runtime.InteropServices.CallingConvention.StdCall)]
public static extern  int TransProjPt([System.Runtime.InteropServices.MarshalAsAttribute(System.Runtime.InteropServices.UnmanagedType.LPStr)] System.Text.StringBuilder psGridFile, int lDirection, double dEasting, double dNorthing, int lZone, ref double pdEastNew, ref double pdNorthNew, ref double pdEastAcc, ref double pdNorthAcc) ;

Thanks for everyones help with this.

Thursday, July 29, 2021
answered 4 Months ago

The best way in my opinion is to crate a C++/CLI lib that you can use to communicate between the layers.

This 3rd party library will be compiled with /clr enabled.

Then you can use the header definitions to the proper c++ function wrappers to call the C# functions.

C++/CLI can help you manage the call just the way you want it, and let you design the type casts the way you want them.

Sunday, August 29, 2021
answered 3 Months ago

As of November 2015: In Visual Studio 2015 it is now supported, just do what you like.

Sample Code:

With frmMain
#region "A sample region in odd place"
  .text = "Sample"
#end region
End With

Note: In earlier versions of Visual Studio it seems that it is not working in VB.NET, but in C# it is working.

Wednesday, October 6, 2021
1.21 gigawatts
answered 2 Months ago

Re the first point: have you tried the (free) VIsual Studio Express Edition? For a lot of things, this is perfectly capable. You just don't get as many helpers / designers, and no plug-in support (for IDE extensions).

Re the second: excluding some nasty tricks, you can't create a pure native executable from .NET; it relies heavily on the framework being available on the local machine. An assembly is just a package of IL, and can be contained (typically) in either a dll, or bootstrapped into an exe that loads the assemblies entry-point; but in this scenario the exe is just a simple loader plus a regular assembly.

Actually, the CLR is more like the JVM; the "framework" is really just the equiavalent of a BCL. The main MS framework+CLR certainly has some Windows specific optimizations, but other runtimes/frameworks (compact, micro, Silverlight, Mono) will have different optimizations.

Re multi-core - you have full threading support (for doing it yourself) - but the main automated multi-core support will (hopefully) be in .NET 4.0 with the "parallel extensions" work.

Re the last point: should be very familiar indeed. Actually, if you want to do some comparisons, "reflector" (free) can take a compiled assembly and show you the code in either C# or delphi (or a few others).

[update re questions]

IL = Intermediate Language; .NET doesn't compile to native CPU instructions, but to something in-between that becomes CPU instruction at runtime (compiled "Just In Time" (JIT) on a method-by-method basis). This means that the JIT compiler can optimize the same IL for the local machine. You can do this in advance using NGen.

CLR = Common Language Runtime; essentially the VM

BCL = Base Class Library; the set of classes shared my many apps

Re deployment: first, install the .NET framework on the client ;-p

After that - various options. At the simplest level, you can just copy the exe/etc onto the local machine and run. For example, I use "robocopy" to push code to web-servers.

For full local installs of a complex client app, msi is an option (and the full VS IDE will help you with this).

For simple clients, you can use ClickOnce - which packages the app into a signed bundle that provides self-updating etc capabilities and allows you to make statements about what security you need (full trust, etc). Express Edition allows you to author ClickOnce packages. ClickOnce can even be used on locked down clients where the user can't install apps, since the app is isolated and sand-boxed.

Finally, you can run a .NET app off a network share, but there are some security implications: the "Code Access Security" layer won't give a network share "full trust" (although there were some recent changes to this so that mapped (F: etc) shares are trusted). So you'd need to use CASPOL at each client to trust the code. ClickOnce would be easier ;-p

Tuesday, November 16, 2021
answered 2 Weeks ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :