You are viewing an older version of this section. Click here to navigate to the latest version.

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.

When testing an HTTP endpoint from a browser, my flows invoke twice, once for the URL I request, and again for favicon.ico.

When a browser receives a response that it interprets as HTML, the browser attempts to retrieve the favicon.ico file for the site to display with the URL in the address bar. In an integration scenario, most HTTP responses are non-HTML payloads and so should be marked as such. You can mark HTTP responses as non-HTML payloads by setting the MIME type explicitly in the HTTP endpoint configuration’s Advanced settings.

For example, if your payload is JSON, specify the MIME type as application/json:


Alternatively, if you return XML, you can set the MIME type to text/xml. As long as the browser does not receive a MIME type of text/html or application/xhtml+xml then the browser suppresses the request for favicon.ico and prevents this second activation of the Mule flow. This issue is not likely to occur for a client application that directly connects to your HTTP endpoint.

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.