CHUVASH.eu

CHunky Universe of Vigourous Astonishing SHarepoint :)

Tag Archives: office365

My first Office Add-In

Yesterday I participated in the Hackathon at European SharePoin Conference in Stockholm. The main goal was to learn more about Office Add-Ins. I wanted to create a very very simple app to learn the basics. Here in this post I’ll provide some links and describe the steps needed to start developing your Office Add-Ins.

The Add-in I created is an Outlook Add-In, it is called “Joke Inserter” and with it you can insert a random Chuck Norris joke. It is just for fun, but it demonstrated how an add-in can be installed, made available in “New E-mail” and interact with the e-mail you are writing.

All the code is on github. The random jokes come from The Internet Chuck Norris Database. As I said, the jokes were just for fun, this add-in is of course, not a business app. During the hackathon I got help from Pretish Abraham, Jeremy Thake and …

This is the result:

joke-inserter-video

Prerequisites

  • Any OS, I happened to have Windows 🙂
  • git, nodejs, npm (they should be in the $env:PATH)

Install following npm packages globally:

npm install -g tsd yeoman generator-office gulp

Creating the Add-In

Now with the yeoman support it is very easy:

Create a folder and scaffold an app:

mkdir joke-inserter
cd-joke-inserter
yo office

After that update the manifest file: Icon Url, and Support Url

Start the application on localhost:

gulp serve-static

Go to your Outook.office365.com. Click on Manage Apps and add the manifest file from your solution. I uploaded this app on azure: https://kultar.azurewebsites.net/appcompose/home/home.html. You can try this app by installing the manifest file in you Outlook client.

Now when one is done with that simple fun add-in, it is very easy to go ahead and create real add-ins that provide value to you and your colleages.

joke-inserter-video

 

Resources:

 

Onpremifying SharePoint apps

onpremify-001

We want to make an app available in SharePoint OnPrem, we want to onpremify it. Rethink SharePoint apps and provisioning SharePoint artifacts.

It has been a while since I updated my blog – Chuvash.eu. I had my vacation, I visited the sunny and green Chuvashia. Now I am back and I am looking forward to an awesome SharePoint Autumn. One of the first things I had to deal with in this SharePoint Autumn was Onpremifying of a SharePoint Online App. We have an app that has gained popularity and we want to make it available for SharePoint OnPrem. There is no such word Onpremify (yet?), I know, it is a Swenglish happy word making (onpremifiera), but I like the word “onpremify” a lot.

There is still uncertainty around the purpose of SharePoint apps. One app type, though, has been used a lot in our company: an app that provisions SharePoint Artifacts – that creates SharePoint Applications. What I mean by SharePoint Applications can be read in my blog post:

The successful app type creates SharePoint Applications – by provisioning needed SharePoint artifacts (Fields, Content Types, Lists, Page Layouts, Styles, Scripts, Web Parts, Pages…). Often it is a one time job: When the SharePoint application is provisioined, it is finished.

onpremify-002

When you’re about to onpremify such an app, you have three main choices:

  1. Install app in OnPrem. Requires the App Infrastructure in place and a separate build of the app (15.0.0.0 version)
  2. Make a parallel version of the app using a farm solution (not good at all)
  3. Invoke the provisioning code from a console app (I recommend this one)

The choice 1 might seem obvious, but not all companies have a functioning app infrastructure (a dedicated server for Provider Hosted apps, S2S Trust and Governance around it). The choice 2 splits your app into two variants and makes it hard to maintain.

On the other hand, the choice 3 might seem crazy, when you hear it for the first time. A Console App? But give it time, think about it. The idea comes from the awesome SharePoint Provisioning Library SPMeta2, where the Model (SharePoint Artifacts) and Executing are separated. Your model for Fields, Content Types, and Lists and so on, is an agnostic code based definition that can be used for SSOM and CSOM, for SharePoint 2013, SharePoint Online, SharePoint 2016 and SharePoint 2010. SPMeta2 eliminates the need for XML and wsp packages.

So my recommended approach for onpremifying SharePoint apps where the main goal is to provision SharePoint Applications is to move the provisioning code into a separate VS Project. The SharePoint App Project (mainly AppManifest.xml) remains the same, The App Web Project is made to a “stupid” interface that invokes the Provisioning Library. We also create a new interface – a Console App. You can replace the console app with a Windows Application, a Web Application, PowerShell Script, An admin page in Central Admin – whatever suits you. The Console app can be used not only in OnPrem, but also in SharePoint Online.

SPMeta2 vs. PnP vs. Own Framework

Every developer with Self-Respect uses a framework for provisioning SharePoint artifacts. It might be some own utilities or preferably public framework, because you don’t want to repeat yourself, especially in SharePoint. When SPMeta2 and PnP are available it is not smart to reinvent the wheel. I usually recommend to use one of them. I personally prefer SPMeta2 because… mainly because it is more complete and consistent. Read more about SPMeta2 vs. PnP comparison.

Export any web part from a SharePoint page

The blog post below describes the technical details about how Web Parts can be exported using a hidden tool in OOB SharePoint, though this requires manual assembling of a special url. If you are just interested in a solution for an easy Web Part Export function, just proceed directly to my new blog post where you can download my tool that you can add to your web browser.

 

[youtube https://www.youtube.com/watch?v=wL9y9E1aJy0]

Technical background

Almost all web parts can be exported from a SharePoint page. An exported web part  can be imported on another page or it can be used as a source in a module to provision pages. An exception is the XsltListViewWebPart, there you cannot enable exporting. I have used Glyn Clough’s method before which has worked although it is a complicated process. Now I have found another way for exporting any web part (even ListViewWebPart and XsltListViewWebPart) present on a page. A method that only involves a web browser.

How to export any web part

First, we need to find out the webpartid. To do so inspect the html markup with the web browser dev tools of your choice.

export-webpart-001

In SharePoint there is a hidden application page that exports web parts: /_vti_bin/exportwp.aspx. This page takes two query parameters:

  • pageurl. The absolute url of the page where the web part resides that you want to export
  • guidstring. The guid that is called webpartid in the markup on the page

So, suppose, you have this site: https://intranet.contoso.com and a web part (id: 0c3adfe9-8f5d-4432-918a-42410e4e324d) on a page https://intranet.contoso.com/Pages/default.aspx

This will be the resulting URL to export your webpart:

https://intranet.contoso.com/_vti_bin/exportwp.aspx?pageurl=https://intranet.contoso.com/Pages/default.aspx&guidstring=0c3adfe9-8f5d-4432-918a-42410e4e324d

Paste it into the web browser address bar and you’ll download an xml file with your web part definition. This method works in SharePoint 2010 and SharePoint 2013 and even in SharePoint Online (Office 365).

Sources

Natalia Tsymbalenko. Get the list view web part convertable

Maurice Prather. Exporting a ListViewWebPart

SharePoint StackExchange

I am glad to update my answer on SharePoint StackExchange site and provide a much easier way of exporting any web part from SharePoint.

Bookmarklet (update 2015-10-21)

Finally there is a bookmarklet for making Web Part Export a lot easier. See my new blog post for more details:

AppLoader Concept for SharePoint apps

In this post I want to share an unusual, nevertheless interesting conceptual idea of loading content from SharePoint 2013 apps on many pages. The original awesome concept was proposed and developed by my colleague Martin Villysson at Bool.

The problem we are trying to solve

SharePoint apps are great to extend functionality in SharePoint and integrate other systems (full page apps available through Site Contents), they also provide tools to enrich the default SharePoint experience by App Parts (Client Web Parts) and Custom Actions (additional menus).

One of the biggest shortcomings of that model is the need to add app parts on all pages where it is needed. Let’s say, we want to have some app parts present on every single page in our whole SharePoint tenancy, to provide a consistent look and feel (e.g. navigation, notifications). Traditionally, on premises, we have added user controls in our customized master page. In SharePoint Online that is impossible. The complicated workaround is to add those client web parts (app parts) on every page, be it manually or by automating it (powershell or app). It will require updating all pages. Nevertheless, it will not work on Out-of-the-box application pages (pages from layouts folder). It becomes even more unacceptable when you realize that your app must be added as an app instance on every single site (SPWeb) in your tenancy. 

Towards a solution

Allright, we don’t want to have thousands of app instances of the same app. What we can do is to use Tenant scoped apps (Tenant Apps). Then we’ll need only one app instance. But wait, app parts from a tenant app are only available in the parent site (HostWeb), meaning – App Catalog. That’s not good. So what Martin found in the SharePoint internal javascript code is using of _layouts/15/TenantAppInfo.ashx, a http handler that provides information about all Tenant Apps and their custom actions.That’s how the idea of the AppLoader was born.

Vesa Juvonen

After we had created a working Proof-of-Concept of the AppLoader concept, I met Vesa Juvonen at the SharePoint Conference in Las Vegas and introduced this idea to him (although I didn’t call it AppLoader). He liked it although he pointed out that this TenantAppInfo.ashx is an internal utility only in SharePoint and it is not supported by Microsoft. That’s correct. There is even almost no information about it on the Internet. But I got a feeling of Microsoft that they are willing to hear feedback and improve the product. Vesa encouraged me also to blog about it. So now I am telling about this idea. I hope to hear feedback about it. Unfortunately I cannot share the source code of the working Proof-of-Concept solution.

AppLoader Concept in colors

The AppLoader Concept is quite simple. Look at this picture:

apploader-concept

 

The solution contains a custom Master Page (blue) that references a javascript file called apploader.js (red). This file initializes the whole process. Tenant Apps (green) are the apps that an administrator has installed in the App Catalog and deployed to the whole tenancy. TenantAppInfo.ashx (black) is a handy but officially unsupported OOB service utility (http handler) that returns a json-formatted list of all Tenant Apps (green). AppLoader (red) receives the app list (black) and renders it on the Page (blue) inside new iframes (red). The page a user has navigated to can be any page (wiki page, publishing page, application page, really any page).

To summarize the colors in the diagram: red is our javascript code, green are all the tenant apps and their content, black is the utility and its output, blue is a sharepoint page and its underlying component (master page).

The steps in the AppLoader process:

  1. Make an ajax request to TenantAppInfo.ashx using XHR (XmlHttpRequest)
  2. Receive the app list
  3. For every app information, render app part, or inject css and javascript references. 

 

Reading what to render on the page

You probably have already have tried to navigate to _layouts/15/TenanAppInfo.ashx while reading this post, I know you are curious. Then you’ve noticed that there is no information about app parts. So you may ask: how do we know what app parts to render and where to put them in the page, and how do we know what resources (css and javascript files) to inject on the page. Well there is no information about it in the apps list. But if you have an app with custom actions you’ll see that they are listed in this json-formatted list we receive from the TenantAppInfo.ashx. So the solution is the brilliant idea of my colleage Martin to define custom actions in the app. CustomActions contain a ActionUrl. The ActionUrl points to the url to render (app part page) or to inject (javascript or css file). The apploader.js reads the ActionUrl in the Custom Actions for every app information and takes action upon it (rendering an app part iframe, or injecting a javascript or css file). That’s it. 

Usage and Limitations

This bright idea takes advantages from a huge SharePoint API (that contains a lot of good but not supported parts) to make using of apps in Client Application Model solutions more pragmatic and still provide a consistent design and behavior. By consistent design I mean same parts like additional navigation, notifications etc in the whole Intranet. The AppLoader renders and injects whatever you have rolled out to your whole tenancy (Tenant Scoped Apps) and that on every page (!). It also improves the perceived performance of the page load, because it renders app parts (iframes) after the main page has been loaded preventing freezing of the page. 

There are of course some limitations in the AppLoader Concept. Today we cannot rely on the TenanAppInfo.ashx API (because it is not supported and future updates can break solutions). We have to define our own custom actions in the apps. That means we can only use our own apps, it will hardly work with the apps installed from the Office Store. On the other hand, your customer will not want to have generic apps from the Office Store to be a part of every page on their intranet.

What about the SharePoint app domain?

This is an open question about the domains for SharePoint apps. On Technet: Configure an environment for apps for SharePoint (SharePoint 2013) we can read the following:

You must configure a new name in Domain Name Services (DNS) to host the apps. To help improve security, the domain name should not be a subdomain of the domain that hosts the SharePoint sites. For example, if the SharePoint sites are at Contoso.com, consider ContosoApps.com instead of App.Contoso.com as the domain name.

Does it apply to SharePoint Online? Well, apparently not 🙂 So why should we do it on premises?

subdomain

As we all know, sharepoint.com is used for our Office 365 tenancies and for apps.

The CDN concept in SharePoint

How many instances of jquery are there in your SharePoint farm?

 Get-SPWebApplication http://dev `
  | Select -Expand Sites `
  | Select -Expand AllWebs `
  | Select -Expand Lists `
  | Select -Expand Items `
  | ? { $_.Url -match "jquery.*.js" } `
  | select Name, Url

Have you more than two (jquery and jquery-ui), then you have too much. You can save much place and performance by using Content Delivery Network (CDN) links for the resources like javascript, css, fonts and icons. Consider those Content Delivery Networks:

CDN for custom resources

But can we benefit from this CDN concept for our custom resources? I think so, if your farm has ten thousands of site collections, and you deploy javascript files, css files in the Style Library, it would be great to eliminate resource duplicates. So my thougt is to deploy resources to one place. It could be:

  • An external web application static.contoso.com like many web applications do
  • A dedicated site collection for resources cdn.contoso.com with Anonymous access
The CDN concept in Office 365

Have you noticed that Office 365 uses cdn links for almost all SharePoint javascript files that traditionaly were referenced from the _layouts folder

cdn-001

With this I want to raise a question. What do you think about the CDN concept within SharePoint? Have you used it? Have you plans to have it?

SharePoint Apps: “Provider Hosted First” Approach

Recently I had an exciting mail conversation with Thomas Deutsch. He came up with an idea how to fasten the development of apps. This smart approach is called “Provider Hosted First”. See Thomas’ original blog post. Here are some highlights:

What you actually do is a local website which runs in grunt server:

localhost:9000

Then a SharePoint-hosted app is created with an SPAppIframe that refers to that local app site. Genious!!!

Some key features of this approach:

  • This local app contains a livereload script. Your sharepoint app is updated every time you save your css, js, html file in your IDE
  • Grunt minifies, bundles your assets
  • Grunt runs your tests automatically when your content is modified
  • The SharePoint app can be on Premises, on Office 365, wherever you want it.

Video

See the video how it looks like to develop using this approach

See the video how it looks like to develop using this approach

Develop for SharePoint on Windows 8

Do you like Windows 8 user expirience, as me? Well than you want to try developing sharepoint solutions in Windows 8. Here I will show what I found out.

Environment

I installed Windows 8 Release Preview as a VMWare machine. Then I installed Visual Studio 2012 RC. Then I followed the steps for installing SharePoint on Windows 8 which are more or less the same as for Windows 7 client install. But then I encountered an error I haven’t found solution for yet. In my standalone sharepoint installation there were some permission problems:

Failed to create the configuration database.

An exception of type System.Data.SqlClient.SqlException was thrown. Additional information:
Cannot find the object ‘proc_putDeletedSiteMap’,because it does not exist or you do not have permission.

Plan B

In a meanwhile I tried to just to use Andrew Connell’s trick: to copy sharepoint dlls to GAC and the 14 folder. To extract the sharepoint dlls, you can use a script from sharepoint tech blog:

mkdir c:\temp
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Portal")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Policy")
[appdomain]::currentdomain.getassemblies() |
where {($_.fullname -match "Microsoft.Office") -OR ($_.fullname –match "Microsoft.SharePoint")} |
copy-item -path {$_.location} -destination c:\temp\ -verbose

Then copy the dlls to gac with gacutil.

This plan B works, but with one shortcoming: you can’t debug, neither you can create new sharepoint solutions, you’ll get an error: “SharePoint Not Installed”.

What you have to do is to open an existing sharepoint solution. And you can build it and publish. After I opened an existing solution in Windows 8, I could create new solutions as well :).

The most awesome feature in Visual Studio 2012 is the ability to publish your projects:

Вула Чăвашла

VulaCV - Чăвашла вулаттаракан сайт

Discovering SharePoint

And going crazy doing it

Bram de Jager talking Office 365, SharePoint and Azure

My view and thoughts on Productivity and more.

My programming life

and everything in between

SharePoint Development Lab by @avishnyakov

It is a good place to share some SharePoint stories and development practices.

SharePoint Dragons

Nikander & Margriet on SharePoint

RealActivity - Real-time and trustworthy

Blog site of founder, RealActivty - Paul J. Swider

Mai Omar Desouki - Avid SharePointer

Egyptian & Vodafoner - Senior SharePoint Consultant

Cameron Dwyer | Office 365, SharePoint, Outlook, OnePlace Solutions

Office 365, SharePoint, OnePlace Solutions & Life's Other Little Wonders

paul.tavares

Me and My doings!

Share SharePoint Points!!

By Mohit Vashishtha

Jimmy Janlén "Den Scrummande Konsulten"

Erfarenheter, synpunkter och raljerande om Scrum från Jimmy Janlén

SPJoel

SharePoint for everyone

SharePointRyan

Ryan Dennis is a SharePoint Solution Architect with a passion for SharePoint and PowerShell

SharePoint 2020

The Vision for a Future of Clarity

Aharoni in Unicode, ya mama

Treacle tarts for great justice

... And All That JS

JavaScript, Web Apps and SharePoint