How to update a SharePoint Framework project to Drop 1.2 (Extensions RC0)

[Update September 2nd, 2017]

I’ve updated the steps to remove the node_modules forlder, as that seems to fix some of the build libraries.

--

With the release of SharePoint Framework Extensions RC, SPFx has moved to Drop 1.2. If you want to update an existing project these are the steps you need to take.

Update the generator to Drop 1.2

npm install -g @microsoft/generator-sharepoint 

Enter your SPFx project folder and open package.json, where you need to update the version numbers for the following packages:

dependencies

"@microsoft/sp-core-library": "~1.2.0",
"@microsoft/sp-webpart-base": "~1.2.0",
"@types/react": "15.0.38",


devDependencies

"@microsoft/sp-build-web": "~1.2.0",
"@microsoft/sp-module-interfaces": "~1.2.0",
"@microsoft/sp-webpart-workbench": "~1.2.0"

If you have other @microsoft packages, set them to 1.2 as well, or if it’s @microsoft/sp-client-base, you can remove it.

Next up, remove your node_modules folder with your favorite command before running:

npm install
gulp --upgrade

And you should be all set!

NOTE! You may run into other breaking API changes you have to deal with.

NOTE 2! If you are using Office UI Fabric with react, Drop 1.2 takes a dependency on v4.32.0, and not on v2.34.2. If you have an explicit link to v2.x, then you have to upgrade in order for the build to work. See this issue for information about Office UI Fabric React which I raised with Drop 1.2 https://github.com/SharePoint/sp-dev-docs/issues/827

Maybe the most useful Azure function ever! – Introducing a proper Swagger definition generator

This post relates to Azure functions written in C#, hosted as a Function App – and maybe the title is a tiny bit clickbaity ;)

I’m in a project where writing small Azure functions to accomplish pieces of functionality is a very good fit, and the tasks will be connected in a workflow – Microsoft Flow or Logic Apps. With the latest update for Visual Studio 2017, creating an Azure Function project and publish the function to Azure is super easy.

The tricky part comes when you want to consume those functions somewhere else using a Swagger definition file to describe your API.

The people over at the Azure team has been kind enough to add functionality to automatically generate a Swagger definition. The problem is that the output of this preview functionality is, to put it in nice terms, the equivalent to a table of contents, where the book was left out.



There are some blog posts out there on how you can write that book to get a working definition, but manual work when you have already defined the functions pretty well in code is not my cup of tea.

Digression

If an Azure function project had been a WebAPI or similar, you could have installed Swashbuckle, and you would have gotten a nice Swagger definition just like that. The fact that Azure functions are compiled to a class DLL, and that Swashbuckle does not work against a DLL in any easy fashion, I saw two options. A shadow API with Swashbuckle, or roll my own.

I started out with the first option where I created a shadow WebAPI project, copying all my Azure Function signatures, and then manually copying out parts to generate a proper Swagger definition. But I quickly discovered this was still too much manual work for my taste.

Option two it is – generate the mofo myself!

That left me with option two, write my own Swagger generator. The Swagger spec itself is not too complicated, and as Azure uses v2, that’s what I set to use as well. I’m no stranger to reflection on .Net DLL’s, having worked with SharePoint for many years, as well as writing other types of generators, so that’s what I did.

I created an Azure function in my project which at run time reflects on the current assembly, finds all methods marked to be Azure functions, then inspect their ins and outs, and construct a full fledged Swagger definition.

It’s not complicated, but a bit tedious to support all the scenarios I wanted to support. I wanted to support input via the path, as query parameters and JSON objects in the body – which is the most useful one in my opinion. It took me one working day, 7.5h to have this up and ready to go, with ~400 lines of code. Imagine if the Azure team could have spend the same? But then again, I wouldn’t have this blog post :)

SharePoint Query Tool moves to the PnP Tools repository and v2.7 released

As Codeplex is shutting down the repository for the SharePoint Query Tool has been moved over to the PnP Tools repo. I’m very happy about this move, and if you want to make changes or additions, feel free to make a PR.

Get v2.7 (link on the page)

The code was actually moved over in late May, but today I give you v2.7. There is one major new function, and one function removal.

Firstly, GQL support has been removed as Microsoft is removing support of this preview API.

Secondly I’ve had some requests about the login for SharePoint Online being tricky with cookies and multiple tenants, and lately those with single sign-on on their machines were force logged into their SSO domain.

In the connection dialog you can now choose SharePoint Online Management, which piggy backs on the way the SharePoint Online Management Shell authenticated.

This should give you an easy way to switch between tenants and accounts by re-clicking the sign-in button.

A workaround to support switching logins between tenants in Windows apps or PowerShell – Piggyback the Microsoft SharePoint Online Management Shell ADAL application

If you write Windows Applications or PowerShell scripts to connect to multiple tenants you have probably experienced the “That didn’t work” dialog where the web based login tries to log you in with some other tenant credential as cookies are persisted from an Internet Explorer or Edge session. This was a typical problem for the SharePoint Query Tool, and I managed to add some funky code to ensure cookies were ignored when the login window popped up.

However, recently I’ve had a couple of issues where people have domain/aad joined pc’s with single sign-on to Office 365. With this in place cookies doesn’t matter. The login dialog will always try to log you in with your current user when using IE/Edge, which happens to be the browser control available when programming in Windows. Hence, using the query tool was hard to use in these scenarios.

At the moment the Query Tool uses web browser login and a FedAuth cookie for authorization. The obvious workaround is to use an ADAL app and a Bearer token instead. This is quite easy to implement, but having people register a custom ADAL app per tenant to support this login flow seemed too cumbersome. And for those who know me, I always try to find an easy way out, and a clever work around came to mind.

Dealing with package errors when building SharePoint Framework solutions

I’ve been working on a web part for a customer lately and was going to bundle it up and install it at the customers tenant. When I ran gulp --ship to prepare the bundle I got the following error:

[14:47:51] Error - [webpack] 'dist':
cylinder-configurator.bundle.js from UglifyJs
Unexpected token: name (finish) [cylinder-configurator.bundle.js:5976,6]

Something broke when the build process was running uglify-js. I opened by bundle in the temp\deploy folder and looked at line 5676. This was a reference to MathLab which was included my the npm package pica which I’m using in this project.

I figured as much as to solve my issue I needed to break pica out of the main build process, but how?

Again, my good friend Waldek pointed me in the right direction and he has actually written about this before, and the needed documentation can be found in the official SPFx documentation Add an external library to your SharePoint client-side web part.

Enable external sharing on Communication sites

By default when you create a Communication site, external sharing has been disabled. As Communication sites are not listed in the site collection admin UI you need to turn to code or PowerShell to fix this.

I’m using PnP PowerShell where you enable external sharing using the following code:

# Connect to admin site
Connect-PnPOnline https://contoso-admin.sharepoint.com

# Enable external sharing. Possible values are:
# ExistingExternalUserSharingOnly
# ExternalUserAndGuestSharing
# ExternalUserSharingOnly
# Disabled

Set-PnPTenantSite -Url https://contoso.sharepoint.com/teams/Communication201 -Sharing ExternalUserSharingOnly

Similar code for SPO commandlets would be, where we also allow anonymous sharing of documents:

# Connect to admin site
Connect-SPOService -Url https://contoso-admin.sharepoint.com

Set-SPOSite -Identity https://contoso.sharepoint.com/teams/Communication201 -SharingCapability ExternalUserAndGuestSharing

I chose to use ExternalUserSharingOnly as you cannot share the full site anonymously, only documents, and sharing documents anonymously from a Communication site might not be the most obvious scenario.

Note: You have to ensure that the sharing settings on your tenant allows the sharing capability you are setting for the site.

The next step is to invite your external users. If you try to share using the Share site button in the UI, this won’t allow adding an external user (per writing this post).


The Share button is disabled for external users.


Instead navigate to Site permissions and hit the advanced permissions settings link. Or tack /_layouts/15/user.aspx at the end of the URL of your site. This is the old SharePoint permission page where you can hit the Grant Permissions button, and fill in your external user. Be sure to check off the email invitation and pick which access level the user should have. I’m adding my external user as a visitor in this example.



When clicking the site link in the invitation e-mail my external user is now added to the site and can browse around. Notice that as an external user you get blue/black suite bar, as the tenant theme won’t show for external users.



Happy sharing!

How to list all Communication sites in your tenant

The unique identifier for a Communication site is the web template used, and the name of the template for Communication sites is SITEPAGEPUBLISHING.

With this piece of information there are a couple of options you can use to find all the sites.

The first is to iterate over all site collections, and filter on the web template property, the other is to use search.

To list all sites you can use the SPO Management Shell, CSOM tenant API, or hope my PR at PnP PowerShell get’s accepted (https://github.com/SharePoint/PnP-PowerShell/pull/998)

Basically the CSOM code looks something like this:

SPOSitePropertiesEnumerableFilter filter = new SPOSitePropertiesEnumerableFilter()
{
    IncludePersonalSite = PersonalSiteFilter.UseServerDefault,
    StartIndex = null,
    IncludeDetail = true,
    Template = "SITEPAGEPUBLISHING#0",
    Filter = null
};

var list = Tenant.GetSitePropertiesFromSharePointByFilters(filter);

Using the SharePoint Online Management Shell do this:

Connect-SPOService https://contoso-admin.sharepoint.com
Get-SPOSite -Template SITEPAGEPUBLISHING#0 -Limit ALL

With the PR accepted you would be able to use PnP Posh with the following command to list all Communication sites much like the management shell:

Connect-PnPOnline https://contoso-admin.sharepoint.com
Get-PnPTenantSite -WebTemplate SITEPAGEPUBLISHING#0

If you want to use search, you can use the Submit-PnPSearchQuery commandlet.

Submit-PnPSearchQuery -Query "webtemplate=SITEPAGEPUBLISHING" -All -RelevantResults

This approach is of course available for other templates as well. Happy iteration!

What is Microsoft 365?

I’ve read numerous posts after the release of Microsoft 365 at Inspire stating that Office 365 now has a new name. This is not the case.

Microsoft 365 is a combination of:

• Office 365
• Windows 10
• Enterprise Mobility + Security

aka, a bundled offering, and is primarily target for businesses up to 300 users. The idea is that you per user per month pay for subscribing to Windows 10 as an operating system, Office 365 products and device and security management.

If you scroll far enough down on https://www.microsoft.com/en-us/microsoft-365/business you see a comparison of Office 365 Business premium vs. Microsoft 365 Business.

And if you scroll down on https://www.microsoft.com/en-us/microsoft-365/enterprise you see the Enterprise offerings in E3 and E5 SKU’s (but with no pricing).

Global deployment of SharePoint Framework Parts and Extensions is now live!

With version 1.1.3 of the SharePoint Framework yeoman generator it is now possible to specify for a SPFx solution to be tenant wide available. This means that when you upload the solution to your tenant you have the ability to let the extension or web part be made available to all site collections in your tenant.

Using Windows, in a console with administrative privileges you can get the latest version by re-installing the generator with: npm i @microsoft/generator-sharepoint -g

For web parts this means that the web part is available for use on all pages in all sites. For extensions, you still need to perform the part of registration using CSOM or REST per site collection/site/list where the extension is to be registered, but you don’t have to first add the extension to the site. For auto-provisioning scenarios this is huge!

Read the documentation over at https://dev.office.com/sharepoint/docs/spfx/tenant-scoped-deployment

YouTube video

Questions

Q: How can I make my existing SPFx solution be available tenant wide?

A: Update @microsoft/sp-build-core-tasks to v1.1.1.

> npm i @microsoft/sp-build-core-tasks

Open up config/package-solution.json and add "skipFeatureDeployment": true to the solution element.

{
  "solution": {
    "name": "tenant-deploy-client-side-solution",
    "id": "dd4feca4-6f7e-47f1-a0e2-97de8890e3fa",
    "version": "1.0.0.0",
    "skipFeatureDeployment": true
  },
  "paths": {
    "zippedPackage": "solution/tenant-deploy-true.sppkg"
  }
}

Q: Do I need this feature for web parts?

A: If you create web parts which should be globally available, this is the feature for you. If you create custom applications, then stick to the old way of adding it where needed.

Q: Do I need this feature for extensions?

A: Definately! This feature was made for SPFx extensions. You could for example create an extension with a company footer which you want available on all sites in your tenant. You would still need to figure out the best way to register the extension on the sites – but that is something we can deal with!

How to reduce the bundle size when using Office UI Fabric with React in SharePoint Framework

Yesterday I wrote about how the build process has changed for SharePoint framework web parts using the Office UI Fabric components and Fabric Core CSS. Previously you could take a dependency on whatever version was deployed in your tenant and your web parts were quite small in size as Office UI Fabric was pre-loaded from a Microsoft CDN. This has now changed, where the build process will bundle in the Office UI Fabric components to ensure your part works regardless of what Microsoft updates.

The caveat of this is that your web part grows in size (considerably), and if you have more than one web part on the page, all using Office UI Fabric components – well, load times do go up as code is loaded multiple times.

There’s a perfectly good reason for this change. Microsoft might decide to upgrade components they use, which could break your solutions. This means that you as a developer must control what version of Office UI Fabric you are using.

More: Read about it at https://dev.office.com/sharepoint/docs/spfx/web-parts/guidance/office-ui-fabric-integration

One solution to get the bundle size down again and at the same time have full control is to put Office UI Fabric components and CSS on a CDN, and having all parts re-use this. Fortunately I have done this for you :)

SPFx bundle size when using Office UI Fabric React components

I was making some updates to a SharePoint Framework web part which utilized the React Office UI Fabric components today. Previously when I built the web part, the bundle .js size was about 10kb. When I built it today the size was suddenly close to 600kb.

The reason turns out to be how the build process works in SPFx. It now bundles Office UI Fabric components instead of re-using whatever SPO has installed. It actually makes sense to de-couple the dependency and ensuring your web parts won’t break if Microsoft decides to upgrade Office UI Fabric on their side.

Ideally I would like to externalize Office UI Fabric to a version which I control. Reading up on How to use the Office UI Fabric React in a Safe Way in Your Solution we’re told to put an explicit dependency in your project to Office UI Fabric, so you have control over the version. The biggest issue right now might be that can you really expect an average developer to hit that doc page? Hopefully the version will be added in packages.json in a future version of the SPFx generator. (See the end of this post for how to add the reference.)