NULLReferenceException

[qur]

Hi All I am calling the function from DLL using InteropServices. But when i called the function that accept the string as parameter NullReference exception is thrown. Actual function signature: int GetName(int pModel, int iVar, char *pszVarname); Function Signature for C#: [DllImport("C:\\MyFunctions.dll")] public static extern int GetName(int nProb, int nIndex, ref string sVarName); Fuction Call: string sVarName; int nErrCode, i; i = 14; sVarName = "x123456"; nErrCode = GetName(nProb,i, ref sVarName); //Getting NullReferenceException Thanks in advance qur

[Heath Stewart]

Don't ref the string. A char* is a string. The signature in C# should be (and loose the path - put the DLL in a directory in your PATH environment variable, or the current application directory):

[DllImport("MyFunctions.dll", CharSet=CharSet.Ansi)]
public static extern int GetName(int nProb, int nIndex, string sVarName);

Also notice the CharSet field in the DllImportAttribute. .NET deals with Unicode strings. If you don't specify a CharSet, CharSet.Ansi is used by default for C# and VB.NET, but it's still a good idea to specify it for readability. Also notice there's no out or ref keyword for the sVarName parameter (which, by the way, can be called anything you want). A String (C# alias string) is already a reference type. Also, if you want your code to be portable, those int parameters and return should actually be IntPtr. An int in C/C++ is a processor-dependent bit width (i.e., 32 bits on a 32-bit CPU, 64 bits on a 64-bit CPU). int in .NET (an Int32, actually) is always 32 bits. When .NET 2.0 is released and if your code runs on a 64-bit platform (and your native DLL is recompiled for a 64-bit platform), your call will fail. Finally, never make P/Invoke'd methods public (unless the class that declares them is private or internal). Native function calls are unmanaged, so the CLR can't determine if someone would exploit your code. Depending on your native implementation, someone could easily perform a buffer overrun using the string variable and the CLR couldn't prevent it because it's unmanaged. P/Invoke'd methods are typically wrapped in a class that encapsulates the functionality that you're trying to use in a native DLL. Many classes throughout the .NET Framework Class Library (FCL) - such as every Control in Windows Forms - does this.

Microsoft MVP, Visual C# My Articles