Contents tagged with SharePoint 2016

  • The SharePoint Framework (SPFx) is here!

    Tags: SharePoint, SharePoint 2016, SharePoint Online, SharePoint Framework

    Today is the day many of us have been waiting for since the big SharePoint event at May the 4th. The highly anticipated SharePoint Framework (SPFx) is here and announced in at the SharePointFest, in this blog post, as well as in the new Github repo for SharePoint. Personally I've been waiting for this even longer after being involved by the product team to give early feedback and also attending the first top secret DevKitchen "hackathons" where we could try out very early bits.

    That feeling when you use the SharePoint Framework the first time...

    The first release of many to come…

    This is the initial public preview release, officially christened the SharePoint Framework Developer Preview, is a beta, maybe an alpha, of the SharePoint Framework. This is by no means something you should use or deploy to production. Things will change! Period. There are several known issues at the moment and some of them will likely incur breaking changes. But please, build stuff and give feedback to the product team, use the Issues feature in the Github repo.

    This initial release focuses on client-side Web Parts which can, once released, be used in you classic SharePoint sites and pages as well as in the new modern user experience that is slowly being rolled out throughout the suite. As some of you know, I've spent quite some time on Web Parts and written a book on the topic, so this is something that gets me really excited.

    How and where to get it!

    All you need to do to get your hands on it is to follow the instructions on the Github repo. I'm sure we'll see tens and hundreds of blog posts on how to do it, but I recommend you to follow the one in the repo to start with. And, if you can't follow it, create an issue, make a pull request with an update - make sure we get good official documentation! Heck, I'm pretty sure I will write a couple of posts on the topic, but I will also continue to provide feedback on the framework and the documentation.

    You will find samples, documentation and all you need in a set of brand new repositories in Github, also under a brand user/organization called…SharePoint (yes, no more generic Office dev, SharePoint is back!).

    Need to know more?

    Keep the conversation going on Twitter, SharePoint Stack Overflow, the new Office 365 Community network and other social media, and do use the #SPFx hashtag. I'll try to hang around at the SharePoint Stack Overflow as much as possible, since that is the best platform of the above mentioned ones.

    I've previously written a Q&A on SharePoint Framework and will continue to update that post with details and changes in the current preview release.

    Now, go, build something awesome!

  • Why my Pages, with a custom Page Layout, was not indexed in SharePoint Online!

    Tags: SharePoint Online, SharePoint 2016

    Here's one of these real life stories that caused some headache for quite some time but was in the end very easy to resolve. I'll write it down and hopefully some of the search engines pick it up and help some other poor soul out there.

    Background

    We have a solution that uses publishing pages to manage news articles and information pages in SharePoint Online. These articles and pages have a custom page layout with a custom content type, so they look decent and have proper metadata. They are all deployed using the PnP PowerShell cmdlets.

    Creation of pages worked flawless and the rendered nicely. They page layouts use jQuery, some Office Fabric components (including those nasty jQuery scripts for that).

    So far so good!

    The Problem

    We wanted to roll up this News articles through a custom Web Part based on a search criteria, and also show some of that metadata, such as News category, rollup image and more. But the pages was not indexed. First thought was that well, indexing in SharePoint Online usually takes everything from a couple of minutes to a couple of days, so just wait. Then summer vacation came - I'm not complaining - and when i got back we had index. Ok, good. But then I started adding some custom managed properties to the rollup feature and was waiting for it to pick up the changes. I clicked re-index the libraries, I clicked re-index the site, added new pages and articles, I might even sacrificed the cutest little kitten you can imagine - but nothing. The pages and articles was just not picked up by the crawler. So I started to smell something fishy.

    Is there something wrong with my SPO tenant? No, same issue across multiple tenants!
    Can it be the page layout? No, it renders perfectly in all browsers!
    Can it be the PnP PowerShell cmdlets? No, the same issue if I uploaded page layouts manually!

    Old man yells at cloud

    Troubleshooting

    First of all I added the CrawlTime managed property to see when stuff was actually crawled and that there was nothing wrong with the crawler. I could see how this managed property was populated on other stuff than the pages. So there is obviously something wrong with our pages and not SPO.

    Time to get my troubleshooting gloves on and I brought out my checklist for this. Since I can't check trace logs (ULS) in SharePoint Online all I could do was to inspect the crawl logs. And now I could see in plan text that my news articles could not be crawled:

    "6074070",
    "https://contoso.sharepoint.com/news/Pages/xyz.aspx",
    755",
    "Item Error",
    "The SharePoint item being crawled returned an error when attempting to download the item.
      ( SearchID = F2A4A5E4-AAAA-AAAA-B034-10C593EF6CCE )",
    "8/4/2016 7:07 AM",
    "https://contoso.sharepoint.com/",
    "Intranet",
    

    So, the crawler can obviously not download my page! I also noticed the following cryptic error message on the site and library levels:

    "755",
    "Container Error",
    "The SharePoint item being crawled returned an error when attempting to download the item. 
      ( Unknown Error The surrogate pair (0xD8DA, 0x272) is invalid. 
      A high surrogate character (0xD800 - 0xDBFF) must always be paired with a low surrogate 
      character (0xDC00 - 0xDFFF).; SearchID = 00D32C87-7CD9-4350-AFF4-BBF38B8EB712 )",

    Hmm, some Unicode errors?

    I was out of options and I could not do an IISRESET (Rule #3) - so I called a friend (Rule #4), Doc Hodgkinson. He was almost as clueless as I but asked my to test it on a normal SharePoint 2016 on-premises installation (born in the cloud you know) and see if I could replicate the issue and also then have the option to check for more detailed crawl and trace logs.

    And so I did. I ran the installer on a clean SharePoint 2016 install, started creating a page using our custom page layout and BOOM! The browser just went white!!! Nothing! It rendered fine in SharePoint Online (cloud-born innovation!)

    The solution

    Quickly I opened up the trace logs and reloaded the page and found this in the logs:

    SharePoint Foundation	General	ahi1s	Medium	
    Cannot find requested file: 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\layouts/https://code.jquery.com/jquery-2.1.4.min.js'
    SharePoint Foundation	Upgrade	aq775	Unexpected	
    CannotMakeBrowserCacheSafeLayoutsUrl ArgumentException: 15/0/1033/https://code.jquery.com/jquery-2.1.4.min.js
    
    

    Aha! The Page Layout contains a ScriptLink control that points to that CDN location.

    <SharePoint:ScriptLink 
      id="jquery" 
      runat="server" 
      Name="https://code.jquery.com/jquery-2.1.4.min.js" 
      Language="text/javascript"></SharePoint:ScriptLink>

    I quickly changed it to a normal script tag and the page rendered fine in the SharePoint 2016 on-premises instance, and I uploaded it to SharePoint Online where it also rendered fine. And…after just a few minutes all my articles was indexed and queryable and I had my Managed Properties. And all was good!

    Summary

    I find this bug very interesting, SharePoint Online obviously accepts full URLs in the ScriptLink property when rendered through a browser but when the crawler sees it something weird happens (also, I wonder why it gets Unicode errors on the site and library as well). Also, the code for ScriptLink is different for SharePoint Online and SharePoint On-Premises (I have NOT tested all CU's though). Also, it's really weird that it some time during the summer actually indexed the pages.

    All in all, actually using an on-premises installation for troubleshooting my SharePoint Online issues was a great idea (big thanks as always Neil) and I'll keep that option as a part of my normal routine from now on.

  • When a GUID is not really unique - I'm looking at you SharePoint!

    Tags: SharePoint 2016, SharePoint Online

    I have long thought that GUIDS are unique, well GUID actually stands for Globally Unique Identifier. And SharePoint is one unique product using GUIDS everywhere. There are 2^128 possible GUIDs to choose from, so there should be no need to reuse GUIDs as long as I'm alive methinks.

    Not even Chuck Norris is allowed to reuse GUIDsSharePoint uses GUIDs to uniquely identify Site Collections and Sites, and more, and this is for instance exposed through the ID property of the SPSite and SPWeb objects. If you take a look at the documentation for SPWeb.ID it actually says: "The globally unique identifier for the website" - which I interpret as this ID is unique, globally! Period.

    When you create a Site Collection in SharePoint you create a new Site Collection (SPSite) and a Root Web (SPWeb). The SPSite will be given a unique identifier, a GUID, and so is the root web as well. Due to the way the API is created you cannot find a web directly using the unique Web Id, you actually need the Site Id. Even so there are multiple applications and services that has only stored the unique Web Id and used that as something unique.

    Given (recent) changes and a new feature called Fast Site Collection Creation, used in SharePoint Online and to some extent in SharePoint 2016, this is no longer true and you can no longer trust in the Web Id being unique. When a site collection is created with a root web, specifically the SharePoint Team Site (STS#0), it is copied from a site master. The Site Collection is given a new GUID, but the GUID for the root web is copied from the site master. So, in SharePoint Online all your Site Collections with a root site of type Team Site will have the same id.

    There is no workaround for this, you cannot change the Id - your only chance is to use a combination of Site Collection Id and the Web Id. That is a dual GUID combo - can't be more unique than that.

    Some of you perhaps already knew this, some not. Hopefully you'll be aware of it now and I wish this would be different and that the Fast Site Collection Creation actually updated the Site identifier property, and since I most likely cannot have that I wish the documentation would be updated with a hint on this.

  • SharePoint Framework - Questions and Answers

    Tags: SharePoint, SharePoint Framework, SharePoint Online, SharePoint 2016

    Me at The Village in San FranciscoAt the Future of SharePoint event in San Francisco on May the 4th Microsoft announced the new and improved customization option and/or development model called the SharePoint Framework. This is a development model that solely focused on client-side development. There's been some confusion going on on Twitter and other social medias and podcasts and I thought I should put together an Q&A post for this.

    This Q&A post is totally unofficial, all of this is currently in private preview and some comes from my (awesome) DevKitchen experiences, so things can and will change and I take no responsibility of any errors in this post or any financial, physical or mental issues caused by reading this.

    I will try to keep this post alive as much as possible and if you have any questions, feel free to post them and we'll try to get answer to them. I also listed some questions, that I do not have an answer to, but are working on to find out…

    [1] Updated 2016-08-17, after initial developer preview release

    Q: Is the SharePoint Framework an new development model

    My point of view here is that this is not a completely new model. The framework might be new, but that is a framework that we all has been longing for for quite some time. Client-side development has been here for years and we all built our own frameworks. Now Microsoft is creating this framework for us, it is standardized and they will also build in native support for this framework in SharePoint. This model leverages techniques we are used to such as CSOM, the SharePoint REST API's, the Microsoft Graph etc and at the same time embraces open source technologies such as node.js, Gulp, Yeoman and more.

    This model does not deprecate anything; if you need to do full trust code you can still do that (on-premises) and build WSP's, if you want to use the App/Add-in model you are free to do that.

    Q: What's not so new in this model?

    A bit of a weird question, but I wanted to highlight that this model actually piggy backs on previous development models and infrastructure in SharePoint - specifically the Add-in model. The packaging and deployment mechanism is using the add-in model. The solutions built using the SharePoint Framework are being packaged as a .spapp file, which is very similar to the .app package created when building a SharePoint add-in, and distributed using the App Catalog.

    Q: Are the Feature framework, Sandbox and the Add-in models dead?

    [Added 2016-05-08] Far from it! The Feature Framework (introduced in SharePoint 2007) is very much alive for on-premises deployment and is in many cases a requirement, with the caveat that it is hard to convert that to a model that works in the cloud. The Sandbox is partly dead, it is, code based Sandboxed solutions are officially deprecated, but there are still a usage for declarative Sandboxed solutions. The Add-in model is also still a very relevant way moving forward; Add-ins offers features that the SharePoint Framework doesn't (such as isolation, elevation of privileges etc).

    Q: Does this replace Add-ins?

    [Added 2016-05-08] No! The SharePoint Framework will NOT replace Add-ins, the will co-exist side by side. There's no need for you to migrate your Add-ins to the SharePoint Framework. That might not even be possible to do - since you want to stay in isolation, you might want to elevate privileges, you might want to do work without user interaction, you might want to use the existing store.

    Q: Do I need to create those weird app keys and secrets and learn all about OAuth?

    [Added 2016-05-08] No, this is not how the SharePoint Framework works You only run this as a user, within the SharePoint page context so you are already authenticated and the SharePoint Framework app are already authorized with the currently logged in users credentials and permissions.

    Q: Can I call the Microsoft Graph using the SharePoint Framework?

    [Added 2016-05-08] No. Not now at least. You don't get any token that you can pass to Microsoft Graph (graph.microsoft.com). The only API's you can access are the same ones as you can using any Script editor web part or script embedding. If you really want to query the Microsoft Graph, you need to create an Azure AD App and sacrifice to the gods that the Azure AD team fixed ADAL/MSAL so that it works with Internet Explorer and trusted/intranet zones, and do it the "old fashioned way".

    Q: Is there any specific requirements on my infrastructure?

    [Added 2016-05-08] No, there is no requirements on app-domains etc. as we have in the Add-in model. You can host your SharePoint Framework solutions on any web server anywhere or in SharePoint itself, without any extra infrastructure components. This also makes it very easy for the SharePoint team to bake this into a future Feature Pack (see below).

    Q: What does the .spapp package look like?

    When you package your client-side solution, an .spapp package is created. This package looks very similar to any other SharePoint Add-in you're creating. This package contains the following major things:

    • An AppManifest - a regular SharePoint add-in AppManifest with the difference that the App element has a IsClientSideSolution="true" attribute
    • One or more features - a normal Feature element file

    For a client-side web part the feature contains a .webpart file that is being added to the Web Part gallery. The client-side web parts actually use a new .NET web part class called Microsoft.SharePoint.WebPartPages.ClientSideWebPart. This web part has one important property that references the client-side web part Id. The elements file for the Feature also contains a new CAML element (ClientSideComponent) that is used to point to the bootstrap JavaScript file that we use. That file can be hosted locally (for development), in SharePoint or any other CDN (for more information see below).

    For client-side applications it is a bit more complex as they are tied to lists. For the sake of uncertainty I leave that description out for now (well I got to have a reason to lure you back here). I know there are discussions on how this should be implemented/executed.
    [1] Note that client-side applications is not part of the initial release.

    Note that none of your actual logic (JavaScript etc) is stored in the .spapp package.

    (Once again this might very well change over time when we get closer to release)

    Q: How do I deploy my solution?

    Deployment is two steps; one is to deploy the JavaScript files and artefacts (see below) and from that you get a bootstrap URL, that URL is used to package the solution (.spapp) which you then deploy to the App Catalog in your SharePoint tenant.

    Q: How do I deploy my JavaScript files and other artefacts?

    You have three options of hosting all your files:

    1. For Development you host your files locally (localhost using the node.js express engine) and can take advantage of automatic reload of your app when you save files etc.
    2. You can deploy to a SharePoint library. A good option if you want full control of the artefacts in your tenant
    3. To a CDN. This is most probably the best solution for ISV's where they centrally can manage all the artefacts.

    Q: How do I update a client-side solution

    This is an answer that some might be scared of. If you only need to update the logic or code in your app you only have to update the source files, you do not have to redeploy the .spapp package. The "only" time you would need to do that is if you change the URL to the location of where you host the bootloader JavaScript file.

    Since the app package and app registration only contains a reference to the bootloader JavaScript file, there is nothing preventing a user, vendor or similar to actually modify that file (and thus giving the app full access to the page/site - see question about isolation below). But, this is exactly the same way we have it with any jQuery or Angular files hosted on a CDN.

    Q: Will the Office Store allow client-side solutions built using the SharePoint Framework.

    Thank you, very good question. I do not have an answer to this right now, but I assume that the team are working hard on this, specifically regarding the topics around updates. To be continued…

    Q: But hey, I'm an ISV and this looks like an Enterprise developer feature only!

    [Added 2016-05-08] Thank you for asking and noting. Yes, I agree that the current initial release is focused on enterprise developers. I know one of the goals with this new framework is also to support the ISV market. I have however no timeline for this.

    Q: What about isolation in my customizations

    The SharePoint Framework runs in the context of your page, and will also have all the privileges of the user of the page. This might sound scary, but it works in the same way as any Script Editor Web Part or Custom Action with JavaScripts. If you truly need isolation in your app you have two options; 1) Go back and use the Add-in model and host your application in an iFrame or 2) build your new client-side application using an iFrame.

    Q: I don't want everyone to be able to see my business logic in JavaScript!

    No problem! Then you just encapsulate your "secret" business logic or algorithms in web services and make sure that those are CORS enabled.

    Q: What client-side frameworks are supported?

    All of them. Well, I haven't tested all of them, but that's the idea. The product team does not want to limit you with what frameworks to use, so go ahead use your preferred ones. Personally I've built client-side solutions with jQuery, Angular 1.x, Angular 2, React and Knockout.
    [1] Microsoft and the Product Team for SharePoint has taken a decision to use React in their solutions. This actually have a big effect on us developers. For instance the new Office UI Fabric version 2 - is React only! So if you want to use the new components offered you either have to use React in your client side solution or reverse engineer Office UI Fabric, since there's no "pure CSS" spec/implementation.

    Q: Do I really need to learn TypeScript?

    Short answer Yes. The tooling right now is built using TypeScript and uses class inheritance etc. It is possible to write using plain JavaScript but that would just be a waste of time and more error prone. And just because of that we'll probably see people doing this. And this makes me bring up the old SharePoint mantra - Just because you can, doesn't mean you should!

    Q: Do I really need to use Visual Studio Code?

    Short answer; absolutely not! You can use whatever tool you want to write the code. However I guess most of the demos and instructions from Microsoft will be based on Visual Studio Code.

    Q: But I really want to use Visual Studio that I'm used to and love so much!

    Yea, I'd love that option to and there's a lot of benefits of using Visual Studio. I know that the product team are aware of this and I'm pretty sure that they are working on it. But see this as an opportunity to learn Visual Studio Code meanwhile…
    [1] Visual Studio is fully supported, together with the use of the Node.js tools for Visual Studio (NTVS). Please use at least version 1.2!

    Q: Do I really need to use Gulp?

    Short answer: Yes. The current tooling is built on Gulp tasks and I recommend you to start with that. But if needed you can configure and modify those tasks. It is also totally possible of building your own package mechanism and code structure that fits your style of coding, if you have the time. (I actually wrote my own package mechanism and gulp tasks from scratch just to understand how it all worked out and to be able to give feedback to the team - so it is possible)

    Q: Does it work on my bestest device ever - my precious Mac?

    [Added 2016-05-08] Yup! Use Visual Studio Code on your Mac, use whatever text editor you like, use it on a Linux box! This is one of the reasons the team choose to use Node.js npm ,gulp and Yeoman as the foundation for the development framework and that is why the go with Visual Studio Code first (instead of the full Visual Studio).

    Q: Do I really need to use Git?

    Short answer: Nope! Git has nothing to do with this, at all. But the code samples and the source for all the tooling will most likely be distributed using Git/Github so if you're interested in contributing you should learn it.

    Q: Is this Open Source?

    [Added 2016-05-08] From my understanding the idea is to have this Open Sourced once we get out of "closed beta". There really is no point in doing it any other way with client side components,.

    Q: What is the Workbench?

    The Workbench is a test rig for client-side solutions which comes in two flavors. One static html version that are used without the context of SharePoint. It is capable of rendering the page canvas and client-side solutions so that you can work with the UX components. If you need live data however you need to create mock data for your domain model. The second flavor of the Workbench is the one running in SharePoint, with that one you have access to the full page context including SharePoint data.

    Q: What about SharePoint 2016 on-premises, will we ever be able to take part of all this?

    Yes, I do believe so. There's nothing in here that actually locks this model to Office 365 and SharePoint Online and at the Future of SharePoint event there was announced that SharePoint 2016 will get "Feature Packs" during 2017. So, yes, this will most likely happen.
    [1] Microsoft is targeting an on-premises release of the SharePoint Framework for the first half of 2017. This will be a part of a feature pack for SharePoint 2016.

    Q: When can I get my hands on this??

    [Added 2016-05-08] It was announced at the Future of SharePoint event that this will roll out starting this summer to first release tenants. My guess is that we will have a first version by the end of this year (2016).
    [1] You can get your hands dirty right now over here:

    Q: Is it SPX or SPFx?

    Over the last two days I've seen the SharePoint Framework been shortened both as SPX and SPFx. I prefer the latter one. How about you?

    Q: What permissions is needed to deploy a SharePoint Framework app?

    [Added 2016-05-10] A really good question. This is an assumption based on the experience so far. You distribute the app/solution to the App Catalog - so you need to have permissions on the App Catalog.

    Q: How does the development life cycle look like?

    [Added 2016-05-10] The development life cycle is one of the things that this SharePoint Framework would like to align with the rest of modern web development. You have multiple options and how you actually do it is up to you. This is how I see it and what works great with the tools:

    1. Build and host your solution locally (node.js Express web engine) using the local Workbench, without any real SharePoint data just using mock objects
    2. Host your solution locally as above, but deploy the solution to the app catalog and then add it to a site so you can test it with real data
    3. Iterate 1 and 2 until you are happy
    4. Pack and deploy your JavaScripts and assets and deploy either to CDN or to SharePoint
    5. Package your solution, now pointing to the CDN location, and upload that to the App Catalog to distribute it to a SharePoint tenant
    6. Repeat 4 and 5 in dev, stage or production
    7. Go back to 1 to build your next version/update

     

    Do you have any more questions? Let me know!

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...