31. August 2013
VS2013 , LightSwitch
When you have SharePoint Enabled in a LightSwitch solution you can work with SharePoint Lists in different ways. As a data source or ‘in App’ added as a list to the SharePoint project.
The choice is yours what to use … below some different characteristics.
As a data source
adding a SharePoint List as a data source.
- The list must exist on SharePoint.
- The list isn’t deployed together with the LightSwitch App. There is no connection with the LightSwitch Solution and the SharePoint List only by connection string.
- When you upgrade your LightSwitch solution you must not forget to update your list manually (when you made table changes)
- The SharePoint list isn’t affected when you uninstall the App.
- The connection to the List is set during packaging of the App in Visual Studio When deploying the App to a different Site (where you created the list) , you must package the App specific for that site, with the proper connection string.
- The SharePoint Lists can be saved as STP, which can contain data.
- The SharePoint List is a LightSwitch entity, which can used by the screens. Browse Edit Add for free,
- The SharePoint List is an entity in the LightSwitch App and can be accessed in code with intellisense.
- You can create relationship between the different data sources.
As a List in the SharePoint Project
Add a List to SharePoint Project in the solution.
- Lists in the SharePoint Project uses the SharePoint App Deploy and Update mechanism. The table stays with the LightSwitch App, also when installed on different sites. When updating the table structure is updated too (when not deleting columns or changing data types, adding columns is fine). When deleting the App the list and data are gone too.
- The SharePoint List can be accessed with CSOM from LightSwitch.
- The table entities are accessed in code by Name, no intellisense and compile time warnings.
- The SharePoint List isn’t an LightSwitch entity ad can’t be used (out of the box / browse, update, edit for free) with the LightSwitch screens.
So the tradeoff is most about … the usages of the screens (browse, update, edit for free and intellisense ) versus the deployment model (a package per site and manual update the lists.)