For those of you attending CodeCamp tomorrow and just can’t wait to get your hands on those demos, here you are. Enjoy!
Recently I was asked how to take the nifty SharePoint Explorer view and save a shortcut to it so users don’t need to constantly navigate to the library via the browser to access it. This of course assumes that you do not want to or can not use OneDrive due to one of it’s many shortcomings.
- Ensure your site has been added to the “Trusted Sites” or “Intranet Sites” security zone in IE settings. If it hasn’t been added, you’ll need to add it then reboot your computer. If you don’t do this you’ll end up with an access denied error when you attempt to map the network drive.
- Navigate to the library in your browser and click the “Open with Explorer”.
- Depending on your operating system, you’ll need to do one of the following:
- In the Map Network Drive window, select the drive letter you wish to map to.
- For Office 365 users in the Map Network Drive window, check the box to Connect using different credentials.
- Click Finish.
- If prompted, enter your SharePoint username/email and password and click OK.
[Edit – 11/22/2014] I found that this does not work well on Office 365, so if you’re using O365 and want a more permanent desktop integration solution, you’re stuck with OneDrive (until I can find a way to fix it).
Sooooooo, creating a Publishing HTML field in SharePoint (think wiki Page Content field) is a huge pain (well, the solution is easy, but the figuring it out part was a pain). However, because I’m extremely busy, I’m going to skip the part where I explain all the hundreds of things I’ve tried and why they all failed, and move straight to the solution:
$web = Get-SPWeb “http://dev01”;
$spList = $web.Lists[“Pages”];
$newField = “<Field Type=’HTML’ DisplayName=’FieldName’ RichText=’TRUE’ RichTextMode=’FullHtml’ />”;
I just wanted to post a link to my SharePoint Saturday Presentation. Thanks to everyone for attending and making my first presentation a good one!
It’s really frustrating sometimes how Microsoft’s whitepapers are so specific to individual cases that they fail to apply to any useful scenario – particularly those scenarios that involve custom development. Such is the case for making HTTPS web service calls from SharePoint 2010 (to external endpoints).
Custom built web parts deployed into SharePoint 2010 need to make web service calls to a 3rd party API which used an HTTPS endpoint.
Could not establish trust relationship for the SSL/TLS secure channel with authority ‘[some url]’
The typical cause of this is that the root certificate that the SSL endpoint uses is not trusted by the computer that is attempting to make the web service connection. The typical resolution? Open the certificates snap-in through the Windows Management Console and add the root certificate (or even the certificate for the SSL endpoint) to the Trusted Authorities node and you’re all good. You can even test this by navigating to the endpoint with your browser; if you get a certificate warning it didn’t work, otherwise it’s gravy.
The issue (and the reason for this blog post) is that this doesn’t work; apparently SharePoint completely ignores the machine settings for the trusted root certificates.
It’s actually quite simple – open Central Administration and go to the security page. Find and click the Manage Trusts link. Add a new trust, and in the window that opens upload your root server certificate, give it a good name and boom, things start working – just like magic.
I also found a nice little PowerShell script that will automate the trust creation for you:
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\MyRootCertificate.cer"); New-SPTrustedRootAuthority -Name "my root certificate" -Certificate $root;
One task I’ve found to be the bane of my existence when dealing with XSL is date formatting. There’s no a good way to do it, and it makes things extremely difficult always needing to write new XSL because no 2 dates ever have the same format.
Since I’ve written more than my share of date parsing templates, I decided that I would try to do it once more, and this would be the last time I’d ever write one. The DateFormatting.xsl contains callable templates for most common operations.
The majority of the templates require a format string for input and/or output. The syntax for the string is as follows:
m – the numeric value for the month i.e. 8, 9, or 10
mm – the 2 digit padded numeric value for the month i.e. 08, 09, or 10
mmm – the short month name i.e. Aug, Sept, or Oct
mmmm – the long month name i.e. August, September, or October
d – the numeric value for the date i.e. 8, 9, or 10
dd – the 2 digit padded numeric value for the date i.e. 08, 09, or 10
yy – the 2 digit century i.e. 08, 09, or 10
yyy – the 4 digit century i.e. 2008, 2009, or 2010
ww – the short day of the week i.e. Sun, Mon, or Tue
www – the full name for the day of the week i.e. Sunday, Monday, or Tuesday
Any other characters are considered delimiters and are not evaluated as part of the date.
So the date 01-Jan-2011 would use the format “dd-mmm-yyy”
The templates are callable templates. There are internal templates that begin with an underscore. The main templates (with no underscore) are mostly wrappers around the internal templates and provide the ability to call the templates with strings instead of structured xml dates – I’ll explain the main ones below:
FormatDate – takes in a date string and returns a new date string in the specified format. It accepts 3 parameters: inputFormatString, outputFormatString, & dateTimeString. The inputFormatString specifies the format of the dateTimeString parameter. The outputFormatString specifies the desired format of the returned date. The dateTimeString contains the actual date to be formatted (pretty obvious I would think, but you never know).
ParseDate – parses a date and returns a new XML structure containing the raw date values. Input params are the format string and the date string.
CalculateDayOfWeek – parses a date and returns the numeric day of the week. Sunday = 1, Monday = 2, etc…
** The rest of these follow a similar format and return a number or formatted string so I will not include the examples or results for the sake of brevity…
CalculateTotalDaysSinceEpoch – parses a date and returns the number of days since January 1, 0000.
CalculateTotalSecondsSinceEpoch – this method is somewhat pointless since the script does not take into account time – only dates. So right now this just takes the DaysSinceEpoch and multiplies it by the seconds in a day.
MonthShortString – returns the short name of the provided month. i.e. “Jan”, “Feb”…
MonthLongString – returns the full name of the provided month. i.e. “January”, “February”…
MonthFromShortName – returns the month number from the provided short name.
MonthFromLongName – returns the month number from the provided long name.
WeekDayLongName – returns the full name of the provided weekday number.
WeekDayShortName – returns the short name of the provided weekday number.
WeekDayFromLongName – returns the day number from the full weekday name.
WeekDayFromShortName – returns the day number from the short weekday name.
You can find the full XSL code along with a test stylesheet and some sample data here.
Recently while debugging a web part in SharePoint 2010, I received this error message. I had never seen it before but after doing some searching, I found that apparently this happens quite a lot in SharePoint.
First thing I tried was to open the page in ?contents=1 mode and found the following:
Once the erroneous web parts were removed, I redeployed my solution and added my new webpart onto the page, but alas, still getting the same error.
So, I decided to take a closer look at my code, more specifically, the list I was deploying, and the code used to query it. After more than a few hours of staring at the answer (and even almost giving up and putting a post for help on stackoverflow.com) I noticed this:
<Where> <FieldRef Name="Source" /> <Value Type="Text">http://dev01:80/Pages/default.aspx</Value> </Where>
Damn! Poor CAML syntax – the bane of my existance. After changing the CAML so it was formatted properly:
<Where> <Eq> <FieldRef Name="Source" /> <Value Type="Text">http://dev01:80/Pages/default.aspx</Value> </Eq> </Where>
Everything started working as it should. Why Microsoft decided to stick us with this crappy query language then provide us with no means of validating it and give us completely ambiguous errors and COM errors on top of it all (or below it all depending on how you look at it) just makes me question why I ever decided to use Microsoft products to begin with.