FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 2, column 0: The prefix "atom" generally is associated with the namespace "http://www.w3.org/2005/Atom" [help]
```
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rs ...
```
line 2, column 0: The prefix "sy" generally is associated with the namespace "http://purl.org/rss/1.0/modules/syndication/" [help]
```
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rs ...
```
line 2, column 0: The prefix "dc" generally is associated with the namespace "http://purl.org/dc/elements/1.1/" [help]
```
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rs ...
```
line 2, column 0: The prefix "content" generally is associated with the namespace "http://purl.org/rss/1.0/modules/content/" [help]
```
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rs ...
```
line 2, column 0: The prefix "wfw" generally is associated with the namespace "http://wellformedweb.org/CommentAPI/" [help]
```
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rs ...
```
line 2, column 0: The prefix "slash" generally is associated with the namespace "http://purl.org/rss/1.0/modules/slash/" [help]
```
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rs ...
```
line 339, column 2: Missing atom:link with rel="self" [help]
```
  </channel>
  ^
```

Source: https://blogs.msdn.microsoft.com/edhild/feed/

<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rss/1.0/modules/syndication/" xmlns:dc="https://purl.org/dc/elements/1.1/" xmlns:content="https://purl.org/rss/1.0/modules/content/" xmlns:wfw="https://wellformedweb.org/CommentAPI/" xmlns:slash="https://purl.org/rss/1.0/modules/slash/"
version="2.0">
<channel>
<title>edhild's WebLog</title>
<atom:link
href="https://docs.microsoft.com/archive/blogs/edhild/feed.xml"
rel="self"
type="application/rss+xml" />
<link>https://docs.microsoft.com/archive/blogs/edhild/feed.xml</link>
<description />
<lastBuildDate>Tue, 16 Apr 2019 05:07:03 GMT</lastBuildDate>
<language>en-US</language>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<item>
<title>MTC Studio Broadcast on SPS 2016</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/mtc-studio-broadcast-on-sps-2016</link>
<pubDate>Fri, 25 Mar 2016 15:55:46 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/?p=1203</guid>
<description><![CDATA[Thanks to everyone who attended our MTC Studio Broadcast on SharePoint 2016. Due to some last minute...]]></description>
<content:encoded><![CDATA[Thanks to everyone who attended our MTC Studio Broadcast on SharePoint 2016. Due to some last minute audio problems, you didn't get to see my ugly face on the screen. I did help plan and execute the event (and ended up answering most of the questions in the Q&A). For those that missed it, you can watch the replay here.
<iframe src="https://channel9.msdn.com/blogs/MTCStudio/2016-03-24-Whats-Next-in-SharePoint-2016/player" width="960" height="540" frameborder="0" allowfullscreen="allowfullscreen"></iframe>]]></content:encoded>
</item>
<item>
<title>SPS DC Event Follow Up</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/sps-dc-event-follow-up</link>
<pubDate>Tue, 06 Oct 2015 10:51:00 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2015/10/06/sps-dc-event-follow-up/</guid>
<description><![CDATA[For those who attended the SPS DC Event in Reston last weekend, as promised, here is the follow up...]]></description>
<content:encoded><![CDATA[For those who attended the SPS DC Event in Reston last weekend, as promised, here is the follow up post that has my slides from the event. My session was an overview of SharePoint 2016 and the major investment areas. I slanted the presentation a bit towards the IT Pro given that was the track I was in and delivered a hybrid search demo that included previews of search results delivered from the Office Online Server preview.
Thanks again for spending your time listening -Ed
 <iframe src="https://onedrive.live.com/embed?cid=601CFA765E7A6FD3&resid=601CFA765E7A6FD3%21184599&authkey=AGu89qGgL1qBhGM&em=2" frameborder="0" scrolling="no" width="402" height="327"></iframe>]]></content:encoded>
</item>
<item>
<title>NOVA Code Camp Follow Up</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/nova-code-camp-follow-up</link>
<pubDate>Tue, 21 Apr 2015 12:35:00 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2015/04/21/nova-code-camp-follow-up/</guid>
<description><![CDATA[Last weekend, I presented a session on Developing Structured Document Solutions with Office Apps....]]></description>
<content:encoded><![CDATA[Last weekend, I presented a session on Developing Structured Document Solutions with Office Apps. The presentation was a continuation of the topics that I have been writing about for years in my previous books. This time, I gave an update on Open XML and Content Controls with Word 2013. Then we started looking at building on that foundation with the new Office Apps. Here is my slide deck from the event.
 
<iframe src="https://onedrive.live.com/embed?cid=601CFA765E7A6FD3&resid=601CFA765E7A6FD3%21134481&authkey=&em=2&wdAr=1.7777777777777776" frameborder="0" width="350px" height="221px">This is an embedded <a href="https://office.com" target="_blank" data-mce-href="https://office.com">Microsoft Office</a> presentation, powered by <a href="https://office.com/webapps" target="_blank" data-mce-href="https://office.com/webapps">Office Online</a>.</iframe>
 
Plus here are some links on MSDN to some of the samples that were in my presentation:
<a href="https://code.msdn.microsoft.com/office/Apps-for-Office-Persist-ddd4cb40" target="_blank">Apps for Office: Persist custom settings</a>
<a href="https://code.msdn.microsoft.com/office/Apps-for-Office-Create-an-a3ad6522" target="_blank">Apps for Office: Create an Invoice Manager</a>
<a href="https://code.msdn.microsoft.com/office/Apps-for-Office-Work-with-d58e7a79" target="_blank">Apps for Office: Work with custom XML parts</a>
<a href="https://code.msdn.microsoft.com/office/Apps-for-Office-Add-and-a525e64d" target="_blank">Apps for Office: Add and Populate a Binding in Word</a>
<a href="https://code.msdn.microsoft.com/office/Apps-for-Office-Binding-to-39ccfed8" target="_blank">Apps for Office: Binding to and validating content controls in Word 2013</a>
 
Thanks for the great turn out!
Ed
 ]]></content:encoded>
</item>
<item>
<title>High Trust SharePoint Apps on Non-Microsoft Platforms</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/high-trust-sharepoint-apps-on-non-microsoft-platforms</link>
<pubDate>Mon, 14 Jul 2014 10:38:18 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2014/07/14/high-trust-sharepoint-apps-on-non-microsoft-platforms/</guid>
<description><![CDATA[I came across this post from Kirk Evans and just had to share as I get asked this question from time...]]></description>
<content:encoded><![CDATA[I came across this post from Kirk Evans and just had to share as I get asked this question from time to time...
<a href="https://blogs.msdn.com/b/kaevans/archive/2014/07/14/high-trust-sharepoint-apps-on-non-microsoft-platforms.aspx">https://blogs.msdn.com/b/kaevans/archive/2014/07/14/high-trust-sharepoint-apps-on-non-microsoft-platforms.aspx</a>
 ]]></content:encoded>
</item>
<item>
<title>SharePoint Hosted App with VS 2013 Update 2 & SPS 2013 SP1 Equals Style Sheet Error?</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/sharepoint-hosted-app-with-vs-2013-update-2-sps-2013-sp1-equals-style-sheet-error</link>
<pubDate>Fri, 30 May 2014 08:29:00 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2014/05/30/sharepoint-hosted-app-with-vs-2013-update-2-sps-2013-sp1-equals-style-sheet-error/</guid>
<description><![CDATA[I've been completely rebuilding my on-premises SharePoint 2013 development environment recently. I...]]></description>
<content:encoded><![CDATA[I've been completely rebuilding my on-premises SharePoint 2013 development environment recently. I built it out entirely in Azure. With the rebuild comes the opportunity to update everything to the latest and greatest. This means SharePoint 2013 SP1, SQL Server 2014, Visual Studio 2013 Update 2, and Windows Server 2012 R2. I even applied the April cumulative updates for SharePoint. I've never been one to just take someone else's Powershell script and just run it as I find a guilty pleasure in going through the configuration so it is exactly what I want.
One area that I always spend a good deal of time with is setting up the App-Domain to host the SharePoint apps on-premises. This time, I decided that even though it was a development environment, I wanted to do everything over SSL. I also routinely use a new top-level DNS domain so if my SharePoint web application is intranet.sample.com, my app domain url is *.sampleapps.com. This involves a good deal of configuration (for another blog post) including DNS, Certificates, and Powershell, but when complete I thought I would do a simple test. It seemed like a good idea to open up Visual Studio 2013 Update 2, create a new SharePoint hosted app, target my developer site collection and just press F5. I have done this 100s of times in my older environment. But what is this? Look at the result! This picture is the app's page in the app web. Remember I didn't write one line of code!
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/8420.stylesheet%20missing.png" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/8420.stylesheet-missing.png"><img src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/8420.stylesheet%20missing.png" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/8420.stylesheet-missing.png" alt="" border="0" /></a>
I thought the error was probably in my configuration. Could it be the way I setup the app domain? Was the SSL requirement causing something to not be loaded? After lots of investigation, I found that the real problem was that a stylesheet from the host web wasn't being applied to the page in the app web despite the fact that the stylesheet reference was in the resulting HTML. This made me scratch my head for a while. What was the problem? Was there a bug in the sample code that was included in VS 2013 Update 2? I found that unlikely. I then installed a free SharePoint hosted app from the SharePoint store. This worked and rendered exactly as suspected without the stylesheet error. So what was different between the store app and my no-code / press F5 app?
It turns out it was really simple. You need to explicitly give your app Web Read rights in its app manifest. Odd that in previous versions, I noticed that leaving this out didn't cause a problem. It was as if there was implicit read rights. Well this is no longer the case. After setting Read permission for the Web and pressing F5 again, sure enough the stylesheet loaded.
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/5545.stylesheet%20present.png" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/5545.stylesheet-present.png"><img src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/5545.stylesheet%20present.png" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/5545.stylesheet-present.png" alt="" border="0" /></a>
I thought this worth a quick note in case anyone else is confused with the same problem. ]]></content:encoded>
</item>
<item>
<title>Creating an Interactive Lync Kiosk</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/creating-an-interactive-lync-kiosk</link>
<pubDate>Fri, 06 Dec 2013 07:39:48 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2013/12/06/creating-an-interactive-lync-kiosk/</guid>
<description><![CDATA[I know I haven't posted in a while. I thought you all would like to see what myself and fellow MTC...]]></description>
<content:encoded><![CDATA[I know I haven't posted in a while. I thought you all would like to see what myself and fellow MTC team members have been up to. For our new center, we created a video wall interactive experience with Kinect that enables customer to learn about and play with Microsoft Lync:
<a href="https://blogs.msdn.com/b/mtcblog/archive/2013/11/27/mtc-reston-building-an-interactive-microsoft-lync-kiosk.aspx">https://blogs.msdn.com/b/mtcblog/archive/2013/11/27/mtc-reston-building-an-interactive-microsoft-lync-kiosk.aspx</a>
 ]]></content:encoded>
</item>
<item>
<title>Custom Site Provisioning in SharePoint's New App Model with Workflow</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/custom-site-provisioning-in-sharepoints-new-app-model-with-workflow</link>
<pubDate>Thu, 26 Sep 2013 13:06:23 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2013/09/26/custom-site-provisioning-in-sharepoints-new-app-model-with-workflow/</guid>
<description><![CDATA[If you have followed this blog at all over the years, you know I started the bandwagon really early...]]></description>
<content:encoded><![CDATA[If you have followed this blog at all over the years, you know I started the bandwagon really early on with automating site and site collection provisioning with SharePoint. In fact this has been my topic at all of the SharePoint conferences except the last one. I was a little tired of the topic and thought everyone had heard it, but I was wrong and there still was a session on the topic anyway. I have simply seen too many customers that turn the knob either too far or too little in terms of enforcing their governance policies into this process. If an organization puts too few controls in place then you end up with the wild, wild west and uncontrolled sprawl of sites with no reason for naming conventions, urls, selected templates, etc. Go too far and make it so that a human has to intervene for any type of site request and well you have an awesome SharePoint deployment that no one will want to use because sending the file via email will get the job done quickly.
Finally with the release of SharePoint 2013, there are hooks in the product for you to jump in and take control of the process. My favorite technique with this release is to simply provide a URL to a custom application that is going to provide the form and take over the entire process. I am not the only one to advocate this technique. In fact, Richard diZerega (my fellow MTC colleague) has a great post on how to do exactly that as a SharePoint app. He has his code and a video to go along with his solution.
<a href="https://blogs.msdn.com/b/richard_dizeregas_blog/archive/2013/04/04/self-service-site-provisioning-using-apps-for-sharepoint-2013.aspx">https://blogs.msdn.com/b/richard_dizeregas_blog/archive/2013/04/04/self-service-site-provisioning-using-apps-for-sharepoint-2013.aspx</a>
The goal of this blog is first to draw attention to Richard's great example and I am not going to re-walk you through his code and solution. Second, I want to point out a common customer ask that I have extended into Richard's work. After I show the custom form much like the one in Richard's demo, the customer often asks - "How do I incorporate a workflow into that so an approval has to happen?". Great question!!! I thought I would outline here what I added to Richard's solution to incorporate this requirement.
First the design of the solution: Since we want a workflow to take place before the site or site collection is created, we need to revisit how to gather the user input, what should trigger the workflow, and how to launch the custom code in the application that automates the site creation. In my demo, I decided to use a simple custom list called Site Requests to be the user input. If you wanted a nicer user interface, you could use the UI in the custom app that Richard has and then have it write an entry to the list, but having the list item gives us something to hook our workflow to. The custom list can really be placed in any site where you want to collect this user requests. Here is a screen shot of my list with some sample test data in it:
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0638.SiteRequestsList.png" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0638.SiteRequestsList.png"><img src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0638.SiteRequestsList.png" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0638.SiteRequestsList.png" alt="" width="367" height="183" border="0" /></a>


Looking that the details of this shape, the URL to the REST web service includes several key elements:
https://012bfa74-f840-4fa3-93ad-610003cc4200.o365apps.net/api/Provision/[%Current Item:SiteType%]?siteTitle=[%Current Item:Title%]&siteUrl=[%Current Item:Url%]&siteDescription=[%Current Item:Description%]&appWebUrl=https%3A%2F%2Fedhild613%2D7eb7f3f84addc7%2Esharepoint%2Ecom%2Fsites%2Fapps%2FSelfServiceProvisioning
The first part of the URL is the actual URL to the remote web where the custom application form in Richard's solution is hosted. Instead of using an ASPX form however, the endpoint is a REST service at /api/Provision. The very next part of the URL is the SiteType, so our request to the REST web service looks like /api/Provision/Blog or whatever SiteType is requested. The remaining part of the URL is a few querystring parameters that the REST service will need both to complete the request as well as information for it to establish the remote context to call back to SharePoint. These include the requested title, url, and description for the site as well as the URL of the appWeb where the custom app is deployed.
The last part of the solution is to just take the logic that is in Richard's ASPX form and wrap it as a REST service. You can still include the ASPX form in the same remote web, so these changes I highlight here are additions to his solution. To begin with, you will need a Global.asax file to register the REST endpoint. Once you add it to the project, place the following code in the Application_Start event:
protected void Application_Start(object sender, EventArgs e) {
RouteTable.Routes.MapHttpRoute(      name:"DefaultApi",     routeTemplate:"api/{controller}/{siteType}");
}
Then, add a new Web API Controller class named ProvisionController. The name of this file is important as the part before the word Controller matches the /api/Provision name in our Url.  This Visual Studio item type should stub out a place for you to write code for the GET requests that we are sending. Here is my implementation which also collects the various querystring parameters.
// GET api/<controller>/5
public string Get(string siteType) {
string siteTitle        = String.Empty;     string siteUrl          = String.Empty;     string siteDescription  = String.Empty;     string appWebUrl        = String.Empty;     string siteOwner        = "I hard coded the email address of the owner";
foreach (var param in this.Request.GetQueryNameValuePairs())     {
          switch (param.Key)       {
case "siteTitle":
siteTitle = param.Value;                         break;
case "siteUrl":
siteUrl = param.Value;                         break;
case "siteDescription":
siteDescription = param.Value;                         break;
case "appWebUrl":
appWebUrl = param.Value;                        break;
           }
       }
      string returnVal = ProvisionSite(siteType, siteTitle, siteUrl, siteDescription, siteOwner, appWebUrl);
   return returnVal;
}
The ProvisionSite method is code that wraps the same code in Richard's solution that is in the code-behind of the ASPX page. I only made a small change from the code you can download from his blog. Basically, I made it so the REALM could be dynamically determined from the AppWeb Url. The beginning of my method looks like this:
private string ProvisionSite(string siteType, string siteTitle, string siteUrl, string siteDescription, string siteOwner, string appWebUrl) {
List<SSConfig> configList;
const string targetPrincipal = "00000003-0000-0ff1-ce00-000000000000";
   try
     {          
      //get configuration information
Uri appWeb = newUri(appWebUrl);
string realm = TokenHelper.GetRealmFromTargetUrl(appWeb);
string appOnlyAccessToken = TokenHelper.GetAppOnlyAccessToken(targetPrincipal, appWeb.Authority, realm).AccessToken;
using (ClientContext clientContext = TokenHelper.GetClientContextWithAccessToken(appWeb.ToString(), appOnlyAccessToken))
 
 And Richard's code will take you from there. The end result is now a list item that has a SharePoint 2013 Workflow attached to it that makes a REST call to a SharePoint App's Remote Web where the actual provisioning takes place. On a side note, I am finding that this pattern of having a workflow call a REST endpoint in a SharePoint App remote web seems to be quite a common way to extend the platform. Good luck -Ed
 
 
 
 
 
 ]]></content:encoded>
</item>
<item>
<title>A Perspective on SharePoint 2013's App Model - Part 2</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/a-perspective-on-sharepoint-2013s-app-model-part-2</link>
<pubDate>Wed, 24 Apr 2013 12:11:00 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2013/04/24/a-perspective-on-sharepoint-2013s-app-model-part-2/</guid>
<description><![CDATA[In part 1 of this series, I discussed why the way developers extend SharePoint needed to change. In...]]></description>
<content:encoded><![CDATA[In <a title="part 1" href="https://blogs.msdn.com/b/edhild/archive/2013/02/13/a-perspective-on-sharepoint-2013-s-app-model-part-1.aspx">part 1</a> of this series, I discussed why the way developers extend SharePoint needed to change. In this article I will detail types of SharePoint applications, how they fit into the app model, and the tools you can use to build applications.
<h1>What is a SharePoint App?</h1>
The words "SharePoint application" could probably mean a lot of different things to different people. Therefore, I want to do some level-setting before I dive specifically into the new App model. SharePoint provides a lot of functionality out of the box (search, workflow, lists, libraries, forms, content and document management, etc). The idea of building an application is really applying this functionality to a specific business need. I have seen some very effective "apps" that are nothing but out-of-the-box SharePoint functionality. So I thought I would talk about categories of applications first and then dive into the app model which usually enters the conversation when out-of-the-box functionality only gets you part of the way there. In my experience, you can categorize applying SharePoint to business processes along two different axis. These are the complexity of the desired user interface along with the complexity of the data model or business logic.
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/7635.app%20matrix.jpg" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/7635.app-matrix.jpg"><img src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/7635.app%20matrix.jpg" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/7635.app-matrix.jpg" alt="" border="0" /></a>
In the bottom-left quadrant, you have those applications that can be completely delivered by configuring out-of-the box functionality. Assuming the data model and business logic requirements remain the same, you can gain greater control of the user interface by introducing some additional tools. These could be forms (either web forms or those created with InfoPath), HTML 5 JavaScript customizations, or even a browser plug-in such as Silverlight.  The nature of the custom user interface requirements as well the skills of the person doing the customization will drive you to one of these choices. Are you simply trying to add some advanced validation and formatting to data entry of your list? In this case, InfoPath is the quickest way to a solution. As the data model becomes more complex or the business logic needs increase, the complexity of the solution does as well. If you can keep the data model relatively out-of-the-box and need just a place for some custom logic, the usually introducing SharePoint workflows will meet your need. When you need to go beyond a workflow and require to code a business layer or if you need to introduce your own relational database - that is the quadrant of custom apps. When I speak of the SharePoint app model, I am mostly focusing on building solutions with requirements similar to those.
Side Note: Why would you ever need your own relational database? Let's be honest here. The SharePoint content databases are things of marvel. Almost whatever you want it to store a list of any type or tons of content it is really good at it. However, a yellow-flag for any solution is where a developer is using many SharePoint lists with lots of lookups and relationships. Or the developer has a list where they are expecting tons of items. Though SharePoint can store the content in both of these scenarios, should it? The main issues I have seen with applications is that SharePoint's content databases are a block-box. They are hands-off from a supportability point of view. So if you expect to write many reports against an extremely large list, odds are you will find yourself battling performance problems since you can't go into the database and add your own custom indexes. Plus it is important to realize that these lists don't give you much support in terms of transaction boundaries. If you app needs a sort of tracking database - odds are that it is better to host that outside of the content database.
<h1>Types of Apps in SharePoint 2013's App Model</h1>
In my earlier post, I introduced the major guiding principal behind the new development model in SharePoint 2013. The new model dictates that no server side code be deployed to the SharePoint servers. The only things that SharePoint hosts for the applications are the things it already knows how to do: Lists, Libraries, Workflows, Content (which can include HTML pages and javascript), etc. If to build your application, you need a custom database that you are going to code against, or web services that you need to supplement, or user interface elements that are easier to build in ASP.NET, these things must be hosted elsewhere. It should be noted that not all custom apps will have server side components. Therefore, we use several terms to describe the type of SharePoint app:
<ul>
<li>SharePoint Hosted: A "SharePoint hosted" application is a SharePoint app that contains no server side components. It can deploy everything it needs (libraries, workflows, content, etc) all within the SharePoint environment.</li>
<li>Provider Hosted: A "Provider hosted" application is a SharePoint app that has server side components. For these components (usually contained within an ASP.NET application), you must provide a separate environment to host them. If could be a separate, non-SharePoint IIS server. Or it could be a virtual machine running in Azure's Infrastructure as a Service. As I stated in the earlier article, the server side components can really be developed in any technology as long as you can abide by the OAUTH requirements and make REST calls. But since Microsoft has done so much to make these remote components easy to build in ASP.NET, we will assume that going forward.</li>
<li>Auto-Hosted: An "Auto-hosted" application is unique to Office 365 and the SharePoint Online service that runs there. If you are deploying on-premises you can cross this one of your list. However, if you are running in Office 365, it is one of the more ideal solutions. An auto-hosted application has server side components, but when you deploy the application to SharePoint, the service automatically spins up the server-side elements in an embedded Azure layer. It isn't Azure like you would manage in IaaS. It is more like the traditional Platform as a Service model where your app is deployed for you in a hosting environment you don't even log into. The biggest benefit of this model is that most of the registration and OAUTH plumbing is completely handed for you.</li>
</ul>
A little bit more vocabulary.... When you add a SharePoint app to a SharePoint site, it is important to understand where things are going. First, we refer to the SharePoint site you added the app to as the "host web". If the application has things it would like SharePoint to host (such as lists, libraries, content, etc), these components are put in a sub-site of the host web called the "app web". Usually this app web is accessed through a different top-level DNS entry then the SharePoint site to protect against cross-site scripting attacks. Having everything in the app web makes an uninstall very easy. When you remove the application, it removes the app web. Keep this in mind if you expect your data to be persisted despite the removal of your application from the site. You may need to place that content somewhere else like the host web. Lastly, if your application has server side elements, these are hosted outside the SharePoint infrastructure. We refer to that as the remote web.
<h1>What Kind of Tools Make SharePoint 2013 Style Apps?</h1>
I am going to go out on a limb here and not just make the statement that you need Visual Studio 2012. Almost everything on MSDN jumps immediately to this point. However, there are lot of tools that can get you into the SharePoint app world most with less development chops then Visual Studio would require. In fact, some of them are sort of built into SharePoint 2013 automatically. Here is a list:
<ul>
<li>Access 2013: Yes Microsoft Access. It turns out that a wonderful feature of Microsoft Access is that you can create "web databases". If you are familiar with Access Services in SharePoint 2010, read carefully - a lot has changed. If you design an application with Access 2013 and you choose to start with a custom web database, the application will publish as a SharePoint app. The form interfaces become HTML 5 forms and the data gets housed in a custom SQL database outside of SharePoint's content databases. If you are running in Office 365, this means SQL Azure. On-premises you can designate on what SQL instance these databases should be housed.</li>
<li>Napa: The Napa tool is a web based development environment for application that are SharePoint hosted and running in Office 365.</li>
<li>Visual Studio Lightswitch: This tool was just recently released with Visual Studio 2012 Update 2. Lightswitch has always emphasized code generation where you customize screen templates and either build your own data model or connect to existing ones. This latest release has an option to deploy as a SharePoint application. The user interface is HTML 5 which is hosted in a remote web or auto-hosted. And the custom data model is housed by SQL Azure or SQL Server on-premises. Lightswitch even supports you referencing SharePoint lists in your data model.</li>
<li>Visual Studio 2012: The developers tool.</li>
</ul>
In the next posts, I plan to go over some examples of applications and a bit more detail on OAUTH. Be on the look out.
 ]]></content:encoded>
</item>
<item>
<title>A Perspective on SharePoint 2013's App Model - Part 1</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/a-perspective-on-sharepoint-2013s-app-model-part-1</link>
<pubDate>Wed, 13 Feb 2013 06:59:00 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2013/02/13/a-perspective-on-sharepoint-2013s-app-model-part-1/</guid>
<description><![CDATA[A lot of my customers lately to the Microsoft Technology Center have been interested in the new App...]]></description>
<content:encoded><![CDATA[A lot of my customers lately to the Microsoft Technology Center have been interested in the new App Model of SharePoint 2013. This should not be a surprise given that the new App Model is one of the big additions to SharePoint 2013. What is interesting is that these customers are not going to the cloud any time soon and see SharePoint as an on-premises enterprise service. Most of the material out there on the new App Model emphasizes Office 365 and Auto Hosted solutions where the remote web is running in Azure. I thought I would start this series of blogs posts with why the App Model is something you should consider in an on-prem deployment.
<h2>Product or Platform?</h2>
Over SharePoint's history, it has struggled with the product or platform question. Ultimately, SharePoint provides a lot of out of the box functionality that enterprises are looking to deploy. Things like content management, search, workflows, business intelligence, etc are all quite functional out-of-the-box with some configuration. This would be the product side of the equation. However, ever since SharePoint was based on the .NET framework (SPS 2003) developers have been looking to extend it. This shouldn't surprise anyone either since for a good quantity of line of business applications, SharePoint is an 80% solution. Developers and enterprises both see it as a platform that if they build on will shorten the development lifecycle substantially since they only have to build the 20% that is specific to their application. Enter event receivers, custom web parts, application pages, custom workflows, etc.
The problem comes when these SharePoint applications are deployed to production and are now the responsibility of IT to maintain. Focused on keeping the lights on, this group is change adverse. Any custom code deployed onto the SharePoint servers complicates things. Does it change the way they do backup and recovery? How well was the code written and will it bring down the farm? Does it change the capacity planning activities that were done for out-of-the-box functionality? For these reasons there is a struggle as to how to effectively support these types of applications that are built leveraging SharePoint.
<h2>Build On or Build Alongside?</h2>
It is important to realize how developers have usually built SharePoint applications in the past, some of the fundamental problems with the model and why things are changing so drastically with SharePoint 2013. Prior to SharePoint 2013, developers looked at SharePoint and saw it almost like a stack of lego blocks they can use to build an application. Things like lists, libraries, versioning, search, calendars, workflows, etc were all pieces to lay the foundation for their application. To build the whole "solution", developers would build custom components that when deployed to the SharePoint server, fill the gap. These were things like custom web parts, event receivers, custom code workflows, application pages, and so forth. The end result was that SharePoint + the Customizations = The Solution. I have coined describing this as the "Build On" solution. See this rough picture:
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0676.buildon.gif" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0676.buildon.gif"><img src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0676.buildon.gif" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0676.buildon.gif" alt="" width="396" height="388" border="0" /></a>
What is the problem of this model? It is the model that all prior SharePoint development likely used and even most of the SharePoint developer training teaches. The problem is that the customizations are literally extending the product on the SharePoint server. Once this has been done, all bets are off in terms of performance. It could complicate your IT staff's ability to meet their service level agreements. And remember this was done to keep cost low - however, now every time you "upgrade" SharePoint, you have to retest all of this additional work. You got a big bang up front, but are paying later when it comes to moving to new releases. This is the most costly part of upgrade/migration conversations I have had with customers.
Enter SharePoint 2013 and its new App Model. Before we get started, it is worth noting that using the App Model on-premises is an option. You can still continue to Build On SharePoint, but you are still subject to the disadvantages of that model. The new App Model changes the game considerably with a fundamental rule change. Thou shall not put custom server-side code on a SharePoint server. SharePoint can still be used as an application platform, but we are going to keep the farm's servers from being burdened with running your customizations and require you to host them somewhere else. Where you say? Anywhere you want (Azure, another web server, etc). In fact this separation of the out-of-the box SharePoint product functionality and your customizations opens up tons of benefits. First the obvious ones:
<ul>
<li>Your app won't have compiled code on the server complicating the hosting and management of the SharePoint farm</li>
<li>You can separate responsibility for hosting the SharePoint enterprise service and the line of business app functionality</li>
<li>Your developers don't have to be as SharePoint savvy since they will just interface through client side object models, javascript, rest end points, etc.</li>
<li>In fact developers could use even non-Microsoft tools and languages to build the remote functionality</li>
<li>Lastly, it drastically reduces the upgrade hurdle since it is easier to keep interfaces backward compatible (you are not strongly coupled to SharePoint's server assemblies)</li>
</ul>
I have coined the term "Build Alongside" as the way to describe this model. Basically SharePoint + your Customizations = Solution still applies. However, we separate the customizations from the product. Now in order for this to work and work well, SharePoint 2013's support for remote code to interact with it has been vastly improved over the prior versions. We get client side object models (CSOM) for javascript and .NET managed code. We also get lots of REST endpoints, ODATA feeds, and OAUTH for application level authentication. All built on industry standards so as to open up this development model to more developers.
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0131.buildalongside.gif" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0131.buildalongside.gif"><img src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0131.buildalongside.gif" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0131.buildalongside.gif" alt="" width="442" height="435" border="0" /></a>
<h2>History of SharePoint Development Models </h2>
 If you are new to this, hopefully at this point I have you scratching your head. You might be wondering how this fits into the developer methods you already know. So let dive in a bit to clear things up... If you were familiar with SharePoint 2010, I'd argue that your development efforts probably fell into one of these three buckets:
<table style="border-width: 2px; border-style: solid;" border="2" frame="box">
<tbody>
<tr>
<td><a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/2330.farmtrusted.jpg" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/2330.farmtrusted.jpg"><img style="margin-right: auto; margin-left: auto; display: block;" src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/2330.farmtrusted.jpg" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/2330.farmtrusted.jpg" alt="" width="344" height="98" border="0" /></a></td>
</tr>
<tr>
<td>
<ul>
<li>Visual Studio customizations whose code ran on the SharePoint server inside the IIS worker process</li>
<li>Often deployed to the GAC on SharePoint’s WFE. Required Admin</li>
<li>Unlimited trust model. Access to SharePoint server-side OM</li>
<li>Usually unmonitored</li>
<li>Wide availability – Feature shows up everywhere at the appropriate scope</li>
<li>Poor clean up if uninstalled</li>
<li>Solution upgrade, maintenance required additional coding or scripting</li>
<li>Increases ramp to upgrading product version</li>
</ul>
</td>
</tr>
<tr>
<td>
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0882.sandboxed.jpg" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0882.sandboxed.jpg"><img style="margin-right: auto; margin-left: auto; display: block;" src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0882.sandboxed.jpg" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0882.sandboxed.jpg" alt="" width="305" height="102" border="0" /></a>
</td>
</tr>
<tr>
<td>
<ul>
<li>Visual Studio customizations whose code ran within the a User Code service</li>
<li>Deployed by a site collection admin uploading the wsp to a site collection’s Solution Gallery</li>
<li>Partial trust model. Limited access to the SharePoint server-side OM.</li>
<li>Support for proxies to widen the trust model often resulted in the “expensive” operations being fully trusted.</li>
<li>Monitored by the farm using resource counters</li>
<li>Difficult to distribute widely and track usage</li>
<li>Poor cleanup if uninstalled</li>
<li>Solution upgrade, maintenance required additional coding or scripting</li>
</ul>
</td>
</tr>
<tr>
<td> <a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0535.clientside.jpg" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0535.clientside.jpg"><img style="margin-right: auto; margin-left: auto; display: block;" src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0535.clientside.jpg" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0535.clientside.jpg" alt="" width="296" height="104" border="0" /></a></td>
</tr>
<tr>
<td> 
<ul>
<li>Content that contained code which ran client side in the user’s browser</li>
<li>Silverlight, JQuery, JavaScript, etc</li>
<li>No trust model. No access to the SharePoint server-side OM.</li>
<li>Leveraged Client Side OM, Web Services, ODATA, RSS, REST, browser’s DOM</li>
<li>Could be deployed by user with little admin rights</li>
<li>Not monitored</li>
<li>Difficult to distribute widely and track usage</li>
<li>Solution upgrade often meant manual adjustments</li>
</ul>
</td>
</tr>
</tbody>
</table>
Now in SharePoint 2013, each of these techniques still exist. However, with the additional of the App Model things change a bit. First, farm trusted solutions become something only for adding administrative extensions, not user applications. The Sandbox service is still there, however mostly for backward compatibility. The new App Model supersedes it. It has the same goals of isolation and monitoring but a lot less limiting in what developers can do when using the model. And lastly, the client side option is wrapped into the App Model as well. These would be applications where there is no remote component (called SharePoint Hosted Applications). These apps only have SharePoint out-of-the-box functionality, SharePoint pages, and javascript. So redoing the above table for SharePoint 2013 turns into this:
 
<table style="border-width: 2px; border-style: solid;" border="2" frame="box">
<tbody>
<tr>
<td><a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/2330.farmtrusted.jpg" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/2330.farmtrusted.jpg"><img style="margin-right: auto; margin-left: auto; display: block;" src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/2330.farmtrusted.jpg" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/2330.farmtrusted.jpg" alt="" width="344" height="98" border="0" /></a></td>
</tr>
<tr>
<td>
<ul>
<li>No longer recommended for extensions that are primarily used by end-users</li>
<li>Should be used for customization of administrative functions (timer jobs, PowerShell, central admin)</li>
<li>No longer support being deployed with Custom Access Security Policies</li>
</ul>
</td>
</tr>
<tr>
<td>
<a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0882.sandboxed.jpg" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0882.sandboxed.jpg"><img style="margin-right: auto; margin-left: auto; display: block;" src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0882.sandboxed.jpg" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0882.sandboxed.jpg" alt="" width="305" height="102" border="0" /></a>
</td>
</tr>
<tr>
<td>
<ul>
<li>Deprecated in SharePoint 2013 Preview</li>
<li>Service remains primarily for backward-compatibility</li>
<li>The goals of this model along with many improvements have been incorporated into the new SharePoint Apps model</li>
</ul>
</td>
</tr>
<tr>
<td> <a href="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0535.clientside.jpg" original-url="https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0535.clientside.jpg"><img style="margin-right: auto; margin-left: auto; display: block;" src="https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/44/66/0535.clientside.jpg" original-url="https://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-44-66/0535.clientside.jpg" alt="" width="296" height="104" border="0" /></a></td>
</tr>
<tr>
<td> 
<ul>
<li>Formalized into the new SharePoint Apps model.</li>
</ul>
</td>
</tr>
</tbody>
</table>
That's it for now. I plan a part two where I go into more detail on the types of apps in SharePoint 2013's App Model and how to change your thought patterns of what it is you need to build for that last 20%. Possibly another post where I give some advice for those of you who are trying to build this on-premises. And possibly some web demos. Let me know what you think in the comments and what direction I should take for the future parts.]]></content:encoded>
</item>
<item>
<title>Some SharePoint Leadership Conference Press</title>
<link>https://docs.microsoft.com/archive/blogs/edhild/some-sharepoint-leadership-conference-press</link>
<pubDate>Wed, 31 Oct 2012 06:46:20 GMT</pubDate>
<dc:creator><![CDATA[Ed Hild]]></dc:creator>
<guid
isPermaLink="false">https://blogs.msdn.microsoft.com/edhild/2012/10/31/some-sharepoint-leadership-conference-press/</guid>
<description><![CDATA[Just a little self promoting, but here is a write up of the very quick demo I did for the SharePoint...]]></description>
<content:encoded><![CDATA[Just a little self promoting, but here is a write up of the very quick demo I did for the SharePoint Leadership Conference in DC a few weeks ago. Thank you to the Bamboo team for putting everything together.
<a href="https://community.bamboosolutions.com/blogs/bambooteamblog/archive/2012/10/29/splf-2012-ed-hild-introduces-the-new-microsoft-office-and-sharepoint-2013.aspx">https://community.bamboosolutions.com/blogs/bambooteamblog/archive/2012/10/29/splf-2012-ed-hild-introduces-the-new-microsoft-office-and-sharepoint-2013.aspx</a>
 ]]></content:encoded>
</item>
</channel>
</rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=https%3A//blogs.msdn.microsoft.com/edhild/feed/"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=https%3A//blogs.msdn.microsoft.com/edhild/feed/

Home · About · News · Docs · Terms