Get Started with Apps for SharePoint 2013!
•Als PPTX, PDF herunterladen•
0 gefällt mir•11,259 views
Presentation given by Danny Jessee at the Capital Area .NET SharePoint Special Interest Group on January 17, 2013
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (12)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Get Started with Apps for SharePoint 2013!
Ähnlich wie Get Started with Apps for SharePoint 2013! (20)
Mehr von Danny Jessee
Mehr von Danny Jessee (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Get Started with Apps for SharePoint 2013!
- 23. • • • • • • • • •
- 39. http://dev.office.com http://cloudshare.com http://blog.cloudshare.com/author/danny http://sdrv.ms/XbohjT
- 46. http://odata.org
Hinweis der Redaktion
- All versions of SharePoint have always been a platform for applications
- Farm solutions are not subject to any monitoring or resource allocation throttling. Poorly written code in a farm solution can jeopardize the performance and stability of the server farm as a whole. To prevent these issues, you should carefully review your farm solution code to identify issues that could cause memory leaks or process timeouts. For example, developers often encounter the following pitfalls that can adversely affect performance:The developer could fail to dispose of SPSite and SPWeb objects after use.The developer could iterate through items in large lists instead of executing queries on the lists.The developer could use for or foreach loops to aggregate data, instead of using SPSiteDataQuery or other recommended data aggregation methods.The developer could use recursive method calls to iterate through information in every site within a site collection.The developer could fail to close connections to external systems after use.The developer could fail to trap timeouts when connecting to external systems.The developer could overuse, or improperly use, session state.
- Let’s take a step back…
- There is an important aspect of the SharePoint app model that deals with uninstalling an app and ensuring that all the app-specific storage is deleted automatically. In particular, a SharePoint host will automatically delete the app web for an app whenever the app is uninstalled. This provides a set of cleanup semantics for SharePoint apps that is entirely missing from the development model for SharePoint solutions. When an app is uninstalled, it doesn’t leave a bunch of junk behind. I wish I could same the same thing for all the SharePoint solutions I have created over the years.
- Many new alternatives to the server-side object model. Clients could not directly access client.svcIntellisense from Microsoft.SharePoint.ClientCUI Namespace - CUI.js, SP.UI.Rte.jsCUI.Controls Namespace - CUI.jsCUI.Page Namespace - CUI.js, SP.UI.Rte.jsSP Namespace - SP.Core.js, SP.js, SP.Ribbon.js, SP.Runtime.jsSP.ListOperation Namespace - SP.Core.jsSP.Ribbon Namespace - SP.Ribbon.jsSP.Ribbon.PageState Namespace - SP.Ribbon.jsSP.UI Namespace - SP.Core.js, SP.js, SP.UI.Dialog.jsSP.Utilities Namespace - SP.Core.js, SP.js, SP.Exp.jsSP.WebParts Namespace - SP.jsSP.Workflow Namespace - SP.js
- Foundation – no significant changes apart from REST supportServer – new APIs added (Microsoft.SharePoint.Client.DocumentManagement, Microsoft.SharePoint.Client.Publishing, Microsoft.SharePoint.Client.Taxonomy, Microsoft.SharePoint.Client.UserProfiles)REST – based on SOAP, much simpler/easier to usePaging may not be supported/working from /_api endpointUpdates using REST require Form Digest (SharePoint pages contain control with form digest; can be acquired through /_vti_bin/sites.asmx)
- An app package is a ZIP file with a .app extension. If you create a new SharePoint app project named MyFirstApp, the project will generate a app package named MyFirstApp.appas its output. Note that the file format for creating an app package is based on the Open Package Convention (OPC) format. This is the same file format that Microsoft Office begin to use with the release of Office 2007 for creating Word documents (docx) and Excel workbooks (xlsx).So now you understand one of the key points of the SharePoint app model. Custom code never runs inside SharePoint. It runs somewhere else. You have the option of writing both client-side code and server-side code. A SharePoint-hosted app is easier to create, implement and deploy. However, it does not provide the opportunity to add server-side code. A cloud-hosted app will yield more power because you can write as much server-side code as you would like using a managed language such as C# and your code is not limited by all those frustrating limitations and issues created by running code inside the SharePoint environment.
- You can do a lot more with the app manifest, such as use different authentication schemes (also known as app principals, declare what permissions the app needs to run, and other tasks. Also, do you notice strings like “{StandardTokens}” in the app manifest shown above? These are tokens that are replaced at build/run time. These tokens allow you to reference your app and also pass context (for example, the SharePoint language, where the app is installed, and so on). To learn more about what you can do with the app manifest and tokens, see App for SharePoint manifest file.Within apps, SharePoint 2013 decouples server-side code from the server, enabling you to run server-side code from outside SharePoint, in the cloud. You can host server-side code in autohosted and provider-hosted apps. It is the presence of an inner solution package inside the app package file that tells the SharePoint host whether it needs to create an app web during installation. If the app package does not contains an inner solution package, the SharePoint host installs the app without creating an app web. The inner solution package for a SharePoint app should contain a single Web-scoped feature. The SharePoint host activates this feature automatically on the app web immediately after the app web is created. This features is what makes it possible to add declarative elements such as pages and lists as the app is installed. However, the inner solution package for a SharePoint app cannot contain any type of DLL or any .NET code whatsoever.
- Hybrid pattern is possible
- Can have multiple shapes within an app
- If you look back at the AppManifest.xml file shown earlier, you notice that it did not include a hard-coded path to the app’s start page. Instead, the URL to the start page contains a dynamic token named ~appWebUrl. This dynamic token is replaced by the SharePoint host when the app is installed. This makes sense because the URL that will be used to access the app web is not even known until the SharePoint host creates a new domain for the app during installation. After creating the app web, the SharePoint host can then use it to create the URL to the start page.So why doesn’t the SharePoint host serve up pages from the app web using the same domain as the host site? At first, the reasons why the SharePoint host serves up the pages from an app web in their own isolated domain might not be obvious. There are two primary reasons why the SharePoint app model does this. Both of these reasons are related to security and the management and enforcement of permissions granted to an app.The first reason for isolating an app web in its own private domain has to do with preventing direct JavaScript calls from pages in the app web back to the host site. This security protection of the SharePoint app model builds on the browser’s built-in support for prohibiting cross-site scripting (XSS). Since JavaScript code running on pages from an app web pages originates from a different domain, this code cannot directly call back to the host site. More specifically, calls from JavaScript running on app web pages do not run with the same identity nor the same permissions as JavaScript code behind pages in the host site.
- Azure ACS is used as an authorization server(Automatically set up with O365)On-premises, a trust to ACS must be configuredCan be avoided with S2S (high trust) – S2S can assert any user’s identity
- You do not HAVE to have a local dev VM to do app development!
- Some hybrid approaches possible (full-trust proxy)
- From managed code, HttpWebRequest/HttpWebResponserequest.Credentials = CredentialCache.DefaultCredentials;request.ContentType = “application/atom+xml”;request.Accept = “application/atom+xml”;request.Headers[“X-RequestDigest”] = FormDigest;JavaScript with jQuery: $(“#__REQUESTDIGEST”).val()LINQ to XMLXDocument doc = XDocument.Load(response.GetResponseStream());doc.Descendants(namespace + “Title”).First().Value;
- JavaScript: _spPageContextInfo.webAbsoluteUrl + “/_api/web/?$select=Title”;jQuery: $.getJSON(requestUri, null, onDataReturned)jsRender.js as a templating engine for templating results
- The second reason for creating an isolated domain for each app web has to do with page processing and JavaScript callbacks that occur on the server. The SharePoint host creates a new unique domain for each app that it installs. This in turn allows the SharePoint host to determine exactly which app is calling when it sees an incoming request from a page in an app web. They key point is that the SharePoint host is able to authenticate the SharePoint app and examine its permissions any time a call originates from the domain of an app web. As you remember from earlier, an app has default permissions to access its app web but it has no default permissions anywhere else in the SharePoint host. The ability for the SharePoint host to authenticate calls from apps using the isolated app web domain is essential to enforcing this default permissions scheme.This is huge. The idea that SharePoint 2013 introduces new authentication support for apps in addition to its existing authentication support for users is a significant part of the SharePoint app model. In effect. this is what allows SharePoint apps to become a first class security principals. This alone gives the new SharePoint app model many advantages over SharePoint solutions development. In this post I am going to keep the discussion authentication with SharePoint apps brief. I am going to create another blog post later in this series that will go into much greater detail about how, when and why SharePoint apps are authenticated.
- User-only – if no permissions are requested by the app (Created by user)User+app – default if permissions are requested by the app (Created by SharePointApp1 on behalf of user)App-only – must be explicitly requested in the manifest