Posts related to: wwdotnetbridge
Creating and Debugging .NET Assemblies for wwDotnetBridge and Visual FoxPro
wwDotnetBridge lets you interface with .NET code directly, but if need to access more than a handful of lines of .NET code from FoxPro, it's a good idea to create a separate dedicated .NET component and call that instead. There are many benefits to easier and more discoverable access to functionality, better performance and support for a few features that don't work well through wwDotnetBridge. In this post I show how to create a .NET component, build and run it, and how debug it as well.
Workflow for using wwDotnetBridge to call .NET Components
In this post I'll describe the common workflow I use when I use wwDotnetBridge to check out the .NET code I'm trying to call first in .NET before actually starting to create the FoxPro code. This helps in discovering the features available on the libraries I'm trying to call, but it also validates that I'm using the .NET code directly before I start adding that extra layer of FoxPro abstraction on top of it.
Troubleshooting Asynchronous Callbacks into FoxPro Code
If you're passing FoxPro objects to COM objects and have .NET call back to you on objects that you passed makes it possible to effectively create asynchrnous applications where .NET code can process stuff in the background and notifying you when it's done or other needs to let you know that something changed. It's powerful but it brings its own set of problems in FoxPro, which wasn't design with Async code in mind. In this post I talk about some of the issue and some of the things you can do to…
wwDotnetBridge: Getting and Setting COM Unsupported Values with ComValue
ComValue is a useful helper class in wwDotnetBridge that provides a wrapper around .NET Values that otherwise would not be accessible to FoxPro due to COM value incompatibilities. ComValues can be passed into .NET methods and are returned as result values for wwDotnetBridge's intrinsic indirect access methods. In this post I describe how ComValue works and why we need it in the first place.
Fixing Windows Downloaded File Blocks and wwDotnetBridge
I'm happy to say that I've found a workaround for the nasty problem with wwDotnetBridge and not being able to load wwdotnetbridge.dll due to Windows file blocking for files or archives downloaded from the Internet. In this post i describe why files are blocked and how you can unblock them including a new solution that is fast and can be done from within a running application.
Calling async/await .NET methods with wwDotnetBridge
More and more .NET APIs expose Async only interfaces and it might seem that calling async await code from FoxPro seems like it would be difficult. I had my doubts it would but as it turns out it does. In this post I describe how async await works in .NET and how the lower Task API is used to implement it, and more importantly how we can call async methods using the .NET Task API.
GAC Assemblies with wwDotnetBridge
wwDotnetBridge makes it easy to load up .NET assemblies and reference to access contained classes and other types. Standalone assemblies can be loaded easily enough by filename, but assemblies that live in the GAC should be referenced by their fully qualified assembly name. Here's how.
Controlling the JSON.NET Version in wwDotnetBridge with Assembly Redirects
JSON.NET is the most popular .NET component used in more components than any other and because of that you can end up finding other components that also use JSON.NET and perhaps with a different version. Trying to load a different version of JSON.NET in an application can cause runtime failures for loading the assembly. The workaround is to use .NET Assembly Redirects in the application's .config file. Here's how to do this.
Fixing wwDotnetBridge "Unable to load Clr Instance" Errors
When you get "Unable to load Clr Instance" Errors while trying to load wwDotnetBridge, look for an unfortunate but simple to fix security issue with Windows. Here's how to get around this error.
wwDotnetBridge and .NET Versions
wwDotnetBridge supports explicitly specifying which version of the .NET Runtime is loaded. But only one version of the runtime can be loaded into the FoxPro application process, and so the first wwdotnetbridge load wins. Here's how loading works and how you can ensure you're loading the right version for your application.