DotNet Connector FAQs
The DotNet connector lets applications call .NET code from a Mule flow.
There is a prerequisite for .NET 4.5 (at least currently) to be installed on the Mule Server that calls the .NET code. The .NET components themselves can be written for any .NET framework version.
No, you must install the .NET assembly that you’re calling on the local Mule Server.
MuleSoft is using a JNI Bridge allowing Mule flows to bridge the Java Virtual Machine and the Common Language Runtime (.NET CLR). The connector includes extensive tooling code that allows Mule to perform serialization and deserialization of the code.
Currently, neither are supported scenarios. The DotNet connector has a dependency on the .NET CLR which is currently only available on Windows machines. The Mono project is not supported at this time.
Many organizations have standardized on writing code using the .NET Framework. This component allows them to continue to build interfaces using .NET without rewriting current code into Java. .NET developers can continue to write code in their preferred language while also integrating with the Anypoint Platform.
If my existing .NET code uses app.config files to store configuration, can this code still be leveraged by the DotNet connector?
Yes, this code can still be leveraged.
What are the performance impacts of using the DotNet connector compared to a similar Java component?
The performance impact is negligible in the context of most Mule integration scenarios.
When Mule ESB calls out to to .NET code it does so in a synchronous manner. You cannot invoke async methods directly from Mule ESB. However, you can call other methods asynchronously once you are in your .NET code. It is recommended that, instead of using these .NET features to initiate asynchronous messaging, you implement Mule ESB’s core messaging features such as Scatter-Gather.
No, assemblies do not have to be strongly named or signed.
Yes, it is possible to debug .NET assemblies by manually attaching Visual Studio to a Java process.
Yes, the additional Mule tooling includes a messaging API that supports Mule message. Flow variables can be accessed via implementing
You can call methods in any .NET based DLL, whether existing binaries or those newly built specifically for the purposes of processing messages in Mule applications. These DLLs can be built using any .NET language, including managed C++, but it must be a .NET assembly. If you need to call native C libraries, you can build a wrapper in .NET that uses DllImport to expose the native methods.