The form template cannot be opened, because the system administrator has disabled opening form templates that require full trust.

This was being caused by a policy on the user's desktop


"RunFullTrustSolutions" -> DWORD = 0

HKEY_CURRENT_USERS/Software/Policies/Microsoft/Office/12.0/InfoPath/Security".

Source:
http://social.msdn.microsoft.com/Forums/en-US/99280dee-5b26-48a7-b444-9e81f03ae012/the-form-template-cannot-be-opened-because-the-system-administrator-has-disabled-opening-form?forum=sharepointcustomizationlegacy

InfoPath posting anonymously

This theme seems to come up a lot. I did some cursory searching based on a user's request
to allow anonymous users to post to a document library.

1. http://tim-sharepoint.blogspot.com/2008/10/sharepoint-anonymous-infopath-forms.html
This solution is a more classic approach using the code behind in VSTA.  This allows us to encapsulate the request with a service account to make the submission for the anonymous user.


2. http://claytoncobb.wordpress.com/2011/06/03/infopath-allowing-anonymous-users-to-submit-forms-in-sharepoint-2010/
   This solution relies on InfoPath 2010 tight integration and expanded capabilities of SP 2010 Enterprise.
3. http://sshela.wordpress.com/2011/05/13/how-to-enable-anonymous-access-to-a-infopath-forms-library/

Javascript blocks in webparts not working in SharePoint 2010.

Difference between RegisterStartupScript and RegisterClientScriptBlock?

Ouch, this took me by surprise.  I have been fighting with two webparts which were migrated from 2007 to 2010.  They used some simple javascript to change div tag blocks from none to display.  They worked great in 2007 but failed in 2010. 

Issue:
Div tags and javascript functions are inserted into page where the webpart was hosted.  The onclick events would fire but not find the function references.  Thus the div tag functionality did not work in 2010.

Solution:
In the onload event changed Page.ClientScript.RegisterClientScriptBlock  to Page.ClientScript.RegisterStartupScript.

Explanation:
During the onload event of the webpart, the Page.ClientScript.RegisterClientScriptBlock was used to insert the javascript into the page.  This puts the code base at the top of the page right after the viewstate variables.  This is also where all of the 2010 ribbon controls are at.  This collision was the reason the webparts could not see the javascript blocks.  Changing the Page.ClientScript.RegisterClientScriptBlock to Page.ClientScript.RegisterStartupScript puts the script block after all the elements and right before the close form tag.

Source:
http://stackoverflow.com/questions/666519/difference-between-registerstartupscript-and-registerclientscriptblock

Webpart deployment gives error - Could not load file or assembly '' or one of its dependencies

I was trying to upgrade 2007 webpart to 2010.  I used the VS empty sp template and added my features and webpart.  I use the argotic libraries to support rss feeds.  These 3rd party dependencies had been added into the project and it compiled and deployed.  After each deployment, I would try and use the webpart and it would fail each time my part tried to hit any of those dlls.  I could not figure why this was not working.  I had the controls deployed to the GAC but was still getting the error.  Then I ran across this post (http://stackoverflow.com/questions/8406037/could-not-load-file-or-assembly-or-one-of-its-dependencies).

Solution:
Add the dependencies to the package deployment and then you are guaranteed to always have the dlls you need.  In your SharePoint 2010 project,

1. Open Package.package from Package folder in SharePoint project.
2. Click Advanced in bottom area.
3. Click Add and chose which type of assembly you want to add.
4. In dialog select dll file, chec GAC or BIN, add safe controls and class resources entries if required. Click Ok.