Monday, September 19, 2011
SharePoint 2007 workflow activities disabled in Visual Studio 2010 toolbox
As it turned out (after comparing the project file with another one where the toolbox was available) I was mssing a ProjectTypeGuid ({F8810EC1-6754-47FC-A15F-DFABD2E3FA90}) in my .csproj file
EDIT: a list of know ProjectTypeGuids can be found here: http://www.mztools.com/articles/2008/MZ2008017.aspx
Friday, September 16, 2011
caml.net.intellisense - Making SharePoint development a little easier
Download here: http://visualstudiogallery.msdn.microsoft.com/15055544-fda0-42db-a603-6dc32ed26fde
The result:
Thursday, September 15, 2011
Windows Search and Xml files
For example, if you have the following xml file:
<myelement attrib="myattrib">You will be able to find it by searching for “myelementext”, but searching on any of the terms below will fail
myelementtext
</myelement>
- <myelement
- "<myelement"
- \<myelement
- "\<myelement"
- %myelement
- ?myelement
- [<]myelement
- xpath:\\myelement
To have all text in an XML file indexed, we need to assign XML extension to use the plain text filter.
This is (currently) not possible with the UI, so you will need to modify the registry.
Navigate to HKEY_CLASSES_ROOT\.xml\PersistentHandler and change the default value to {5e941d80-bf96-11cd-b579-08002b30bfeb}
You will have to rebuild the index (Control Panel / Indexing options / Advanced / Rebuild) to re-index the xml files.
Copy the lines below into a file with a .reg extension and double click to update the registry for you.
Windows Registry Editor Version 5.00To verify that the 'plain text filter' is being used, go to 'Control Panel', 'Indexing Option'. Select Advanced and on the 'File Types' tab, verify that the 'Plain Text Filter' is being used for the 'xml ' extension
[HKEY_CLASSES_ROOT\.xml\PersistentHandler]
@="{5e941d80-bf96-11cd-b579-08002b30bfeb}"
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.xslt\PersistentHandler]
@="{5e941d80-bf96-11cd-b579-08002b30bfeb}"
Thursday, September 8, 2011
‘no connection’ when trying to view another user’s calendar – free/busy information (exchange 2010)
A while ago, the company I currently work for updated their servers to Exchange 2010. Ever since, I was unable to view other people’s calendar and free/busy information. The only error I got was a 'no connection’ message in the calendar tab.
I was using Outlook 2010 on a computer that was NOT part of the domain.
When searching the internet, I noticed that I wasn’t the only one suffering from this behavior, but I couldn’t find an answer for the problem.
I turned on logging in Outlook (File – Options – Advanced – Enable troubleshooting logging) and found that the log file (%temp%\olkdisc.log) was filled with error from the Autodiscover service)
This led me to this Outlook 2007 article on TechNet which explains the relationship between the Autodiscover service and the Availability service:
The Availability service for Microsoft Exchange Server 2007 provides calendar information for your users. This information is known as free/busy information. The Autodiscover service provides information for the Availability service by locating and providing the external and internal URLs for the Outlook 2007 client. If your Microsoft Office Outlook 2007 users cannot view calendar information for other Outlook 2007 users in your Exchange 2007 environment, the problem may involve a failure in either the Autodiscover service or the Availability service.
The article provides the following steps to test the Autodiscover service (the article is for Outlook 2007, but the steps are the same for Outlook 2010):
- While Outlook 2007 is running, hold down the CTRL key, right-click the Outlook icon in the notification area, and then select Test E-mail AutoConfiguration.
- Verify that the correct e-mail address is in the box next to E-mail Address.
- Clear the check boxes next to Use Guessmart and Secure Guessmart Authentication.
- On the Test E-mail AutoConfiguration page, verify that the check box next to Use AutoDiscover is selected, and then click the Test button.
I my case, the test failed because of the Autodiscover services could not be reached.
As it turned out, the Proxy server could not reach the Autodiscover service. I used Internet Explorer to add the url to the ‘Local Intranet’ zone, so the proxy server would be bypassed and everything worked perfectly.