The downsides of Sharepoint are cost, it is not cheap in itself and also it requires a Windows Server licence. If your employer is pro-Unix then this will be a deal-breaker. The other downside of Sharepoint is that your VBA code will not run and will have to be converted to C# or some other managed .NET language.
Nevertheless, the Sharepoint 'market share' of the Excel solution space will grow and a blog on Excel Development should address it.
I've yet to reach recommendations for this technology so this first blog post will solely be a collection of links for more reading.
Some sample C# code for a server-side Excel Services UDF.
// From https://dev.office.com/sharepoint/docs/general-development/step-2-creating-a-managed-code-udf
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Office.Excel.Server.Udf;
namespace SampleUdf
{
[UdfClass]
public class Class1
{
[UdfMethod]
public double MyDouble(double d)
{
return d * 9;
}
[UdfMethod(IsVolatile = true)]
public DateTime ReturnDateTimeToday()
{
return (DateTime.Today);
}
}
}
However, if you thought getting a UDF to run on both the client and the server in a unified code base would be a breeze then check out this web page which shows how to do it. It seems a major undertaking requiring C#, C++/CLI (formerly Managed C++), creating code to handle a managed Add-in and a custom shim. I expect many to be dissuaded from using SharePoint because of the complexity there but I also expect Microsoft to unify the client side and server interfaces in the future.
Whilst I have yet to reach recommendations on Sharepoint and Excel Services one has to wonder why rendering a workbook in a browser which requires a Windows Server, Sharepoint Server and Internet Information Server is better than keeping a workbook of a network file server (running on Linux) and opening in Excel. I guess the question boils down to client licences versus server licences.
No comments:
Post a Comment