Thanks, Darren! Much appreciated. I've got the DLL building OK in VS but figuring out how to debug is a challenge. Apparently because the solution is a "Helper" class library, direct debugging is not possible. In VFP I'm using wwDotNetBridge to load the assembly which appears to succeed but when I attempt to invoke the static method it returns a null. Until I can figure out the debugging process it's an arduous process. Rick Strahl has a pretty extensive white paper on how to do this sort of stuff but the learning curve is steep for an old VFP guy...
-- rk From: ProfoxTech <profoxtech-boun...@leafe.com> On Behalf Of Darren Sent: Tuesday, April 4, 2023 10:53 PM To: profoxt...@leafe.com Subject: RE: Fun with .Net DLLs Richard it is relatively simple. Done it many times but not for a while - I'll hunt down my notes and get something to you. Essentially it is making the .Net assembly com visible and then it is easy to use in VFP. I'll do that this evening. Cheers -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Richard Kaye Sent: Wednesday, 5 April 2023 1:37 AM To: profoxt...@leafe.com<mailto:profoxt...@leafe.com> Subject: RE: Fun with .Net DLLs Thanks, Alan, much appreciated. I was just going through the various build options. The 32 bit thing will be a the top of the checklist. I thought there was a magic way to connect the debugger to an external process (e.g. VFP). There's some stuff in Doug's white paper on how to do that but I'm just at the beginning of this journey. -- rk From: ProfoxTech <profoxtech-boun...@leafe.com<mailto:profoxtech-boun...@leafe.com>> On Behalf Of Alan Bourke Sent: Tuesday, April 4, 2023 10:36 AM To: profoxt...@leafe.com<mailto:profoxt...@leafe.com> Subject: Re: Fun with .Net DLLs Richard I assume you created a project of type 'Class Library'. No you can't debug those, you need to host it in some other sort of exectuable project. To debug that you either need to add another project of a type that is executable to your solution (like a Windows Forms, WPF or Console application) and reference the output from the first project in that, so you can test it. You need to right-click on that project in Solution Explorer and select 'Set As Startup Project'. Normally I would recommend to test it on the .NET side you actually use a proper testing framework like MSTest or NUnit. However what you're trying to really needs to be checked visually so that's probably overkill initially. Did you make the relevant methods COM-visible, i.e. like: [ComVisible(true)] [Guid("8C019E76-59BE-43A6-9DD9-66F7C9CAE67B")] [ProgId("MyApp.ExcelConvert")] [ClassInterface(ClassInterfaceType.AutoDual)] [ComSourceInterfaces(typeof(IExcelConvertEvents))] public class ExcelConvertHelper { ... } I must confess I've never gotten the wwDotNetBridge registration-free COM to work. I've always had to add an installer project in .NET and just make users install and register the assembly. Don't forget you have to build it as 32-bit to use it from VFP. -- Alan Bourke alanpbourke (at) fastmail (dot) fm [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/mn2pr10mb34074c6e627bf651d8ff4b82d2...@mn2pr10mb3407.namprd10.prod.outlook.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
