Rick,

One more question - can we use your library in our commercial applications for free or we need a license? I think your site indicates it's free for use (just the wwDotNetBridge), but I want to make sure.


>Typically the issue if the debugger doesn't want to attach is that you're not running the right version of .NET that the debugger can debug. VFP may or may not load the right version by default. Typically you can't debug a 2.0 dll in a 4.0 project.
>
>I suggest you create an instance of wwDotnetBridge and do:
>
>

>loBridge = GetwwDotnetBridge()
>? loBridge.GetDotnetVersion()
>

>
>This will tell you the version of .NET that is actually loaded.
>
>You can specify the exact version of .NET in the config file - so if you're running the VFP ide you can create vfp9.exe.config and add:
>

><?xml version="1.0"?>
><configuration>
>  <startup>   
>	<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
>    <!-- <supportedruntime version="v4.0.30319"/> -->
>    <!-- supportedRuntime version="v2.0.50727"/ -->    
>  </startup>
>  <runtime>
>      <loadFromRemoteSources enabled="true"/>
>  </runtime>
></configuration>
>

>
>The VS debugger will pick up the runtime version and so will know what version of .NET to debug.
>
>wwDotnetBridge is compiled for .NET 2.0 and that's part of the reason why the debugger might jump into the wrong version. It's 2.0 so that it can work on just about any system that has .NET installed (there are a lot more machines with 2.0 than 4.0 today).
>
>+++ Rick ---
>
>
>
>>>>
>>>>But now the challenge is to make that same dll work from VFP and I ran into the same problem - it doesn't find that .ini file. Since I can not test that DLL from VFP, I am not sure where to place that .ini file and how to name it. I sent this question to my colleague who developed that class.
>>>
>>>Sure you can (assuming you have the source to the .NET DLL). Open the .NET project up, select Debug, then Attach to process. Find the VFP instance and attach to it. Now you can set your breakpoints in the .NET code and they will be hit when your VFP code calls it.
>>
>>For some reason, it didn't work. The code didn't stop at the breakpoints.
>>
>>I see this in the output window:
>>
>>'vfp9.exe' (CLR v4.0.30319: wwDotNetBridge_383459193): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
>>'vfp9.exe' (CLR v4.0.30319: wwDotNetBridge_383459193): Loaded 'c:\dev\v40\sysmanager\siriusware.library.dll'. Cannot find or open the PDB file.
>>'vfp9.exe' (CLR v4.0.30319: wwDotNetBridge_383459193): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
>>
>>
>>'vfp9.exe' (CLR v4.0.30319: wwDotNetBridge_383459193): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
>>
>>
>>I am not sure why did it try to load the c:\dev version of the dll as I put this in the call:
>>

>>if loBridge.LoadAssembly("C:\_Siriusware\Main\Siriusware.Library\Siriusware.Library\bin\Debug\Siriusware.Library.dll")

>>
>>e.g. I specified the exact path to the dll (although I also had the dll in the application directory from where I was testing it).
>>
>>I am going to re-start VFP to be sure.
>>
>>UPDATE. Could not make it to work. VS does not stop on the breakpoints.