We are having difficulty using native DLLs with VS2005 in C# on a PocketPC 2003 device, or the emulator. I would be extremely pleased to hear any suggestions on this matter.
I have tried creating a simple DLL with both eMbedded Visual C++ 4.0, and as a C++ smart device DLL in VS2005.
In both cases I get the "Can't find PInvoke DLL Whatever.dll"
The DUMPBIN looks perfectly fine in both cases, no name mangling, etc. The DLL is compiled for the correct processor. The DLL code is extremely simple:
{
return InVal + 1;
}
The function above is added to empty DLL projects created using the wizards, and the code to PInvoke is:
[DllImport("TheSimpleDLL.dll", SetLastError = true)]
private static extern UInt16 TestMe(UInt16 InVal);
private void button1_Click(object sender, EventArgs e)
{
UInt16 tmp1 = new UInt16();
tmp1 = 5;
UInt16 tmp2 = TestMe(tmp1);
textBox1.Text = tmp2.ToString();
}
Trouble using native DLLs
Binary
What I did was open Visual C++ | Smart Device and then I used the Win32 Smart Device Project template (not the MFC one). Then, in the Smart Device Project Wizard under "Application settings" I set Application Type to DLL
Sure thing.glennb10
There's not a lot of detail to work with but I suspect that the DLL isn't being found because it isn't in the right place.
I'm guessing you have a Visual Studio 2005 solution containing a C# project (the form application) and a C++ project (the DLL)
Right click on the C# project and select propeties then select the Devices tab. The Deployment Options will specify a Target device (e.g., Pocket PC 2003 SE Emulator) and an output file folder (e.g., %CSIDL_PROGRAM_FILES%\PocketPC2005 where PocketPC2005 is the exe's project name). That output folder is where your exe will be copied to on the target device.
Now, right click on the C++ project, select properties and then select the Deployment property page. Again, the property page will specify a Deployment Device (e.g., Pocket PC 2003 SE Emulator) and a Remote Directory (e.g., %CSIDL_PROGRAM_FILES%\TheSimpleDll where TheSimpleDll is the DLL project's name).
Since the default deployment destinations are based on the project name, you end up with the DLL in one folder under 'Program Files' and the exe in another folder under 'Program Files'. The exe runs, looks to load TheSimpleDll.dll and doesn't find it because it is in a different folder - hence the 'cannot find the dll' error.
You can confirm my theory by running File Explorer on the Pocket PC Emulator while you have a debugging session going. Look at where the files are placed under Program Files. Remember that by default "view all files" is turned off in File Explorer so files with a .dll extension are hidden. You'll need to press and hold a blank area within File Explorer to bring up the context menu and check "View all Files" before you'll see files of type DLL.
Now, copy and paste the simple dll file from it's original folder to the folder that the exe is in and you'll find that the program runs correctly because it can find the DLL.
That's okay as a kludge (and to confirm my guess) but it isn't much good as a long term answer.
One better fix is to edit the DLL Project Properties to change the Deployment page's Remote Directory to be the same as the exe's output folder. That way the DLL and the exe will automatically be deployed to the same folder when you rebuild.
SoSoSo
Interesting...
For the DLL you added (in VS2005) a VC++ Smart Device: MFC Smart Device DLL, for PocketPC 2003 platform, and under application settings selected: Regular DLL using shared MFC DLL
And this ran successfully under the PocketPC 2003 emulator
Could you zip up your test exe and dll and email them to me at: Ted.Warring@msisolutions.com please That way I can test it against our environment and then start decomposing the differences in the exe and dll from what we are getting.
Just as an FYI, we have had an open support incident with MS for 3 days and they have not been able to help us resolve it yet.
Joel in Redmond
PPC 2003 is ARMV4 and can not use ARMV4I DLLs. It's a wrong processor type for 2003. WM 5.0 is ARMV4I and can use both ARMV4I and ARMV4 DLLs.< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Mike Hulen
That is a good argument for WM 5.0, hopefully Symbol and other PPC manufacturers will be shipping it instead of PPC 2003 in the near future. Right now PPC 2003 is still prevalent with specialized equipment like we are working with.
David Szabo
Thanks Frank, but the problem is not the DLL not being where it should.
In both test cases (EVC++ 4.0 and C++ VS2005) the compiled DLL is added to the test C# project as content, and I have verified that the correct DLL is in the same folder as the test exe. We even tried placing the DLL in every conceivable folder as a process of elimination.
There is not a lot to go on because the problem is very simple to reproduce...
I would be interested if anyone can take the above code snippets and have successful results....
Paul Connell
Thank you very much for your help Frank, I was able to sucessfully test our internal native DLL under both eVC++ and VC++ VS2005 after receiving your test example.
There were two separate issues:
1 - MFC based CE DLLs do not work when compiled in VS2005.
2 - eVC++ 4.0 DLLs for the ARM4i processor must be compiled as ARM4 to work properly.
This should at least give us a starting point with the third party SDK DLL that we originally found this problem with. I suspect that they fall under case #2. I will ask them to make sure they are compiling against the ARM4 base processor.
We will let MS know about the above.
Thanks again for your help.
verv
I created a C# Smart Device project, dropped a text box and button onto the form and pasted your button_click body into my click event handler and your DllImport into my class definition.
Then I used Add New Project to add a C++ Smart Device project to the solution, made that a DLL type application and pasted your definition of TestMe under the DllMain.
At that point I had a project that got the "cannot find DLL" problem because the DLL and the EXE were being placed into two separate folders under Program Files. I changed the C++ project to deploy to the same folder as the exe and it all just works.
Another possible explanation for your symptom would be that DllMain is returning FALSE when called with DLL_PROCESS_ATTACH. That gives rise to the same "cannot find the DLL" exception (MissingMethodException really).