Amit Gandhi's Blog https://docs.microsoft.com/archive/blogs/amigan/feed.xml This blog will display posts about SharePoint 2013 Wed, 17 Apr 2019 03:47:13 GMT en-US hourly 1 Part 4 - SharePoint-Hosted App https://docs.microsoft.com/archive/blogs/amigan/part-4-sharepoint-hosted-app Tue, 15 Jan 2013 23:16:00 GMT https://blogs.msdn.microsoft.com/amigan/2013/01/15/part-4-sharepoint-hosted-app/ This post is in continuation to my previous posts about SharePoint 2013 App Model. You can see the previous posts here:

 

SharePoint-Hosted App

 

A SharePoint hosted app is one where the business logic is implemented within the client (browser). These types of apps do not have any external dependencies nor do they use any server-side code but they can utilize some SharePoint artifacts such as lists and libraries for storing content. SharePoint will host the app in a special isolated subweb (SPWeb) that has all the same capabilities of a regular SPWeb. All logic & code runs in the client. Apps could make external service calls from the client using some provided tools.

 

Understanding the App URL

 

Consider an app installed in the SPWeb https://intranet.mydomain.com .The app URL will be (for example): https://app-bf473b5225nn0f.apps.mydomain.com/SharePointAppWebTitle

AppUID and AppName are highlighted in bold in the above Url. App UID is a unique 14 character identifier that is given to each app installation in that particular customer /tenancy. This makes the domain unique for each app. App Name is the name of the SPWeb folder under which the app is installed. Currently this is a GUID and is automatically generated. In the case of a hosted deployment, the root domain (mydomain.com in the above scenario) is always SharePoint.com.

 

Explore App Solution Structure

 

Once you have set up your VM for SharePoint 2013, open Visual Studio 2012 and create a new project using template "Apps for SharePoint 2013" for creating apps for SharePoint.

 

 

Provide the name of the SharePoint app, the SharePoint which you will use for debugging and select the option where you would like to host SharePoint app. For this post, we will select "SharePoint-hosted" as shown in screenshot below:

 

 

The following screenshot shows a new project created from "Apps for SharePoint 2013" template in Project Explorer and illustrates its structure.

 

 

App Manifest

Any app for SharePoint (be it SharePoint hosted or cloud hosted) includes an appmanifest.xml file. The appmanifest.xml defines the high level app's attributes like the title, internal name, icon path and version of the app. The most important item specified in the app manifest is the URL of the start page, which is the page that opens when the app is started.

If app needs to access any SharePoint resources outside the app web, then requests for permission is also defined in the app manifest via Permissions tab. You can also define a list of the prerequisites in app manifest, if any, that must be available to the app in order for the app to be installed. For example, certain features may need to be installed and activated, and certain services may need to be licensed and installed. You can right click on app manifest and select "view code" to view the details:

Notice that with start page, there is a dynamic token prefix as ~appWebUrl, and SharePoint will replace this dynamic token at runtime depending on which site the app is installed. App Principal is needed for identification, for authentication and authorization purposes, of the app. For SharePoint hosted app, App Principal will always be internal as SharePoint is going to track the identity of the app internally and does not need any outside help.

Default.aspx (i.e. Default Start Page)

Once you open the default start page of the SharePoint hosted app (i.e. default.aspx), you'll find that Visual Studio automatically adds two content place holders  in it i.e. PlaceHolderAdditionalPageHead and PlaceHolderMain. Inside of PlaceHolderAdditionalPageHead, Visual Studio automatically adds the jQuery libraries and link to app.css and app.js. You can directly start adding styles for default.aspx in app.css and can add scripts in app.js.

A SharePoint hosted app can have many pages, it's just the template provides you with the default start page. You can add as many pages or script files or CSS.  

Hello World SharePoint Hosted App

Without making any code modifications in above project, if you right click on the project, and select "deploy", it will deploy the app to SharePoint site. You can also change the site URL to deploy the app to your O365 tenant site collection. You can go
to site content and clicking on the app "My First SharePoint App" will open up the default page of the app as shown below.

 

The hello world app "My First SharePoint App" deployed above displays the name of the logged in user. This name is fetched using the SharePoint 2013 Client Side Object Model (CSOM) via JavaScript. CSOM can be used using JavaScript or by using code behind files. Since in SharePoint-hosted app, any server side code is not allowed, thus SharePoint content can be accessed using the following ways:

  1. Using client side object model via JavaScript
  2. Calling REST based APIs via JavaScript

In the above hello world app, the logged in user's name is fetched using the following CSOM code in App.js:

 

 

Debugging SharePoint-Hosted App via F5

 

Once you're done with the development of your app, you can directly hit the F5 key, its going to package your source files to install the SharePoint app on the target test site. Visual Studio then starts a session of IE, and direct you to the start page of the page, Also, note when you close the session of IE, Visual Studio starts the uninstallation and retraction process of app from the target SharePoint site. Please note that when you hit F5, Visual studio attaches the JavaScript debugger as well to IE, because of which you can directly debug the JavaScript files inside Visual Studio. However, if you would like to use JavaScript debugger built into IE (i.e. IE Developer Tools), just use Ctrl F5 instead of F5.

 

]]> Part 3 - Apps Hosting and Branding https://docs.microsoft.com/archive/blogs/amigan/part-3-apps-hosting-and-branding Tue, 11 Dec 2012 18:17:00 GMT https://blogs.msdn.microsoft.com/amigan/2012/12/11/part-3-apps-hosting-and-branding/ This post is in continuation to my previous posts about SharePoint 2013 App Model. You can see the previous posts here:

Before we get into the details of building useful apps using SharePoint 2013, we need to go over the app model architectural overview.

Apps for SharePoint hosting options

The SharePoint 2013 app model provides two broad approaches to hosting your apps for SharePoint:

  • SharePoint-hosted
  • Cloud-hosted

Within the cloud-hosted approach there are two important subcategories:

  • Provider-hosted
  • Auto-hosted

 These are not exclusive categories: An app for SharePoint can have both SharePoint-hosted and remotely hosted components. Each approach has key features you should consider when deciding how to host your apps.

SharePoint Hosted App

 

Figure 1: SharePoint-hosted apps

SharePoint hosted app runs within the context of SharePoint, but there is no server side code. Any kind of logic is going to run in the client side using JavaScript. You can leverage some of the SharePoint artefacts like lists, document libraries, pages without code behind and out of the box web parts. SharePoint-hosted apps for SharePoint are installed on a SharePoint 2013 website, called the host web, and that have their resources hosted on an isolated subsite of a host web, called the app web.

Cloud-hosted apps

 

Figure 2: Cloud-hosted apps

In cloud hosted apps, the logic resides outside of SharePoint. The logic can reside either on IIS server OR Windows Azure OR some other cloud solution and it is going to talk to SharePoint using client side object model (CSOM) or REST services and have to be granted permission to SharePoint using OAuth.

Within this category there are two types of apps:

  • Provider hosted

Provider-hosted apps for SharePoint includes components that are deployed and hosted outside of the SharePoint farm, usually by the developer. The provider-hosted app for SharePoint interacts with a SharePoint 2013 site but also uses resources and services that reside on the remote site.This approach enables you to use any hosting service you want, but it places the responsibility for creating the installation, upgrade, and uninstallation logic of the remote components on the developer.

  • Auto-hosted

Apps that include a Windows Azure Web Site, and possibly also a SQL Azure database, that are automatically installed when the app is installed. The Windows Azure web site and optional SQL Azure database can be included in app package, such that when you provision the app, it automatically creates Windows Azure web site and optional SQL Azure database in Azure. If you are using auto hosting for your app, each installation of the app provisions its own Windows Azure web site. The Windows Azure web sites infrastructure handles load balancing, multi-tenancy, and other important maintenance tasks for you.

 

Note: Cloud-hosted app is the most preferred hosting model for almost all apps. You can get full power of the web, you can choose your infrastructure and technology, you can run in IIS or in Windows Azure or even on other non-Microsoft infrastructure. Whereas SharePoint hosted apps is good for smaller apps with limited resource storage.

 

App Shape and Branding

 When you build SharePoint apps, one of the design decision is how apps are going to look like and be presented to the user. To design the user experience of the app, you need to understand the following:

  • App Shape
  • Branding

 Apps for SharePoint fit seamlessly into the SharePoint website where they are installed.

 

Figure 3: App Shapes option

As shown in figure above, the apps can have three possible type of shapes:

Immersive: An app for SharePoint provides a fully immersive experience and optionally can extend some of the existing UI, such as in menus, or by providing embeddable parts for other pages. Immersive apps will take entire browser experience.

 App Part: App parts surface an IFrame element that contains content from your app. Imagine these apps as the ones which add something like a web part to the SharePoint site e.g. weather monitor app. An App Part is nothing but a type of Web Part that is represented by the ClientWebPart class. This kind of Web Part is essentially a wrapper for an IFrame that would host a page of the app.

 Extension App: You need to use extension app when you create new actions for documents or list items. Ribbon or context menu extensions make your app available on list items, documents, or anywhere else a ribbon is shown. An app can add links like ribbon, custom actions or ECB menu to the host web. When user will click on the link, user will be redirected to the app web.

 All apps have a default page which might take the full page. Apps show custom action or app part in the host web. The app might take the full page by redirecting user from host web url to app web. For example, the host web url is https://www.hostweb.com and an app is installed in the host web which adds a custom action. When user clicks the custom action, the user will be navigated to a new url (say, https://www.appweb.com). So the app takes the full page (so it’s called Immersive Full page). However user will not notice the url changes as the new app site will have the same UI look and feel. The idea of having the app web to have similar look and feel like host web is achieve thorough a new concept in SharePoint 2013 – called Chrome Control. This is a javaScript based object that allows custom app to consume and import the css and stying of the hosting parent appweb. Also the chrome control create a SharePoint 2013 ribbon bar in the app site, so that user can navigate back to the hot web.

 

 Figure 4: Chrome control in a web page

 Apps Branding

Microsoft has recommended design process as well as basic guidelines for developing quality user experiences for apps. Refer to this link UX design for apps in SharePoint 2013 to understand the recommended UX design process for apps for SharePoint.

 Developers are going to primarily use three different types of branding:

App Template: The app template is the default branding option in Visual Studio when you create an app web and pages within that web. The app template can be used only for SharePoint-hosted ASPX pages. The template includes the app.master master page.

 Chrome Control: This is a JavaScript based object that allows custom app to consume and import the css and stying of the hosting parent appweb. If you’re not building SharePoint-hosted ASPX pages, but you still want your app to fit in naturally with the host site that it is used from, the chrome control is the right choice.

Custom Branding: If, instead of aligning to the host site’s theme and fitting into the SharePoint site where your app is installed, you want to use your own brand inside your app, you will have to build your chrome from scratch. However, you should still have a "back to site" link in the upper-left corner of the page that redirects the user back to the site where the app is installed.

In the next post, I will mention about details around SharePoint Hosted apps.

]]> Part 2 - Introduction to SharePoint 2013 App Model https://docs.microsoft.com/archive/blogs/amigan/part-2-introduction-to-sharepoint-2013-app-model Mon, 10 Dec 2012 03:29:00 GMT https://blogs.msdn.microsoft.com/amigan/2012/12/10/part-2-introduction-to-sharepoint-2013-app-model/ This post is in continuation to my previous post "Part 1 - Why Apps are needed for SharePoint 2013", wherein I had explained that there have been some issues with fully trusted SharePoint 2010 applications, they can destabilize the whole farm and they are difficult to migrate to newer versions of SharePoint.

The new SharePoint 2013 application model not only addresses concerns around solution packages, custom code on server, but also introduce a lot of new capabilities.

Key points about SharePoint Apps

  • Everything is in a SharePoint site is now an app
    • Yes, everything in a SharePoint site is an app. This includes lists and libraries. Though the actual implementation of lists and libraries has not changed. They are referred in user interface as apps, to create a more unified experience. For e.g. if you would like to create a new document library, you need to create an app and pick document library and then name it.

 

  • No custom code on SharePoint server
    • As per the new SharePoint 2013 App Model, SharePoint apps do not live in SharePoint, rather they execute within a browser client, or in non-SharePoint server such as IIS server or in cloud server such as Windows Azure. SharePoint apps are granted permissions to get back into SharePoint sites via OAuth and communicate with SharePoint via REST/CSOM.

 

  • Easier to upgrade to future versions of SharePoint
    • This is possible because the apps are running against client side service 

 

  • Reduces the ramp-up for those developing apps
    • Developers building SharePoint apps don't need to be familiar with SharePoint specific things  e.g. object model. If they want to work with data from SharePoint, then they have the option to leverage some of the standard services or CSOM.

 

  • Leverage hosting platform features in new apps
    • If you develop an app which is going to run in another hosted platform (like Windows Azure OR non-SharePoint server such as IIS server OR any other infrastructure) but it's going to use SharePoint UI such that end user feels that he is in SharePoint and the app looks like SharePoint. However, since the app is running in another environment like Windows Azure, then you can use the capabilities of hosting platform i.e. Windows Azure, which you normally cannot do in SharePoint.
    • This enables taking SharePoint apps to different levels - further than what can be done with farm/ sandboxed solutions

 

  • Provides additional approach for development
    • The app model does not replace the solution based approach of development/deployment, it is an additional option. Thus, in SharePoint 2013 for development, we can use either of the following approach:
      • SharePoint Apps  
      • Fully trusted solutions
      • Sandboxed solutions

 

Which development approach to use - SharePoint Apps, Farm Solution or Sandboxed solution?

It is important to understand the differences between the three development models which we have i.e. SharePoint Apps, fully trusted solutions and sandboxed solutions.

 

 

Farm Solutions

Sandboxed Solutions

SharePoint Apps

When to develop?

 

Use farm solutions only when you cannot achieve the same via apps

SharePoint sandboxed solutions are deprecated in SharePoint 2013 in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013.

Recommended approach - Develop an app whenever you can

Use Server-Side SharePoint API

Fully trusted solutions allow developers to write code that can use server side API.

They are also called as partially trusted solutions. Server side code runs under a strict CAS policy and provides limited capabilities.

Server side code running of SharePoint server is strictly prohibited in apps. Any server side code that needs to be used within your app needs to run and hosted outside SharePoint on a different server such as cloud or a different IIS server.

Use Client-Side SharePoint API

Yes

Yes

Yes, and the capabilities provided by client side SharePoint APIs in SharePoint 2013 is much more as compared to previous versions.

On-Premise Deployment Friendly

Custom code in these solutions is deployed to the bin directory or to GAC. Code can be secured using CAS policies but is typically runs inside full trust. 

These type of solutions are deployed by farm administrator.

They can be uploaded and deployed by site collection admins and owners. It has limited set of APIs available from server side SharePoint.

In addition server side code cannot make request to externally hosted web services or databases. Though developers can use client side solutions to call external services and even make cross domain calls.

Yes

Hosted Deployment and Cloud support

Farm trusted solutions cannot be deployed in hosted SharePoint deployment. They are only available in on-premise deployment.

Sandboxed solutions are the only type of solution that can be deployed to hosted SharePoint installations.

Yes. In addition, developers will be able to publish their apps to a public marketplace for download & purchases. In addition organizations will be able to create a private corporate marketplace where the apps would be available to the organization.

Install/Upgrade/Uninstall

With these type of solutions, developers should manually code each of type of activity logic when solutions are upgraded or uninstalled

Similar to farm solutions, developers need to write code to write logic when solutions are upgraded or uninstalled.

Microsoft has made a lot of investments in install/upgrade and uninstallations of apps to make it end user friendly experience and to ease out developer challenges.

Server Outages

When error occurs in these, they can affect the service app pool and in worst case can even host server outages. 

These are the most unrestricted type of solutions that can be deployed in SharePoint 2013.

Runs on the server farm, but in a dedicated isolated process. Thus, they are considered safe and cannot cause server outage.

Apps run isolated from a SharePoint farm and cannot cause SharePoint server outages.

Authentication Options

The components in the solution can, and usually do, run in full trust.

The components in the solution run in partial trust.

 

 

 

Before you can call SharePoint APIs from your app, you need to authenticate to SharePoint. Which authentication mechanism you use depends upon where the code of your app is running.  

  • Inside SharePoint: You have to use HTML and JavaScript, and authentication is already taken care for you.  
  • In the cloud:   
    • Use client-side code along with the cross-domain library
    • Use server-side code along with OAuth
    • REST APIs

  

What can be developed?

Almost all components can be deployed as Farm solution.

Refer to this link to understand in detail what can be implemented in Sandboxed Solutions in SharePoint.

Some of the most common things a sandboxed solution cannot do are: 

  • Connect to resources that are not located on the local farm
  • Access a database
  • Call unmanaged code
  • Write to disk   
  • Access resources in a different site collection

 

What Can be Created as Apps -  

  • Custom Web Parts (remote pages that contain custom Web Parts)    
  • Event receivers and Feature receivers(remote event receivers)
  • Custom field (column) types
  • Custom web services built on the SharePoint Service Application Framework Application pages  

What cannot be created as Apps -  

  • Custom site definitions
  • Custom themes
  • Custom action groups and custom action hiding User controls (.ascx files)
  • Delegate controls

 

In my next post, I will discuss Apps Hosting and Branding - wherein I will mention about app hosting options, different types of apps, entry points, user experience and branding.

]]> Part 1 - Why Apps are needed for SharePoint 2013 https://docs.microsoft.com/archive/blogs/amigan/part-1-why-apps-are-needed-for-sharepoint-2013 Mon, 10 Dec 2012 00:28:00 GMT https://blogs.msdn.microsoft.com/amigan/2012/12/10/part-1-why-apps-are-needed-for-sharepoint-2013/ Hello everyone, I am planning to write a series of articles on the SharePoint 2013 App Model. This article is the first one in the series - where I will start with a bit of theory first, why APPS are needed?

 

Well, all previous versions of versions of SharePoint had many concepts and artifacts (like pages, lists, libraries, sites, web parts, master pages etc.), which make it difficult for new people to learn SharePoint. Sometimes end users get confused by various number of elements which are visible in ribbon and navigation. The reason of these various concepts and artefacts is because SharePoint can be used for loads of purposes and that’s why the SharePoint web application experience is very different as compared to other dedicated web applications. With the new version of SharePoint 2013, Microsoft wants to make it easier for users to learn new concepts.

 

Why Apps are needed?

 

As per the new web technologies, latest gadgets, smartphones etc. which are coming up nowadays, it is found out that end users primarily understand Sites, People, Apps and Themes. The new SharePoint 2013 experience is centered across these 4 primary concepts - (Sites, People, Apps and Themes), such that it is easier for the end users to get familiarize with SharePoint 2013.

 

For end users, these concepts are described as:

 

Sites: A storage space with content (such as pages, documents and list items).

People: Site will allow users to access the content and collaborate with each other within same space.

Apps: Apps are going to provide functionality to make site valuable. It can be anything like web part, document library etc.

Themes: Used to improve the look and feel of the site.

 

In SharePoint 2010, we already have 3 out of the 4 concepts i.e. Sites, People and Themes. But there is nothing like apps, which provides a specific functionality and end users are fairly comfortable in using it similar to other platforms like phones and tablets. This is the gap which needs to be filled.

 

SharePoint 2010 Application Challenges

 

There have been some issues with fully trusted SharePoint 2010 applications, they can destabilize the whole farm and they are difficult to migrate to newer versions of SharePoint. SharePoint farm solutions require deployment of solution packages. A lot of custom code is there on SharePoint2010 server, if it is not written well, it can cause SharePoint outages.

 

The initial attempt to solve this problem was by using sandboxed solutions in SharePoint 2010, but it has its own limitations and there are limited number of customers actually using it.

Developers who are creating these apps must have good knowledge of SharePoint API.

 

SharePoint 2013 App Model

 

The new SharePoint 2013 application model not only addresses concerns around solution packages, custom code on server, but also introduce a lot of new capabilities.

 

SharePoint 2013 apps do not live in SharePoint rather they execute within the browser client or in a non-SharePoint server such as IIS or Windows Azure. Apps are granted permissions to SharePoint via OAuth, and communicate with SharePoint via REST APIs or via CSOM (Client side object model).

 

Developers will be able to publish their apps to a public marketplace for download & purchases. In addition organizations will be able to create a private corporate marketplace where the apps would be available to the organization.

 

Hopefully this post would have given you an idea why Apps are needed for SharePoint 2013. I will be publishing a lot of content on the SharePoint 2013 app model in next few posts. Apps introduce a breaking, now philosophical change to how people extend SharePoint. Upgrading, installing and uninstalling SharePoint applications was not a great story in previous versions of SharePoint. SharePoint 2013 changes this with robust infrastructure to support upgrade, installation & uninstallation of apps. The upgrade story for apps in SharePoint 2013 also ensures that if an app upgrade fails, it is rolled back so the site isn’t left in a bad state. One significant change in SharePoint is that everything is now treated as an app. This includes existing lists and libraries. I understand you would be curious with loads of questions running around in your mind about Apps - I am sure most of these questions would get answered in the upcoming posts.

 

---------------------------------------

 

In the next post - I will mention about the "Introduction to SharePoint 2013 App Model".

]]>