Just thought I would share a tip that I found on the usenet group: microsoft.public.sharepoint.windowsservices.development
and in particular a post made by Colin Byrne colinb@>flexnetconsult.co.uk

1. Add the field as XML

list.Fields.AddFieldAsXml("<Field DisplayName=\"NewField5\"
Type=\"Boolean\" Required=\"FALSE\" Name=\"NewField5\"
CanToggleHidden=\"TRUE\" Hidden=\"TRUE\"/>");

2. Set the internal CanToggleHidden property via reflection

If you want to use script tags for dynamic content in a master page, for example:

 <%= DateTime.Now %>

and you recieve the following error:

Include the following in your web.config file to resolve this issue:

Symptom:

Often times, developers in WSS3.0/MOSS2007 probably run across the issue where a web part is dropped on to a page
and then Sharepoint errors out for one reason or the other. Sometimes, the user is directed to a Web Part Maintenance page,
which helps the developer remove the offending web part from the page.

However, there is no way to get to this page from any easily available link.

Resolution:

In order to get to the Web Part Maintenance page for ANY sharepoint url, try the following trick.


a) Append the querystring ?contents=1 to the url in the browser as shown below.

b) The Web Part Maintenance page for the desired url can then be accessed, as seen here:

Hope this helps other developers.

- Rajiv

I just ran across the link for the  Microsoft Office Developer Center, which boasts small how-to videos and links to common development/deployment tasks.

This seems like a place that will prove useful to many WSS3.0/MOSS2007 developers in general. I thought it would be a good idea to share with as many developers as possible, to spread the knowledge around

Symptom:

We ran into a strange issue recently. We had deployed a signed DLL to the Global Assembly Cache (GAC), and assumed that it would be available to all applications on  the web server.

For some reason, it turned out that one of these DLLs in the GAC was not being resolved by our SharePoint application unless the dll was copied into the \bin folder of the application as well.

The above shows the error that the Sharepoint Application was throwing if the DLL was in the GAC only, but not copied over to the \bin folder of  the virtual.

Resolution:

After some research, we determined that we had to add a line to the web.config of our SharePoint web application, as follows:

The copy of the DLL could then be removed from the \bin folder leaving only the one copy in the GAC.

Hope this helps other developers.

- Rajiv

If you need PDF files in your search results, the steps listed by Stan Spotts in his post WSS 3.0BetaTR PDF search configuration and setup have been confirmed to work under WSS 3.0 RTM.

As an added bonus, WSS 3.0 RTM will actually show lines that contain your search term and highlight the term!

S.S. Ahmed has a detailed article that specifically for MOSS, but it is useful as well, especially for the instructions on getting the PDF icon to display: http://www.sharepointblogs.com/ssa/archive/2006/10/13/13812.aspx.

Nathan

Want to uninstall, then perform a clean installation of Office 2007 and WSS B2TR?  Think you can get away with running SharePoint.exe and have a perfectly working WSS?  Not so fast... After a wasted day of failed installs, a broken WSS Search Indexer, bluescreens, and yelling, we offer these tips to keep in mind when migrating, as well as our step-by-step process for a clean reinstallation.

Tips for installing:

• If you want WSS Search to work, you need the .NET v3 Framework RTM installed
• If you can't install the .NET v3 Framework on Windows 2003 Server or you get a "cryptographic services" error, try running regedit and set HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \  SystemCertificates \ TrustedPublisher \ Safer to 0.  The Sharepoint Configuration Wizard likes to set it back to 2.
• If you are running Sonic RecordNow to burn your ISOs, make sure you remove it from your startup or uninstall it, or you'll get a neverending bluescreen loop at startup!
• To remove startup items, I highly recommend Mike Lin's Startup Control Panel, found here: http://www.mlin.net/StartupCPL.shtml.
• Even after a WSS reinstall, it is possible for Web Applications to persist which will raise an error if you try to recreate the application.  Be sure you delete them in Central Admin -> Application Management -> Delete Web Application.

Steps for B2TR to RTM migration for Office 2007 and WSS 3.0:

1. Uninstall all Office 2007 applications, including Sharepoint Designer via Control Panel -> Add/Remove programs
2. Uninstall WSS B2TR via Control Panel -> Add/Remove programs.
3. Delete all Content Databases from your SQL server
4. Ensure the SAFER key in your registry is set to 0  (see tip above)
5. Install Office 2007
6. Install SharePoint Designer 2007
7. Install Visio 2007
8. Install Project 2007
9. Ensure the SAFER key in your registry is set to 0  (see tip above)
10. Remove .NET Framework v3 via Control Panel -> Add/Remove programs
11. Run the Microsoft .NET Framework 3.0 Uninstall Tool to clean up any other .NET Framework remnants.  Click YES or OK if you get any warnings during the uninstall- all the files you are being warned about (MSXML 6 for example) will be replaced when you install the latest .NET Framework.
12. Ensure the SAFER key in your registry is set to 0 (see tip above)
13. Install the .NET Framework 3.0 Redistributable (available at http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en).
14. Update the SAFER key in your registry (see tip above)

Hope this saves you some headaches.

Nathan

This is just a heads up to provide a very useful link about .NET provider models and some actual sample code from Microsoft that could be used not just in Sharepoint but in any .NET application.

Here's the link to the page on Microsoft MSDN where you can download sample code from.

ScottGu's blog entry here is also very helpful.

Hope that helps.

-Rajiv

Thought this may be useful. Here are the links to the WSS3 and MOSS2007 SDK Files.

WSS 3 SDK:

http://www.microsoft.com/downloads/details.aspx?FamilyID=05E0DD12-8394-402B-8936-A07FE8AFAFFD&displaylang=en

MOSS 2007 SDK:

http://www.microsoft.com/downloads/details.aspx?familyid=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en

- Rajiv

Thanks to Sage Kitamorn (the Sharepoint Search Program Manager) promptly responding to our call for help with search under forms authentication, and a response to our previous blog post from his colleague Avi, we have made some progress implementing WSS Search on a site using Forms Authentication. 

Search now returns results and performs UI Trimming as we will show below, but we have one outstanding issue. Anonymous search under forms authentication raises the following error:

"Your search cannot be completed because of a service error.  Try your search again or contact your administrator for more information."

While we have not found a workaround to fixing search for the anonymous user, below is a step-by-step guide for setting up a site with both anonymous and secure content and a functional search for authenticated users.  This guide assumes that you already have a search server configured correctly.

Note: Our custom provider is called "PassportMembershipProvider", not to be confused with other Microsoft authentication providers with the same name.

1. Create a new Web Application in Central Admin and select your Search Server.  We use port 12000.
2. Create a new Site Collection for the newly created Application.
3. Configure your site to support forms authentication.  This must be set correctly in the web.config of the application.  The web.config file in your application should contain the following entries:
   

   <!-- Add to the configuration node -->
   <connectionStrings>
     <add name="MembershipProviderDBConn" connectionString="Data Source=servername;
      Initial Catalog=dbname; User Id=userid; Password=userpassword;" />
   </connectionStrings>
   
   <!-- Add to the System.Web node-->
   <membership defaultProvider="PassportMembershipProvider">
      <providers>
        <remove name="PassportMembershipProvider" />
        <add name="PassportMembershipProvider" type="MyAssembly.PassporMembershipProvider, MyNamespace" applicationName="TestSite" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" passwordFormat="Hashed" connectionStringName="MembershipProviderDBConn" commandTimeout="45" />
     </providers>
   </membership>
   
   <roleManager defaultProvider="PassportRoleProvider" enabled="true">
      <providers>
         <remove name="PassportRoleProvider" />
         <add name="PassportRoleProvider" type="MyAssembly.PassporRoleProvider, MyNamespace, AppliedPassportMembershipProvider" applicationName="TestSite" connectionStringName="MembershipProviderDBConn" commandTimeout="45" />
      </providers>
   </roleManager>

   Note: Since our web application is setup to use Forms Authentication, we have to also set up Site Collection Administrators based on users from our custom data store. In order to do so, you would have to include the above entries in the web.config file of your Central Admin Application as well  (Do not include the <roleManager...> node in your Central Admin web.config, or else you will get errors when saving )
   
4. We were interested in supporting anonymous content in addition to secure content.  In order to support anonymous content, be sure to go to  Site Actions > Site Settings > Advanced Permissions > Settings > Anonymous Access, then select "Entire Web Site" for your site.
   
5. At this point, a second zone is needed with NTLM authentication for the search service to index correctly.  To create an extended zone, use the Central Admin > Application Management  > Create or extend Web Application, then select "Extend an existing Web application".  When extending your Web Application, you may select any open port and any available zone.  We selected the Custom zone, port 12001, and Allow Anonymous for our test site.
   
   At this point, our settings were as follows:

   
   Web Application with Default (forms) and Custom (NTLM) Zone

   
   The Default (forms) zone

   
   The Custom (NTLM) Zone

6. Confirm that the Search Crawling Account has Full Read policy for your application.

   

7. Since the search crawler only seems to index applications set up with NTLM authentication, you can also confirm that the search Database contains a Crawl Host List entry in the dbo.MSSCrawlHostList table for the extended zone (12001, in our case).  Sharepoint by design does not seem to index zones/sites with Forms authentication (note that there is no entry in the table for port 12000, which was our DEFAULT zone setup with our custom membership provider). 

   

   You should now get search results when logged in to your Forms authenticated site as seen in the image on the right, below.

   

   
   
   Note:  Our attempt at creating the site in the reverse order (i.e. using NTLM in the Default zone) did not work for us. 

- Rajiv

After creating a Sharepoint site using Forms Authentication (CustomMembershipProvider), search no longer appeared to work.  Running some analysis yielded the following discoveries:

• Search was confirmed to work as expected for our site with NTLM authentication mode enabled.  In the WSS_Search database, an entry was added to the dbo.MSSCrawlHostList matching the site's HostName, as expected.  After the service indexed the site, the SuccessCount column reported a nonzero value, and the ErrorCount column reported 0.  Entries were added to the dbo.MSSCrawlUrl table with accurate DisplayURL values.
  
  
• However, after switching the site authentication mode to Forms Authentication using our CustomMembershipProvider and CustomRoleProvider in Central Admin, searches no longer returned results.  After investigating, we noticed that all the entries in the dbo.MSSCrawlUrl table were immediately removed.  The HostName entry remained in the dbo.MSSCrawlHostList table, but the SuccessCount column reported 0, while ErrorCount was positive.

Based on these findings, it seems as though search is not available for any site that is not authenticated with Windows authentication.

We have not been able to find any other articles with a clear resolution to this issue, and feel that it has something to do with the service account used by the Search Service. 

 If anyone has had success with enabling search for sites using Forms Authentication, please let us know which solutions you have found to get around this issue. 

- Nathan and Rajiv

We have encountered several issues while trying to incorporate CustomMembershipProvider and CustomRoleProvider in WSS 2007 B2TR under Forms Authentication.  Most notably:

• Search does not work with forms authentication (separate post with more detail here)
• Forms authentication causes issues in Central Admin
• Anonymous Access is very difficult to set up for forms authentication.

Many similar concerns are discussed in the comments for the MSDN Blogs article "Configuring Multiple Authentication Providers" article so we've made a comment there, and hopefully someone will respond with some answers on the search issue.  In the meantime, these tips may help you with Forms Authentication providers:

ISSUE #1: Unknown Error in Central Admin working with Forms Authentication
If you have created a role provider, make SURE the <roleManager...> node is NOT in your Central Admin web.config.  This will work in a web.config for a Sharepoint site, but not for the Central Administration site.  Central Admin will only use your authentication provider to verify usernames when you select site administrators, so the role provider would never be used anyway.

ISSUE #2: WSS/MOSS throws an Unknown Error when creating a new Web Application or Site Collection under Forms Authentication
For creating ANY new website (forms or windows auth), you need to remove the <membership...> node from the Central Admin web.config.  To create a new Forms website, follow these steps:

1. Remove the <membership...> node from the Central Admin web.config.
2. Create your new web application and site collection in Central Admin, and set it to use Windows Authentication.  
3. Replace your Forms Provider's <membership...> node in the Central Admin web.config.
4. Now go back into Central Admin and set the Authentication Provider (Central Administration > Application > Authentication Providers) to Forms on your new site.
5. Your site should now work with your provider.

ISSUE #3: Unable to allow Anonymous Users under Forms Authentication
Actually, you can, it is just not easy or fun.  Here are all the steps you need to allow anonymous users on your site WITH Forms Authentication.

1. In Central Administration > Application > Authentication Providers, check the "Enable Anonymous Access" checkbox for your site.
2. Make sure the anonymous user (or Everyone if you're lazy) has read and script access to your site's folder using Windows security (the files are usually in inetpub\wwwroot\wss\VirtualDirectories\[port number]).  Be sure to set those permissions on all the child folders as well.
3. Now for the fun part. In Central admin, switch your site back to using Windows authentication.  Then, make sure your NTLM user is the site owner.
4. Log in to your site, and select Site Actions > Site Settings > Advanced Permissions > Settings > Anonymous Access.  If this is on Nothing, change it to "Entire Web Site".
5. Save this setting, then switch your site back to forms authentication in Central Admin.  You can not change the Anonymous Access radio buttons while in Forms authentication mode!

Hope this helps.  Good luck!

-Nathan and Rajiv