We have been busying working on lots of new features of xInterop C++ .NET Bridge for more than a year and I have not been able to find time to write technical article for too long, and I found the last time I wrote about Native C++ to .NET Bridge was 15 months ago. Since then, the features of Native C++ .NET Bridge is getting much richer, actually, the other bridge, .NET to Native C++ Bridge has gained lots of new features too.
If you don’t know already, xInterop Native C++ .NET Bridge is based on P/Invoke (PInvoke), Reverse P/Invoke (Reverse PInvoke) and also xInterop Technology on top of xInterop .NET to Native C++ Bridge. If you are currently using C++/CLI or about to use C++/CLI, xInterop C++ .NET Bridge is the perfect candidate to replace C++/CLI, it is much better than C++/CLI in terms of productivity and it lets you build native C++ bridge DLL automatically for the targeting .NET assembly, developers can even use post-build script to build the native C++ bridge DLL automatically every time the targeting .NET assembly is changed and rebuilt.
Let’s take a look what we have added since the last time we blogged about it.
The following is the configuration window of the earlier version of Native C++ to .NET Bridge.
And the following is the current configuration window of Native C++ to .NET Bridge.
As you can see from the differences of the two screen-shots, there are lots of new features and changes. Let’s examine each of them one by one.
1. Honor .NET namespace
The earlier version of xInterop C++ .NET Bridge puts all bridge C++ classes, enums in the namespace of xinterop, we have changed to enable users to honor the .NET namespaces. It seems a very small change, but because the Native C++ to .NET Bridge relies on the .NET to Native C++ Bridge, we had to make Native C++ Bridge support namespace first. I am giving you a few examples of the C++ namespaces matching to the corresponding .NET namespaces. It is an option, users can still choose to map all namespaces to xinterop namespace for simplicity, not everyone likes complicated namespaces and having to either type “using namespaces” or full type of each of c++ bridge classes and enum. But this won’t work when there is duplicate class name, struct name, enum name in different namespaces, it will cause compiler error when xInterop C++ .NET Bridge tries to build the native C++ bridge DLL. Honoring .NET namespace resolves this kind of issue.
2. Debug and Release version of the native C++ Bridge.
Any auto-generated Native C++ bridge DLL relies on the also-auto-generated .NET bridge assembly to communicate with the original .NET assembly, at present, the .NET bridge assembly are configuration specific, its debug version can only communicate with the debug version, the release version can only communicate with the release version, the reason for that is the size of instance of each class may be different in the debug version and release version. When the native C++ bridge DLL is used in a C++ application, the debug version and release version can’t be mixed, a debug version of the C++ application can not call a release version of the DLL, a release version of the C++ application can’t call a debug version of the DLL, the native C++ bridge DLL is a normal native DLL. If users try to build a C++ application by linking to the native C++ bridge DLL in a different configuration, it will trigger a compiler error.
3. .NET exception handling
Any call from the Native C++ bridge DLL into .NET method including constructor may trigger .NET exception which can be handled by the .NET bridge assembly and then a C++ exception can be raised in the Native C++ bridge DLL with all the available information from the original .NET exception, including message and stack trace, etc.
4. Simulate .NET property and index
.NET class may have property or index while C++ language do not have concept of property and index. In the earlier version of xInterop C++ .NET Bridge, a property with a name of get_Value gets mapped to a C++ method of get_Value. With this new feature, an instance property of .NET becomes a property of the native C++ bridge class, an .NET index also have corresponding index in the native C++ class. This feature does not support static property.
5. Support WPF
When the option of Support WPF is enabled, xInterop C++ .NET Bridge will create bridge classes for all necessary WPF controls to support create and manipulate WPF windows and controls from the native C++ application using the native C++ bridge DLL.
6. Support WinForm
When the option of Support WinForm is enabled, xInterop C++ .NET Bridge will create bridge classes for all necessary WinForm controls to support create and manipulate WinForm windows and controls from the native C++ application using the native C++ bridge DLL.
7. Support WinForm controls
When the option of Support WinForm controls is enabled, xInterop C++ .NET Bridge will create bridge classes for all windows WinForm controls so that users do not have choose the controls by themselves.
8. Support WCF service
When the option of Support WCF service is enabled, xInterop C++ .NET Bridge will create bridge classes for all necessary .NET classes to support create and manipulate WCF service from the native C++ application using the native C++ bridge DLL.
9. Support .NET extension methods
The extension methods are defined outside of the original class declaration, mostly, it is implemented in a different assembly than the one implementing the original .NET class. To find the extension methods, xInterop C++ .NET Bridge will have to iterate each classes of all the assemblies involved. The option can be turned off if extension method is not a concern.
10. .NET type selection
When targeting a certain assembly, if users are not interested in creating bridge C++ classes for all .NET classes, or they are interested in creating bridge C++ class for other .NET classes outside of the targeting assembly, such as the .NET classes implemented by the .NET framework, they can choose which classes to be bridged.
11. Static read-only field optimization
A .NET static read-only field may contained a fixed value through out of the lifetime of an application. Once being fetched, the value never changes. When this feature is enabled, xInterop C++ .NET Bridge will create code caching the value in the native C++ bridge, no call shall be made the next time the same static read-only field is accessed.
12. Targeting .NET framework different from the framework of the .NET assembly.
The original .NET assembly may be targeting earlier version of .NET framework, such as .NET framework 2.0, this feature allows users to target a higher version of .NET framework when using the native C++ bridge DLL together with the .NET bridge assembly.