Debugging a solution with multiple SharePoint Apps

In a very large environment it is not uncommon to have Visual Studio solutions that contain multiple different projects. However, when you’re working with these individual projects, you want to be able to quickly debug your specific project. I recently discovered, that when you do this in a solution that contains a Provider Hosted App, switching to and from the Provider Hosted App for debugging purposes, has some very specific gotcha’s…

Let’s create an example to see what I mean. I create a new solution with a provider hosted app (ASP.Net Web Forms Application). After the solution has been created, I add an additional project. This time it’s a console application. The solution structure, still very basic, now looks like this:

SolutionStructure

Let’s say I’m going to work on the Console Application first. So I right click on the project and select ‘Set as startup project’. I hit F5, and the console app launches and everything is working great. The debugger is properly attached, and my breakpoints (if I’d have any) are properly hit.

ConsoleAppDebug

Now the Console application is absolutely perfect, and I want to continue working on my Provider Hosted Application. This is where the trouble begins… Which project do I set as startup project? First let’s see what happens when I set the PHApp project as startup and hit F5. So far so good… Visual Studio installs my app in my SharePoint site, launches IE and reverts us back to the apps default page. However… None of the breakpoints set in my PHAppWeb projects are being hit. Sure, IIS Express launches the web and handles the execution, but not being able to debug through your code makes things quite difficult doesn’t it?!

Breakpoint not hitting

Let’s see what happens when we set the PHAppWeb project as the StartUp project. I hit F5 once again, and great; my symbols have now been loaded! But wait… nothing else happens. Your default browser is not starting, and there is no way for us to reach the code unless we want to manually browse to the apps’ start page. That’s no good either!

So, what other choice do we have? The answer is in the solution properties. Right click on the solution and select ‘Properties’. In the ‘Startup project’ tab, you have the option to select multiple startup projects at once. So let’s select that option, and specify the PHAppWeb first with a ‘Start’ action, and the PHApp second, also with the Start action configured. The end result should look like this:

StartupProjects

Now when we hit F5, the PHAppWeb is launched, symbols are loaded, and then the app is installed to SharePoint. Once that is done, the browser will start up and asks you to trust the app and then redirects to the apps’ start page. Exactly the way we want it to! Unfortunately, you’ll have to manually change this every time you set a different StartUp project.

So, in short, if for whatever reason your Provider Hosted debugging experience is a bit buggy, make sure to check the Solution Properties and check if both the AppWeb and the App project are configured with a ‘Start’ action. Gotcha!

Easily retrieve Yammer Access token for demo purposes

In this blog post, I’ll show you how to easily retrieve a Yammer access token to use for demo purposes. Please note, the method showed here is purely meant as that; for demo purposes. In an actual production scenario, you can follow the steps found at https://developer.yammer.com/v1.0/docs/authentication-1 . If you’re just quickly looking for the access token, to demo the cool stuff you can do with the Yammer API, then this blog post is for you.

Create a new Yammer App
In order to do any demo’ing at all, you’ll first need to register a new app. To do so, first go to https://developer.yammer.com/v1.0/docs/yammer-partners and click on ‘Register an App’. You’ll be redirected to a new page that shows all the apps you currently have. On the left side click ‘Register new app’. The following screen should appear:

Yammer1

You can fill in any values you like, but for the Redirection URL please fill in https://localhost. This will be what allows us to easily retrieve our access token.

After your app has been created, it is important to note that if you want to do any Javascript requests with your app, you should also white list the domain your app is using in the settings. To do so, after the app has been created, click on ‘Basic info’ on the left side of the screen:

Yammer2

Underneath the heading ‘Installation Information’ you have a field called ‘Javascript origins’ which is the field where you want to add your custom domain that you are using for those javascript calls. If you do not specify your domain here, your app will get blocked from performing any javascript calls. This is done for security reasons, so not everyone can ‘fake’ being your app from any domain out there.

Retrieving the Access Token for a particular demo user
Now that we have our app registered at Yammer, we can actually retrieve the access token. This process is as simple as performing a GET request in the browser. We use the following structure:

https://www.yammer.com/dialog/oauth?client_id=%5B:client_id%5D&redirect_uri=%5B:redirect_uri%5D

For the client ID, specify your app’s client ID that you just created. You can find that by clicking on the name of your app in the left menu on yammer. For the redirect URL we can use the value specified as ‘Expected redirect’. Your final URL would be something like

https://www.yammer.com/dialog/oauth?client_id=7SDwM0l5KG0EHm8Ejp2HLx&redirect_uri=https://localhost.

If you’ve done everything properly, Yammer should now ask for your user credentials. The access token given will be based off of these credentials. Fill in your credentials and you’ll be redirected to your Expected Redirect URL. Although this will not actually work, since your localhost is not configured to do anything with this information yet. You will however be able to retrieve the code that is required for the next and final step. In the address bar, take note of the code given. For the last step in this process, create a URL as structured below:

https://www.yammer.com/oauth2/access_token.json?client_id=%5BclientId%5D&client_secret=%5BclientSecret%5D&code=

You already know where to find the values for clientId and clientSecret, and you’ve just found the code. Now go to this address in the browser and you’ll be able to download a json object. This object contains the actual access token. You can find it by opening the json file in your prefered development program and looking for the keyword ‘Token’. The value after the : will be the value you want. You can then use that Bearer access token in your custom application to perform Yammer API calls. And since the access token actually does not expire for quite some time, you’ll good to go! Happy coding!

iOS scrolling issues in a SharePoint Online Public Website

SharePoint online allows you to create a Public Facing Website (atleast, until March 2017 for existing customers, read more). Although the public website has some limitations, there are still some pretty cool things you can do with it.

For a customer of ours, I have implemented a responsive design using the Public Facing Website. I used the default corev15 styling css, and added an additional css file to do all the custom styling. When testing the website on different devices though, I came across a strange bug. For all iOS devices, the vertical scrolling was ‘groggy’, or simply very very slow. This resulted in a poor user experience, especially for pages which had quite a bit of content.

Turns out there is a pretty easy fix for this. In the corev15 the basic scrolling is implemented in two different css statements, as shown below:

body
{
overflow:hidden;
}

and

#s4-workspace
{
overflow:auto;
}

If you want to fix this annoying bug, you can simply add ‘-webkit-overflow-scrolling: touch;’ to the #s4-workspace css rule. Tada, scrolling is now as you would expect it to be in the first place. Gotcha!

If you’re not using a custom masterpage or CSS file, you can simply add the CSS markup by clicking on ‘Site’ and ‘Edit style sheet’ from the ribbon. Add the markup below:

#s4-workspace
{
-webkit-overflow-scrolling: touch;
}

That’s it, you’re all set! Happy coding.

Inconveniently working with App Permissions

Whenever you create an app, you have to think carefully about the permissions that the app needs on order to function correctly. Some apps can execute actions based on the permissions that the user has, but for other apps the app needs its own set of permissions. That is the case for example when you are working with remote event receivers in a provider hosted app.

When it relates to content creation, an app can request four different sets of permissions:

  • Read; (which corresponds to the default Reader permission level)
  • Write; (which corresponds to the default Contributer permission level)
  • Manage; (which corresponds to the default Designer permission level)
  • FullControl; (which corresponds to the default Full Control permission level)

These four different sets of permissions can be requested in one of four scopes:

  • List;
  • Web;
  • Site Collection;
  • Tenant;

It is important to note that whenever your app requests the ‘FullControl’ permission set, that particular app cannot be uploaded to the SharePoint Store.

During the development of your app you might have to switch the permission level that your app requires. On MSDN Microsoft explains how to change the apps permissions after it has already been installed. You can do so by navigating to http://<yoursharepointsite>/_layouts/15/AppInv.aspx , enter the app’s ID and update the XML related to the permission request. However, recently I found out that this in fact does not work in all cases. In one of our apps we used remote event receivers to create a new subweb, which requires the FullControl permission level. Currently we only had the Manage permission, so we had to change that. Updating the app and then re-trusting it unfortunately still resulted in a ‘You do not have the required permissions for performing that action’ error.

Following the above mentioned steps for updating our apps permissions also did not work. In fact, the only way to get the new permissions working properly, was to delete the entire app and then install it again. After that our new subwebs were properly created.

In short; there appears to be a bug in updating the permission request when developing your app and deploying it in an Office 365 developer site. In order to get the new permission request functioning properly, remove the app from your site and reinstall it. Gotcha!