I had this guide on how to publish SharePoint with Forefront UAG in draft mode but as it turns out Microsoft just pulled the plug on UAG. As of July 1st 2014, UAG wont be available for purchase and mainstream support ends on April 14th 2015. It is unclear as to why the product was killed but Microsoft now recommends using Server 2012 R2 Web Application Proxy for your publishing needs. The windows server feature is nowhere near as good as UAG and it does require federating any applications you publish with ADFS which means more servers. Luckily your UAG license now gives you an additional Windows Server license for your needs. I will be publishing a guide for the Server 2012 R2 Web Application Proxy pretty soon.
After a long holiday, a lot of project work and numerous requests, the solution is now uploaded to codeplex and can be accessed using the link below.
Received this couple of months ago but I didn’t get a chance to show it off yet (except to some colleagues). The Visual Studio team send me a thank you gift for my contribution to the product which admittedly during this release was mostly around TFS extensibility and the SCRUM tools.
I found an interesting issue in SharePoint 2013 when you try to create a new Document Set based on a Content Type that has a Date and Time field on it in a site where the regional settings are configured to English United Kingdom and the time format is 24 hours. Specifically, you will receive an error that the date is in an incorrect format when you press Save. A quick trip to the forums and I received confirmation that it is a bug and that it was fixed in the March 2013 PU which can be obtained from the links below:
For almost every scenario where we have implemented multiple Content Types for documents, the next comment was if we can replace the “New Document” menu. The menu stops been practical when you have several content types on the same Library and it is definitely not suitable when you use SharePoint with a touch input device. I always wanted to implement a solution for this and I finally managed and here is a detailed description of it.
First of all lets take a look at the out of the box menu which is a split button showing the available Content Types.
My implementation replaces the out of the box split button with a standard button, while retaining the icon, tool tip and label for consistency and localisation. The difference is that when you press the button, a modal dialog appears showing you a list of available content types. Clicking on one of the Content Types will launch the relevant client to create a new document.
Some features I would like to add;
- A search box to search for Content Types. The list of Content Types will be shorten to display results only.
- Grouping of Content Types, potentially using a custom UI in List Settings to configure the groups.
- Paging which isn’t too hard.
- Caching so that we don’t rebuild the list every time. Distributed Cache sounded like a good idea but takes away compatibility with SharePoint Foundation.
- Document Previews for those who have Office Web Apps or potentially using the document thumbnail saved by the client, if any.
The solution has some limitations/needs more work;
- This was only tested and designed to work with Document Content Types. This wont work with InfoPath forms or List Items. I wont support those Content Types for now.
- The dialog does not display the Folder Content Type (has its own button on the ribbon) nor hidden Content Types (just like the standard menu). This is by design.
- The button registers to specific document library types e.g. 101 for out of the box document libraries and will apply to all of them in your Site. Since this is enabled using a feature, changing the scope to Site Collection will allow you to enable it on all sub-sites. Once again by design and provides the flexibility of enabling it to specific list definitions only.
- The dialog does not close after you click on a Content Type. Working on that as top priority :).
- The default save location in Office Clients is the root folder of the Document Library at all times instead of the folder you are currently in. This is top priority as well.
- Styling is custom and doesn’t inherit a huge amount of styles from the theme engine and standard CSS classes in SharePoint. You can always use the custom CSS to modify the list of Content Types so not that high on my list.
- Installation is a bit tricky; Need to add the assembly to the compilation/assemblies section which needs automation. This is top priority for me as well to reduce deployment complexity.
- The code is based on a farm level solution and will not work with SharePoint Online.
I will be uploading the solution project to codeplex soon.
I am using the preview version of the SharePoint 2013 Developer tools and I didn’t see an option that allows upgrading SharePoint 2010 projects to 2013. Following some tweaking I discovered a quick way of converting projects from 2010 to 2013.
Step 1: Open your csproj with a text editor.
Step 2: Change the Target Framework Version from v3.5 to v4.5.
Step 3: Set the Office Target Version to 15 by entering the following tag to the file.
Step 4: Update all referenced assemblies;
- SharePoint assemblies from version 126.96.36.199 to 188.8.131.52
- .NET assemblies from 2.0 and 3.5 to 4.0 and 4.5
Step 5: Build the project to check for any compilation errors and re-adjust.
Keep in mind that your existing list definitions will need updating to take advantage of the new view styles.
Update: The SharePoint team took all the fun away by providing Visual Studio Solution upgrades with the latest Office for Visual Studio Tools (feb-2013).