From time to time, we’re asked about the best way to use NMath to build Silverlight applications. Unfortunately, like so many answers in software development, the answer is: it depends.
Silverlight is a great way to build line of business applications, but at its core, Silverlight runs within a sandboxed environment, typically within a browser, and usually within a networked intranet or Internet environment. NMath, on the other hand, uses native libraries to provide high-performance math capabilities to managed code. While it’s possible to build a Silverlight application that calls NMath functions, it’s worth taking a step back to look at what you really want to accomplish with your software project.
Most often, we find that developers are tasked with building dashboard-style business applications that allow the user to initiate some sort of data analysis, and then see a visualization of results. In these cases, we generally recommend:
1) Use Silverlight (or HTML5) on the client, perform the analysis on one or more servers, and expose web services to initiate the analysis and deliver the results.
This is probably the most favorable approach, and usually the architecture to default to unless there’s a compelling reason to the contrary. Some of the advantages of this approach:
- It’s consistent with typical Silverlight application architecture; capabilities in Silverlight and ASP.NET make it easy to build this kind of application.
- It retains the deployment advantages of Silverlight: there’s no need to distribute and install native components to every client machine.
- It retains the cross-platform advantages of Silverlight: the application will work smoothly regardless of client hardware (including on Mac OS).
- Centralizing the analysis on a server makes it easier to scale up with improved server hardware and/or server farms.
- It makes efficient use of network bandwidth: usually there’s little need to transfer all of the source data between client and server, just the results of the analysis.
The primary disadvantages of this approach include:
- This might drive an architectural shift if it’s not already working in a client-server environment.
- It doesn’t take maximum advantage of available computing resources on the client, at least for the analysis (although the application can potentially use the client’s GPU for the visualization).
If you’re certain that you want to perform the analysis on the client using a Silverlight application, you can:
2) Use Silverlight 4+, and use COM interop to invoke COM components that were previously installed on the client.
3) Use Silverlight 5, and use Platform Invoke (P/Invoke) to invoke native components.
There are significant disadvantages to these approaches, in particular:
- You would need to separately distribute your components and get them preinstalled on the local machine.
- The client applications will only run on Windows; you cannot invoke native code on Mac OS from Silverlight.
- Users will need to explicitly grant elevated trust to the Silverlight application.
- You would also need to build your application with out of browser support (if you’re using COM interop).
For the COM interop approach you would use ComAutomationFactory.CreateObject() to instantiate dynamic COM objects, which would also mean that you would require C# 4, Silverlight 4, and Visual Studio 2010. This approach is less than ideal for new applications; it’s primarily intended for interaction within controlled environments (e.g. interop with Microsoft Office). For more about this, see:
For information about P/Invoke in Silverlight 5, see:
However, if you’re certain that you want to build a rich client application to perform the analysis on Windows, then you should also evaluate whether Silverlight is the best choice for doing so. Some alternatives include:
4) Create a rich client application using Windows Presentation Foundation, and run in within the browser using XBAP.
XBAP applications are WPF applications that run in partial trust inside a web browser. You do have access to more local resources than you do in Silverlight, and you can request the user to grant additional trust if needed. You’re restricted to using Internet Explorer and Firefox. For more about this, see:
5) Create a rich client application using Windows Presentation Foundation or Windows Forms, and distribute it via ClickOnce Deployment.
In this scenario, you’re running a full client application within Windows, but taking advantage of some of the deployment advantages of the web, including initial distribution and facilities for automatic application updates. Generally speaking, this is the preferred way to build rich client applications on Windows. For more about ClickOnce, see:
Our experienced consulting team is available to help you work through the architectural options that would make the most sense for your specific application; just contact us at email@example.com.