We Keep Coding

Why does my C# COM visible DLL always return #VALUE! in Excel VBA?

I am writing a C# DLL which must be COM visible as it's main use case will be embedded into Microsoft Excel VBA (I know). Whilst developing I have been using Visual Studio's "Register for COM Interop" checkbox and having the process done for me. This has been working fine on my PC as I am able to get valid outputs in Excel, however now I am trying to register the DLL on client machines (manually) and I seem to be having issues with making valid calls as Excel only returns !VALUE.
This following has been my process:
AssemblyInfo.cs:
[assembly: ComVisible(true)]
Class1.cs:
namespace ManualRegister
{
public class Class1
{
public string test()
{
return "Working!";
}
}
}
Copy ManualRegister.dll into SysWOW64
Register.bat:
cd/
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe ManualRegister.dll /tlb:ManualRegister.tlb /codebase
pause
Adding reference to VBA module.
VBA Code:
Function test()
Dim object As New ManualRegister.Class1
test = object.test()
End Function
VBA error:
Can anyone see what step I'm missing / doing wrong?
(I have also tried specific CPU architecture builds to no avail)

Can't find unmanaged DLL using DLLImport

Above is my folder structure. I have a Cordova app and a Windows Runtime Component - IBscanUltimate. The include folder has the C# code calling into the unmanaged IBscanUltimate.dll. Class1.cs is like this:
using System;
namespace IBscanUltimate
{
public sealed class Class1
{
public static String getSDK()
{
IBscanUltimate.DLL.IBSU_SdkVersion a = new DLL.IBSU_SdkVersion();
IBscanUltimate.DLL._IBSU_GetSDKVersion(ref a);
return "SDKVersion: " + a;
}
}
The IBScanUltimateApi.cs & _IBSU_GetSDKVersion look something like this:
internal partial class DLL
{
[DllImport("IBScanUltimate.DLL")]
private static extern int IBSU_GetSDKVersion(ref IBSU_SdkVersion pVerinfo);
public static int _IBSU_GetSDKVersion(ref IBSU_SdkVersion pVerinfo)
{
int nRc = IBSU_STATUS_OK;
nRc = IBSU_GetSDKVersion(ref pVerinfo);
return nRc;
}
}
I have placed the DLL in many locations to see if it'll get picked up and they all have the above properties. But when I try to run my app, it says unable to locate the IBScanUltimate.DLL
This is how the output is coming:
I am not sure what is it that I am doing wrong and why the DLLImport cannot find my dll. Thank you for your help.
Exact error is:
System.DllNotFoundException: Unable to load DLL 'IBScanUltimate.DLL': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Update #1:
I have come across https://msdn.microsoft.com/en-us/library/windows/desktop/hh447159(v=vs.85).aspx This article is explaining that LoadPackagedLibrary function can be used to load the dll. I am not seeing any example on how to use this in C#.
Update #2:
Specify the search path for DllImport in .NET Mentions that SetDllDirectory or AddDllDirectory can be used. He has a code snippet for SetDllDirectory, but the argument is string[] paths. How would I specify the relative argument?
Update #3:
[DllImport("kernel32.dll", SetLastError = true)]
static extern bool SetDllDirectory(string lpPathName);
public static bool setPath(String path)
{
//Windows.Storage.
//return SetDllDirectory("ms-appx:///");
return SetDllDirectory(path);
}
I tried calling the SetDllDirectory(path) method with various locations that my app should have access to but I am keep getting "false". Few examples that I have tried:
NativeMethods.setPath(Package.Current.InstalledLocation.Path.ToString());
StorageFolder localFolder = Windows.Storage.ApplicationData.Current.LocalFolder;
StorageFolder folder = Windows.Storage.KnownFolders.MusicLibrary;
This is where my app is installed:
C:\Users\AAA\App\hello\platforms\windows\build\windows\Debug\x64\AppX
and I can see that my DLL is there. But still I'm getting the exception that DLL cannot be found. Do I have to put something on the manifest regarding this?
Update #4:
I ran a dumpbin on the DLL and i see the below DLL in the dumpbin:
WINUSB.DLL
mfc90.dll
MSVCR90.dll
KERNEL32.dll
USER32.dll
GDI32.dll
VERSION.dll
MSVCP90.dll
SETUPAPI.dll
I guess I'd like to check on each dll above separately to see if my windows runtime can pick it? One of them could be the culprit that's not being loaded?
Update #5:
Upon seeing the answer from Peter Torr - MSFT, and googling for MFC I came across this article https://msdn.microsoft.com/en-us/library/d06h2x6e.aspx Which states:
The MFC classes and their members cannot be used in applications that execute in the Windows Runtime.
I guess to conclude this wild hunt now. I would close this up that the library I tried to load is dependent on libraries not available for Windows Runtime.
I had this feeling because Windows form application would run but the the code converted to Windows Runtime would give the error that the DLL is not being found. Thanks to Peter for guiding in the right direction.

The DLL you are trying to load was clearly built for desktop apps (it has User, GDI, and MFC imports) and will not work as a UWP binary. I suspect also that the DLL does not have the AppContainer flag set (an option you pass to the linker). You will need to find another way to accomplish what you need (if necessary, please make any feature requests via the Windows Platform UserVoice.

I suspect that it can find your DLL just fine, but it fails to find one or more of its dependencies. Unfortunately, both of these cases result in extremely generic DllNotFoundException that mentions the DLL your try to P/Invoke to.
There is an easy way to figure out what's missing! Windows contains a feature called "loader snaps", which, when enabled, will log all the things that Windows DLL loader does for your process. That means it will also print what DLLs it fails to load. To enable it, run this in admin command prompt:
gflags.exe -i "<executableName>.exe" +sls
Where executable name is just the name of your executable without the folder. To see the output, you will also need to enable either native or mixed mode debugger. You can do that in your project properties debugging tab in Visual Studio.
You can read more about load snaps here:
https://blogs.msdn.microsoft.com/junfeng/2006/11/20/debugging-loadlibrary-failures/

C++ dll within c#

I have C++ DLL as below
#include "stdafx.h"
extern "C" __declspec(dllexport)double Add(double a, double b);
extern double Add(double a, double b)
{
return a + b;
}
n here m trying to link this DLL with my C# app
using System.Text;
using System.Runtime.InteropServices;
namespace test
{
class Program
{
[DllImport("DLL.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern double Add(double a, double b);
static void Main(string[] args)
{
Console.WriteLine(Add(1.0, 3.0)); // error here
Console.ReadLine();
}
}
}
m getting error:
"Unable to load DLL 'DLL.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"
please help me out ...how can i link c++ dll with c# ?

The calling convention determines how function parameters are placed on the stack prior to a function invocation, and how they are removed (caller vs. callee) when the function returns. You can find out much more about this in about a million StackOverflow questions, or goto here and read up a little.
Regarding placement of the DLL within reach of the C# (aka .NET) application you're writing, I'm afraid I cannot comment on that except to say general DLL's must be in your lib-search path (PATH in Windows) the current directory, or the kernel's home directory (generally c:\windows\system32. Do NOT copy files to system32, btw. just setup your application to "run from" the directory where your DLL is residing and you should be fine. There are exceptions to this, and configuration settings that can radically alter this, but were I you i'd stick with simple for now. Complex can always come later.

You will either need to plant the dll in the same location as the C# exe or pack the dll inside the exe. The first option is simple enough. For the second option, check out Embedding DLL's into .exe in in Visual C# 2010

you got this error because DLL.dll wasn't in your Debug/Release Folder,
as far as i know visual studio doesn't know how to copy those files to your output folder manualy.
add the dll file to your C# solution
and then on files properties set build action to content
and set copy to output directory to copy if newer this will automate the copying

Debug com visible dll managed code

I have written a COM visible dll, which will be called from a native Win32 program. For debugging purposes I added a simple WinForms client to the solution containing the dll.
Now when I set a breakpoint in the dll, that breakpoint is hit, but I can't step through the code: the debugger always jumps to the next breakpoint in the dll, or the first line of code in the client after the call to the dll.
How can I get the debugger to step through the dll code?
I thought it might be the "Enable Just My Code" option, but that is not set.
Update
jdv suggested setting "enable unmanaged code debugging" in the project properties, but that didn't have the desired effect.
Thanks, Miel.

Here are the steps I performed and which allowed me to successfully debug a .NET assembly exposed as COM component:
Start by creating a class library containing a class that will be exposed as COM object:
namespace COMTest
{
using System;
using System.Runtime.InteropServices;
public interface IFoo
{
void Bar();
}
[ComVisible(true)]
public class Foo : IFoo
{
public void Bar()
{
Console.WriteLine("Bar");
}
}
}
Sign the assembly with a strong key and register as COM object:
regasm.exe /codebase COMTest.dll
Once the COM object is registered you may create a new console application in a new Visual Studio instance to test the COM object:
class Program
{
static void Main()
{
var type = Type.GetTypeFromProgID("COMTest.Foo");
var instance = Activator.CreateInstance(type);
type.InvokeMember("Bar", BindingFlags.InvokeMethod, null, instance, new object[0]);
}
}
Place a breakpoint on the InvokeMember line and run the application. Once the breakpoint is hit open the Modules Window (Ctrl+D M) and make sure that symbols are loaded for the COM assembly:
Now if if you press F11 you can step into the COM class to debug.
Remark: You can also directly open the .cs file containing the Foo class and directly place a breakpoint there. Once again the important thing is to have the symbols loaded for the assembly or when you place your breakpoint Visual Studio will tell you that this breakpoint won't be hit.

There was a post VS2008 SP1 hotfix released that solves a number of debugging problems. The KB article is here, the hotfix download is here.

crashdump debugging with Visual Studio 2010

I am trying to get crash dump debugging working with 2010, but it keeps failing.
I get this error when I try to start debugging:
"Managed Minidump Debugging: The signature verification for the file 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordbi.dll' failed with the error 0x800700c1.:
I'm using the simplest program I can think of just to get off the ground (below).
Here are the steps I am taking:
Build
Run with a double-click from Windows explorer
right-click on the process in TaskManager, and select "Create Dump File"
kill the process
open the dump file in Visual Studio (File | Open, set filter to crash dumps)
Select "Debug with Mixed"
much loading of symbols (I have MS Symbol server enabled)
Boom (I get an error dialog saying I need to specify my symbol path -- which I believe I have done -- MS symbol server is enabled, and my solution is loaded)
In the output window, I get the following error (note that there are also a bunch of successful symbol loads, including for my exe):
Managed Minidump Debugging: The signature verification for the file 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordbi.dll' failed with the error 0x800700c1.
(All the while, the solution with the code for my exe is loaded in the Visual Studio instance).
Any idea what I am doing wrong? Is this the right procedure for crashdump debugging in VS 2010?
The test dummy program:
class Program
{
public static string AStaticProperty = "Hello World";
static void Main(string[] args)
{
DoLoop(10000);
}
static void DoLoop(int iterations)
{
for (int i = 0; i < iterations; i--)
System.Threading.Thread.Sleep(500);
}
}
Edit
I'm going to vote to close -- I don't know exactly what the deal is, but everything is working now.
Here's what I did:
I started debugging the running process in VS 2010
I used the "save dump file" option off of the debug menu in 2010
I stopped the process and loaded the dump file.
It worked, so I thought "hmm, maybe the problem was with the dump file that I created (had used both adplus and TaskManager).
But no, now those work too. (although they failed very reliably until I did the 3 steps above). Weird, but now I cannot repro, so I'm going to vote to close.

Maybe this question/answers "Symbol issue when debugging C# code" helps you out.

The common tool used to debug dumps is WinDbg which is available in Debugging Tools for Windows. For x64 dumps you need the x64 debugger, while for x86 you need x86 debugger.
Visual Studio is x86 only, so you should not expect it can debug all dumps.

I think that this was an unstable machine/need a reboot issue. I have been unable to repro the problem