DotNet Connector FAQs
What is the DotNet connector?
The DotNet connector lets applications call .NET code from a Mule flow.
What versions of the .NET Framework do the components use?
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.
Can .NET Assemblies installed on remote machines be called from the DotNet Component?
No, you must install the .NET assembly that you’re calling on the local Mule Server.
How is it possible that a Java platform, such as Mule ESB, can call .NET Code?
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.
Can I use the DotNet connector on Linux or CloudHub?
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.
Why should I be interested in the DotNet connector?
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.
Can I take advantage of the .NET async features available in .NET 4.0/.Net 4.5?
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.
Do my assemblies have to be strongly named or signed?
No, assemblies do not have to be strongly named or signed.
Am I able to debug my .NET assemblies in Visual Studio?
Yes, it is possible to debug .NET assemblies by manually attaching Visual Studio to a Java process.
Am I able to access Mule message properties within .NET?
Yes, the additional Mule tooling includes a messaging API that supports Mule message. Flow variables can be accessed via implementing Callable.
Can I call any DLL with the .NET connector?
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.