Thursday, May 17, 2012
This afternoon, I was getting quite frustrated because I was working on a .master file in Visual Studio and all of the code folding and Intellisense was missing! It seems that when the .master file is opened by double-clicking it in the Solution Explorer, these items will be missing. To resolve the problem, right-click the .master file and select View Code!
Monday, March 19, 2012
Ever had a need to find all of the files in a site collection that link to a specific file? A colleague of mine made an excellent find a few weeks ago and taught me this gem from the SharePoint object model. He had a need to find all publishing page layouts on a site and catalog which were being used and which weren’t. Check out his post here: SharePoint Fix: Powershell script to get SharePoint Page Layouts inventory and its usage across site collection
Tuesday, March 13, 2012
I have a requirement for a DelegateControl where I need the child candidate control to render a link that opens in a new window in certain instances of the DelegateControl and open the link in the same window otherwise. The design that made the most sense to me was to use the same code for the child control to compute and render the link in both circumstances and pass a boolean parameter,
OpenLinkInNewWindow, to control the target of the link.
The reader might be wondering why I need a control just to render a link. For the purposes of this article, just assume that the control has some built-in intelligence to render a link that cannot otherwise be easily generated!
But how would I pass a parameter to the child control that the DelegateControl uses? Unfortunately, the DelegateControl itself does not have the ability to accept parameters. However, the Control element that defines child controls for a DelegateControl, within the elements.xml file for a feature, does have the ability to accept parameters. Perfect!
To define parameters for a control, one can setup property name/value pairs using the Property element, which is a child of the Control element. It’s pretty straightforward!
Say I have an application page, master page, etc. that needs to put the my fancy link-generating control in two separate places: one opens the link in a new window and one opens the link in the same window. In my page’s ASP.NET code, I have my two separate DelegateControls. I give each DelegateControl its own unique ControlId so that I can differentiate between the two.
With the above DelegateControls, I can use the first one wherever I need the link to open in a new window and the second wherever I need the link to open in the same window.
I would then define the following in the elements.xml file within the feature that adds the children to these DelegateControls.
Notice that I’m using the same control for both of the DelegateControls. I’m only changing the value of the
OpenLinkInNewWindow parameter. This will use the same code in both DelegateControls to render the desired link. This allows me to use the LinkNewWindow DelegateControl wherever I want the link opened in a new window and the LinkSameWindow DelegateControl wherever I want the link opened in the same window.
Update: Adding parameters to custom controls
After sharing this article, I had a few colleagues suggest that I add a quick update around how to allow custom controls to accept parameters in the method described above. Parameters for a control can be created by using public properties defined on the control.
As long as the property is public, one can use the method outlined in this article to pass parameters when the control is used with a DelegateControl. If used in a more traditional context on an ASP.NET page, the public property could be used directly in the source code as follows.
There are several attributes that can decorate the public property to enhance its functionality as a property of the control. See the Attributes Applied to Public Properties section of the Metadata Attributes for Custom Server Controls article on MSDN for details.
Thursday, March 8, 2012
I was in the middle of a SharePoint demo this morning, was typing some input, and all of the sudden my development server was going crazy! It turns out to be a problem I’ve encountered many times before. The “e” key started Windows Explorer. The “r” key started the Run dialog. The list goes on. It’s so frustrating!
The first thing to check is StickyKeys, but being in the midst of a demo and quite certain I was not fiddling with my Shift key, I knew that wasn’t the culprit this time.
I researched a bit and found two potential solutions:
The second solution worked for me and cleared up the issue immediately! Hopefully this little tidbit will help someone else; perhaps myself at a later date!
Monday, February 6, 2012
I was introduced to the SharePoint Diagnostic Studio 2010 at the Microsoft SharePoint Conference 2011 in Anaheim, CA. I was very excited about its capabilities and have just gotten around to testing it in the last couple of days.
After configuring PowerShell remoting between my laptop and my development server, I set out to create a new project in the SharePoint Diagnostic Studio and see what it could do. Upon creating a new project, I entered my credentials. After a few moments, I received the following message.
It appears the new project installation was not successful. Click OK to see the error message
After clicking OK, the error log is opened. If it does not open for you, my log was at
%HOMEPATH%\Documents\SharePoint Diagnostic Studio\Server Extensions\Error.log In the error log, I saw the following message.
Logon failure: unknown user name or bad password.
After getting quite paranoid about being up too early in the morning and perhaps not remembering any of my passwords, I started to investigate things on the server to see if I could figure out what was going on. What I found has to do with my configuration of CredSSP authentication.
With CredSSP authentication, there are two preferred/secure ways of submitting credentials: Kerberos authentication and Certificates. These required extra configuration of PowerShell remoting that I haven’t quite gotten to just yet. Therefore, my remoting capability was relying on the third and less secure way of submitting credentials: NTLM.
It turns out, after investigating my server’s security log, the SharePoint Diagnostic Studio (or perhaps the underlying PowerShell commands) are attempting to first authenticate using Kerberos. That fails and I would expect that since I didn’t do all of the necessary configuration for Kerberos to work. However, it then falls back to NTLM. To my surprise it does not use the credentials I had specified. Rather, it was using my local laptop credentials!
To trick any application in to sending other credentials when it wants to send the credentials of the currently logged in user, you can use the Runas command which allows one to execute any program under another user. For this instance, SharePoint Diagnostic Studio shouldn’t run under the remote account. It should run under the local account, but use the remote account for any remote access. Thankfully, Runas has just such a provision - its /netonly switch! The following command will open SharePoint Diagnostic Studio under the local account while using the remote account to access the remote server.
runas /netonly /user:DOMAIN\USERNAME "C:\Program Files\Microsoft\SharePoint 2010 Administration Toolkit\SPDIAG.EXE"
(The Runas command will ask for a password before launching SharePoint Diagnostic Studio.)