SharePoint Dragons

Nikander & Margriet on SharePoint

Monthly Archives: September 2012

Close Encounters of the Third Kind with another Wiki life

Margriet is a regular TechNet Wiki contributor. Read more about SharePoint Wiki pages:

SharePoint 2013 Best Practices: What client API should you choose when building Apps?

There are a lot of different options when it comes to communicating with SharePoint. Here’s some advice when to use them when building Apps:

  • Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model.
  • Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the .managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.
  • Apps hosted on non-Microsoft technology (such as members of the LAMP stack) will need to use REST.
  • Windows phone apps need to use the mobile client object model.
  • If an App contains a Silverlight application, it should use the Silverlight client object model.
  • Office Apps that also work with SharePoint need to use the JavaScript client object model.

See for more general guidelines concerning client API choices and solution development.

Keep track of newer insights at TechNet Wiki page

Talking about the Wiki Compare Feature in a “Matter of Fact” Tone

Margriet is a regular TechNet Wiki contributor. Read more about the Wiki compare feature:

Apps causing client-side mess?

The mantra of SharePoint 2013 seems to be: “Must get all the evil custom code out of SharePoint” (whether that will be workflows, InfoPath, or farm solutions). Is it just us or is the new best practice of creating Apps for SharePoint 2013 leading to a big mess of so-called “client-side pattern” cum “spaghetti” code? At this point, it feels as if MS is catapulting SharePoint devs back into a time where JavaScript was the main tool of the trade (or, as is suggested here, you should build business logic using client-side JavaScript: It seems that in one or two new versions of SharePoint from now we all will be saying: “of course this old development style lead to all kinds of problems and messy code, luckily now we have a development environment that fully supports OO client-side development”… Anyway, this Wiki page contains a link to some of the emerging design patterns for Apps for SharePoint 2013:

LAMP and Apps – Are people getting too excited?

Without getting into much detail,  there are several host models for Apps in SharePoint 2013, namely:

  • No-hosted
  • SharePoint-hosted
  • Provider-hosted

Again, without getting into details, provider-hosted Apps can be hosted on dedicated application servers or in the cloud (Azure). We want to take a moment to reflect on the provider-hosted Apps on dedicated application servers… Those Apps are stand-alone applications that run completely outside of your SharePoint farm, and SharePoint is completely technology-agnostic as far as these Apps go. This means, Apps can be hosted on application servers running, for instance, using any technology on the LAMP stack (Linux, Apache, MySQL, and PHP).

This particular feature was hailed enthusiastically by lots of SharePoint bloggers. We don’t share the sentiment. Although in itself it’s great to have the flexibility to use any flavor of application server you like, in reality we’ve found that this type of platform independence is almost never an issue (Roger Sessions once did some, unscientific, research about it, wrote about it, and found that this is a factor in less than 1% of the IT projects). If you’re an avid Java or PHP developer planning to build Apps, you’ll find that you still have to have intimate knowledge of SharePoint technology and development models. What’s more, developing these types of solutions will be a lot easier using the Microsoft dev tools. We’re convinced that the share of skilled Java and SharePoint developers is pretty limited and we’re betting it’ll stay that way for times to come. In addition, some SharePoint bloggers have even predicted the end of the era of SharePoint developers, since now every ASP.NET developer will be able to create Apps as well. We think this is nothing more than a wrong conclusion, for exactly the same reasons. If you want to develop SharePoint solutions in the form of Apps, you need the knowledge about the platform. You simply can’t do that while you’re avoiding becoming a “SharePoint” developer.

Your thoughts?

Full Trust Solutions in SharePoint 2013

We’ve never seen a version of SharePoint where so much information was already available during beta release. We did notice though that a lot of articles contrasting farm solutions, sandboxed solutions, and Apps use the terms farm solutions and full trust solutions interchangeably (even so in MSDN documentation).We  don’t think this is fair, because it implies that farm solutions can’t run without full trust. The opposite is true, farm solutions can run under very fine grained security policies. We do know where the confusion is coming from, a new change in SharePoint 2013 is that now, the default CAS policy that is used us Full Trust, instead of wss_minimal:

<trust level=”Full” originUrl=”” legacyCasModel=”true” />

In effect, this will mean that by default, a SharePoint 2013 farm solution will run under full trust, which makes it a full trust solution. Things didn’t use to be like that, and we feel this is definitely a step backwards for the latest version of SharePoint. At this point, all we know that this change is caused by the fact that the full trust is needed by .NET 4?! We don’t have more specifics, and we don’t know if SharePoint  2013 is able to run under a different trust model without breaking.

SharePoint 2010 Web Parts in Action

We were technical reviewers of the book “SharePoint 2010 Web Parts in Action” and found it to be one of the best books about SharePoint 2010:

It discusses the following topics:

  • Using web parts in the SharePoint UI
  • Working with web parts via SPD
  • Building web parts in VS.NET 2010
  • Using controls, validators, CSS, web part verbs
  • Web part properties, custom editor parts, type converters and runtime filters
  • Web part resources and localization
  • Packaging, deployment, sandboxed solutions, and upgrading
  • Troubleshooting
  • Performance and caching
  • Ajax in web parts
  • Notification messages, the status bar, and the dialog framework
  • Adding controls to the ribbon
  • The client object model
  • Silverlight web parts
  • Mobile web parts
  • MVP pattern
  • Service Locator pattern
  • Testing web parts
  • Creating connectable web parts
  • Building web part pages and dashboards

Office 365 2013 Preview

Lately, we’ve been getting the question how to get to the Office 365 2013 Preview a lot, so here goes:

Wiki Scorecard

Margriet is a regular TechNet Wiki contributor. Read more about Wiki scorecard in the following Wiki article:

Enabling a wireless network for your virtual machine

We liked this article about enabling a wireless network for your virtual machine: