Generally speaking, it is bad practice to introduce such coupling between systems; however, some business requirements might require such external access. When required, make sure you run your plugins in an asynchronous mode in order to avoid the online plugin limitations and also to enhance user experience. If you need to write to an external source, best practice dictates that you use the Azure Service Bus, as described in Setting up an Azure Service Bus Endpoint later in this chapter. The Service Bus has many advantages, including scalability, queuing, better error handling mechanisms, and loose coupling.

As for merging different assemblies with your assembly, ensure the external libraries can run in the sandbox mode (check out this article to test your assembly https://msdn.microsoft.com/en-us/library/bb763046(v=vs.110).aspx).

While writing this recipe, I tried to access Azure's DocumentDB using the WindowsAzure.Storage NuGet package from within the plugin. An exception was thrown when trying to instantiate the object (even before connecting) due to the constructor trying to access the server's resources (more specifically, the default tracing services). Even using the System.Data.SqlClient library will throw a security restriction exception. This is due to the sandbox mode limitations that do not permit some classes' instantiations. To address this issue, you'll have to create a supported façade to your SQL database or other storage platform. The pattern is similar to what we discussed in Connecting to Dynamics 365 using web applications in this chapter, but for your repository as opposed to Dynamics 365.