[SP2013] SharePoint add-ins in DR farms

When setting up a second SharePoint farm for disaster recovery purposes, there are all kinds of things to take into consideration. Most of those are perfectly covered in other blogs and on TechNet.

With the new app add-in model though, there is one additional factor to take into account: appsadd-ins! When in case of a disaster you need to switch operations over to your second farm, you want your add-ins to remain working. And there’s some stuff you need to take care of to make sure they do. Read on to find out what. Read More

SP2013: SharePoint hosted app, getting to your lists

As described in my previous post, a SharePoint app gets its own Web instance in which it lives. For the SharePoint engine, that means getting rid of your app is easy: just delete the web and everything is gone. The web gives you the option to deploy regular SharePoint stuff like lists and columns. But now that you’ve got your solution setup with a list; how can you reach it to add items? Read More

SP2013: App deployment within your organisation

In this previous post I talked a bit about the new SharePoint app model. I started playing around with the examples on MSDN and succeeeded in producing an actual working app. Great.

All of this is done within a special developer portal (which is well documented in the MSDN getting started articles). You open a project in Visual Studio, set the correct URL yo your site, press F5 and away you go.

But what happens when your app is finished? I starting looking around for a way to upload it. Logical place would be a an “app gallery” as there is a solution gallery for sandboxed solutions. Didn’t find one. But I noticed Visual Studio creates a WSP for these new solutions as well. So I tried uploading that to the normal solution gallery and activating. That succeeded, but changed little. I also found a feature for my app, so perhaps that needed to be activated? Still no listing in the “install an app” form.

So what do you DO need to do to get this working? Here we go:

– Open the admin part of your site. In the top navigation bar (the one with Office 365 Preview in it), click on “Admin” and choose “SharePoint”.

– Now in the admin section, choose “Apps”.

– It’ll ask you to connect to an existing gallery or create a new one; create a new one.

– Fill in the site details, this is just the same as creating a new SharePoint site.

– Wait a bit for the creation process to finish. You’ll now have a seperate site on which you can manage your apps. If you upload an app here; it’ll be available on all of your site collections within your subscription.

Of course, when you want to reach a broader audience; you can also upload your app into the global store, so it can be sold worldwide. Great opportunities there!

One thing I’m missing (perhaps it’s there but I didn’t find it), is the option to scope your apps to certain site collections. For instance, imagine you’ve got multiple departments, all with their own SharePoint site collection. Your HR appartment requests an app to be build and so you provide them with a custom made app. Now what you would like is to make that particular app available within the HR section only. As far as I can see, this is not a supported scenario. Once you upload your app, it’ll be available across all site collections. You can categorise the apps you upload, but that’s just for ease of use, not for scoping.

SP2013: Proxy problems with SharePoint 2013 apps

Ok, a bit sooner as I had expected; but here’s my first tech post on SharePoint 2013.

I was trying out some of the examples found on MSDN for creating SharePoint 2013 apps, such as this one: http://code.msdn.microsoft.com/SharePoint-2013-Hello-0fd15fbf. I kept on running into several problems; beginning with the infamous “object reference not set to an instance of an object” nullreference exception. After some scooping around in the matching TokenHelper.cs file, I noticed it had something to do with setting up a connection to the access control service (ACS) at Microsoft.

Read More

SP2013: apps versus sandbox

Hi SharePoint friends! It’s been a while. The last few months I was changing jobs (more about that in a seperate blog post) and taking vacation. Just before that, Microsoft released the first bits of SharePoint 2013. As is the case with 2010; this new version comes in two flavours: an on-premise installed version for which you need a server, and an online hosted version within Office 365, which is offered as a service. As we developer have become used to: development options differ.

I’ll leave the normal solution building to what is was for now, since that’s not the most eyecatching change. Then what IS, you ask? Apps! Since a few years, the terms “apps” is hot and happening, so Microsoft decided SharePoint and Office needed apps too. And they we’re probably right.

So, what exactly is a SharePoint 2013 app? I’m not sure if there’s an official definition out there somewhere, but here’s my view. An app for SharePoint is a solution (collection of files) which is meant to run client side; in the users browser. You cannot deploy server side code like codebehind, webservices, that kind of stuff. Where a sandboxed solution let’s you use a limited part of the server object model, an app only allows you to use the client side bits (i.e. the JavaScript ECMA model).

Update! There seems to be somewhat of a definition (found here): “So what’s an app? It’s best described as a solution that carries a light footprint and uses standards-based technologies such as HTML5, JavaScript, and OAuth.

My initial response was: why would you want to build a solution with even less options as opposed to a sandboxed solution (which is already pretty limited and thefeore sometimes pretty annoying)? But after thinking about it twice, it might be even better than sandboxed solutions because of the extra limitations. I’ll try to explain why.

If you’ve ever tried developing solutions for Office 365 / SharePoint online, you know the limitations of the object model in the sandbox. Especially when you’re used to building “normal” onpremise farm solutions, these limitations are sometimes frustrating. You’re used to solving problems in a certain way and suddenly Microsoft decides your way of working isn’t going to work any longer. You need to find other ways of doing the same (which feels like a workaround to you), which takes time and learning. So a task which you already knew how to implement in a normal solution suddenly takes more time to build for the sandbox.

Because an app is fundamentally different, it doesn’t resemble a standard solution. The way of creating one is different, the goals are probably different, the tools are different (ok, you can also use Visual Studio of course). Being forced to use the client side bits, you start solving problems in a completely different way instead of using your standard object model knowledge. That’s a good thing.

Because of the client side, disconnected nature of apps, you’re forced to implement asynchronousity in a proper way. I don’t like doing async stuff in JavaScript (scripts easily get bloated and unreadable), so for Sandboxed solutions I tended to just write some server side code for stuff which I probably should have better handled client side instead. I still don’t like async stuff, but now I’m forced to do it and I’m forced to do it in a proper way if I want to remain writing maintainable code. The skillset for writing apps differs from my current skillset. So I need to learn how to do it properly using JavaScript. And was about time I did 🙂

I’m not sure yet how much time I’m going to be able to put into SharePoint 2013 the coming months. But I’ll definitely share some insights and hopefully code here. Towards the end of November I’ll be attending the Dutch SharePoint conference, which will probably feature a lot of SharePoint 2013 content. So stay tuned; there’s more to come!