All sourcecode can be found here on github
When writing code for Sitecore, this code should someday be deployed to an existing Sitecore environment. Preferably, this should happen “the first time right”. One of our guidelines to achieve this is: Don’t overwrite Sitecore files. Don’t update existing files of other packages. Don’t upgrade assembly versions. Don’t break your site. It might cause a lot of trouble without knowing where to look. When we were still working with SharePoint, there was an internal mechanism to create and remove deployment packages. Developers had to do their best to overwrite out of the box files, as packaging mechanisms were introduced which explicitly required to select the files that you wanted to deploy. I was (and I am) wondered that Sitecore doesn’t offer this feature (well, not as I expected it), and thus I decided to write a blogpost on what shortcomings we see, how to solve them and how to verify that things will good right.
Source code for the Sitecore Validate Webdeploy packages is provided on github.
When developing claims based web applications which need to connect to ADFS, Azure or any other STS, it’s not always possible to connect to an existing environment, for example, due to security, the absence of a test environment or an unwilling admin ;). To solve this, a lot of people try to setup a local AD, ADFS, which can cause a lot of trouble, especially in an Enterprise environment. This setup is not very convenient, especially when you just want to create a claims based application. Whenever SharePoint and Claims based hight trust provider hosted apps are thrown into the game, the inconvenient setup turns into a very complex situation.
Luckily, there is a very easy solution for this! In the next two blogposts I will show to solve this:
- How to setup a simple STS for web application development (this blogpost) – how to create a simple STS using Thinktecture embedded STS and configure the web application using the classic web.config
- How to setup claims based authentication via OWIN
- How to mix in SharePoint 2013 and hight trust claims based provider hosted apps using OWIN and the thinktecture Embedded STS
I was working on a small addition to the Thinktecture EmbeddedSTS, to ease up local development for our development teams, who are building a lot of MVC applications and SharePoint provider hosted apps. We don’t want to bother them with setting up a separate AD and ADFS, so we decided to use a simple, small STS: the Thinktecture Embedded STS. One of the actions was to add a FederationMetdata endpoint. This is a small improvement, as it’s now possible to setup claims based identities via OWIN, which is way easier to setup than via the typical web.config configuration. But there was one nifty error that was, in my case, very hard to find, but easy to fix. It turned out that the signature node may not contain any formatting, this means that spaces, line feeds and carriage returns should not be included in this Federationmetadata file
SharePoint 2013 brought great things: great new social features, the API got a major extension and of course, the new introduced app model. A feature that I really missed though, was the ability to post documents to your newsfeed from the context menu. This blogpost describes how to do this.
This is the second post as part of a blog series about the integration of using SharePoint 2013 as a datasource for windows 8 apps.Find the index at SharePoint 2013 and Windows 8 apps – better together Part 1: Introduction, background and considerations
In SharePoint 2010 the possibility of claims based authentication was introduced. The out of the box experience of this functionality is often OK, for example in cases of corporate intranets and extranets, but it doesn’t always fulfill the requirements of internet facing websites which require authentication. This blogposts describes why we wanted to implement the active login scenario and learns us what kind of problems we encountered (and nailed ;))
I would like to reference to an old post that appeared in 2007 on http://blogs.msdn.com/sharepoint, that mentions the SharePoint debugger feature. I use it quite a lot and i am sure a lot of people don’t know about its existance. Its a relatively simple feature that shows up in the SiteActions menu, opens a page which tries to launch the debugger. Using this feature, you don’t need to run iisapp, find the right PID and attach that process to your debugger. Make sure to edit the web.config to allow debugging.
link to the article: http://blogs.msdn.com/sharepoint/archive/2007/04/10/debugger-feature-for-sharepoint.aspx
the link referenced to the codeplex source doesnt work anymore. Use the following link instead:http://www.codeplex.com/features/Release/ProjectReleases.aspx?ReleaseId=2502
SPDisposeCheck is a tool to help you to check your assemblies that use the SharePoint API so that you can build better code. It provides assistance in correctly disposing of certain SharePoint objects to help you follow published best practice. This tool may not show all memory leaks in your code. Further investigation is advised if you continue to experience issues. It’s a must for every SharePoint developer!
Read more about it here:
As I had problems with the way events worked, I wanted to know more about the way they worked. below is bit of information about events that is good to know:
There are two different kinds of events: Synchronous and Asynchronous events.
- Synchronous events
- End with -ing (ItemAdding, ItemUpdating)
- Block the code as long the events arent finished
- Can (thus) make use of Session vars (HttpContext.Current is available), because they run in the same session
- Can be used to prevent the event being finished. For example, with the ItemUpdating event you can verify the content being updated. Is the update not valid, the SPItemEventProperties.Cancel can be set to true and the SPItemEventProperties.ErrorMessage can be filled with an error message. This error message will not be displayed, but is written to the logfile. An error page will appear.
- dont contain the SPListItem in it’s SPItemEventProperties so when you want to make changes to any of it’s field you need to make use of the SPItemEventProperties.AfterProperties (see message below). In the case of itemUpdating, the “old” SPListItem will be used
- Asynchronous events
- End with -ed (ItemAdded, ItemUpdated)
- Dont block the code.
- Can’t (thus) make use of the Session (HttpContext.Current is null, because code is run in another context)
- Can’t be reverted; When these events are fired, the item is already added, updated or deleted.
- contains the SPListItem. Changes can be made if you want to. This fires the (for example) ItemUpdating and ItemUpdated event. This can be turned off by using this.DisableEventFiring();
- When creating a new list, events like FieldAdded and FieldAdding are not fired!