I was recently working on a Lightswitch application to integrate some SQL assets with SharePoint document libraries through a provider hosted app, and hit a snag. Anyone who has worked with Lightswitch knows the pain of using the visual designer for screen development.

Last post I talked a little about how I enjoy using REST and JSON instead of the Client Object Model. When developing I feel much more comfortable working with REST APIs and recently had a need to consume JSON on the server using C# and .net. The normal process would be to retrieve a JSON object, parse it into C# classes that you've created to consume on the server and then do something with the data.

If you are working with large JSON objects, this can be a time consuming task. Lets say you had a JSON object that would result in say 40 C# classes, you'd be pretty bummed to take on the tedious task of creating each one by hand. Well luckily, Visual Studio 2012 and higher has given us the ability to automate this process and allow us to continue working on the important things. 

The Scenario

I’ve been working on a SharePoint hosted app that requires a daily workflow to run to count the number of vacant and occupied homes in each building and create a list item for each day. From there we can use this data to create occupancy charts and graphs with chartJS or Power BI but first thing’s first, I needed to write a workflow that will get me this data in a list called Occupancy Data.

2014 was a big year for SharePoint in the world of forms—Microsoft chose to drop support for InfoPath forms. For years SharePoint developers, users and IT Admins used InfoPath as a means for creating clean and intuitive forms to replace out of the box SharePoint forms. In this post, we’ll explore what the future holds for form development in the absence of InfoPath.