Glenn Block of Microsoft has requested your thoughts on developing with SharePoint. You can find the survey here and more information on Glenn’s blog here. Please note most of the survey is stacked ranking - confused me at the beginning.

I wrote a post listing steps for debugging assemblies located in the GAC. Today I ran into an issue, when I ran Start-Run-%SYSTEMROOT%AssemblyGAC, where the folder which contains my DLL was not available. After digging around, it appears the assembly is in the GAC but isn’t in the GAC.

Anyway, I poked around Visual Studio and found an improved option.

1. Open Visual Studio
2. Open Tools-Options and navigate to the Debugging item
3. Uncheck the option “Enable Just My Code (Managed only)”
4. Select Debug-Attach to Process.
5. Select the correct w3wp process. To know the correct w3wp process, see this post.
6. Set breakpoints accordingly.

Update: Doug Ware has a similar post - “great minds think alike”. It contains a little more information and pictures. Worth checking out.

Update: Please see this post for a better alternative.

I have been creating feature receivers which I installed to the GAC. Of course I ran into issues and needed to debug the code. Below are the steps I ran through to do so:

1. Install the assembly to the GAC. There are a few ways of doing this. First, create a WSP file which installs the assembly to the GAC. Second, you can use gacutil.exe to install it.
2. Select Start - Run and type in %SYSTEMROOT%\Assembly\GAC_MSIL
3. Open the folder which contains the DLL.
4. Open the folder with the version number and public key you are interested in.
5. Open Visual Studio 2005 or Visual Studio 2008.
6. In the Solution Explorer, right-click on the solution and select Properties.
7. On the Build tab, set the Output Path to the folder which contains the DLL (the folder in step #4).
8. Build the project. This will copy in the PDB file to the GAC folder.
9. Select Debug-Attach to Process.
10. Select the correct w3wp process. To know the correct w3wp process, see this post.
11. Set breakpoints accordingly.
12. Execute code by activating/deactivating the feature in browser.

Note: I need to do some more research on this but the breakpoints were not hit if I activated/deactivated the feature using STSADM. Breakpoints were only hit when I activated/deactivated the feature in the browser. Just something to be aware of.

Today I ran into a frustrating issue. I was creating some custom site definitions and when I attempted to provision a site, I would get the “404 Not Found” error. Instead of creating a default.aspx, I created several derivatives with different names (e.g. defaultxxxxx.aspx). The issue was in the ONET.XML file in the modules section, I referenced the correct URL but did not give it a name.

As a way to learn the SharePoint Object Model, I decided to create an application which will display all items (e.g. Sites, Subsites, Content Types, Features, Fields, Lists, Users, etc.) for a top-level site. I know there are other ones out there (SharePoint Inspector, Feature Explorer, etc.) but they don’t have all the features I want (I have ideas!) and what fun is it using someone else’s when you can create your own.

Read the rest of this entry »

I ran into this issue a few days ago. “Essential SharePoint 2007” had a note on the subject.

SharePoint sites cannot contain the following characters:

\ / : * ? ” < > | # { } % & <TAB>

Files uploaded to SharePoint cannot contain the following characters:

: # % & * : < > ? \ { | } ~

BTW, ESP2K7 is an excellent book. Little on development - higher level topics instead - recommended nonetheless.

Today I attempted to edit the default.master file found in the Master Page Gallery by selecting the “Edit in Microsoft Office SharePoint Designer” option. I received the following error:

“The document could not be opened for editing. A Windows Sharepoint Services compatible application could not be found to edit the document.”

It seemed I had a mismatch of Office 2003/Office 2007 applications installed. I checked the list of installed applications and didn’t find any specific to Office 2003. Anyway, to fix, install the following hotfix (will require a reboot).

http://support.microsoft.com/kb/938888

Below is a list of steps to turn off SharePoint custom error messages so you can see the “true” ASP.NET error message along with the callstack/stack trace. I would recommend only making the following changes in a development environment - not production.

1. Navigate to the site directory.
2. Backup web.config.
3. Open web.config.
4. Switch Custom Errors off. Search for “customErrors” and set the value to “Off” instead of “On”. You can also set the value to “RemoteOnly” to troubleshoot a production issue.
5. Enable CallStack. Search for “CallStack” and set the value to “true” instead of “false”.
6. Save web.config.

1. Type Windows Key + Break to bring up the System Properties dialog.
2. Click the Advanced tab.
3. Click the Environment Variables button.
4. In System Variables, scroll down and highlight the Path Variable.
5. Click the Edit button.
6. In the Variable Value text box, go to the end of the entry and type in a semicolon.
7. Type in the following: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin
8. Click the OK button in the Edit System Variable dialog.
9. Click the OK button in the Environment Variables dialog.
10. Click the OK button in the System Properties dialog.
11. Open a command prompt and type in stsadm to test your work.

Today, while messing around with a SharePoint Hello World Workflow project, I ran into an issue where the code snippets for feature.xml and workflow.xml files went missing in Visual Studio 2005. I found this link.

Steps to Fix:

1. In Visual Studio 2005, on the Tools menu, click Code Snippets Manager.
2. Change the language to XML.
3. Add [System]:\Program Files\Microsoft Visual Studio 8\Xml\1033\Snippets\Windows SharePoint Services Workflow to your snippets.