Strange issue with deployment of custom editform.aspx

I had the same issue (see below) a couple of days ago and spent a couple of hours on finding the reason for it

Here the whole thread with the detailed Solution Description:

http://forums.microsoft.com/technet/ShowPost.aspx?siteid=17&postid=3154005

Problem:
Input string was not in a correct format. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.FormatException: Input string was not in a correct format.Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [FormatException: Input string was not in a correct format.] System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) +2755599 System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) +112 System.Convert.ToInt32(String value, IFormatProvider provider) +44 Microsoft.SharePoint.WebControls.ItemHiddenVersion.OnLoad(EventArgs e) +253 System.Web.UI.Control.LoadRecursive() +47 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Control.LoadRecursive() +131 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1436

Solution:
Instead of setting the Zone-Visibility to false, add a DIV around your zone and just hide the DIV with setting style="visibility: hidden". This way round the necessary information will be rendered to the page but not shown to the user. That's it - fixed!

The security validation for this page is invalid. Click Back in your Webbrowser, refresh the page, and try your operation again.

If you need to work with SPSecurity.RunWithElevatedPrivilegs() to do for example Site or Web manipulations (the normal user has no rights to do it), you run sometimes into the following error:

"The security validation for this page is invalid. Click Back in your Webbrowser, refresh the page, and try your operation again."

Now, depending on what operation you want to do exactly, this can be solved by

a) Setting SPWeb.AllowUnsafeUpdates = true and/or
b) turning SPWebApplication.FormDigestSettings.Enabled off

Note that I really recommend to set both values back to AllowUnsafeUpdates = false and FormDigestSettings.Enabled = false after you did your stuff. If not you will leave (especially with having Security Validation turned off) a big security hole.

Boolean parameters in SharePoint definition files are CASE-SENSITIVE, crazy!

This is real SharePoint crap!!!

I just found out, that boolean Parameters in Definition Files (like List Definition, Content Type Definition, Site Columns Definition et cetera- in general all schema.xml definition files) are CASE SENSITIVE!

One example:
<Field
ID="{...}"
Required="True"
/>

This will not work. The Field will not be defined as required. Reasons: SharePoint understands only TRUE / FALSE values written in capital letters - everything else (including True or true) will be ignored and the default setting will be taken (in case of Required the default is false).

In make our example work:
<Field
ID="{...}"
Required="TRUE"
/>

This issue applies also to all other boolean parameters, like
Hidden="TRUE" or FROMBASETYPE="TRUE".

This is something I have never seen before... anyway - that's SharePoint!!!

Connected Webparts Lifecycle in detail

The list below shows you what is going on while your connected Webparts get "alive":

• Begin PreInit
• End PreInit
• Begin Init
• End Init
• Begin InitComplete
• End InitComplete
• Begin LoadState
• Provider: CreateChildControls
• End LoadState
• Begin ProcessPostData
• Consumer: CreateChildControls
• End ProcessPostData
• Begin PreLoad
• End PreLoad
• Begin Load
• Provider: OnLoad
• Consumer: OnLoad
• End Load
• Begin ProcessPostDataSecondTry
• End ProcessPostDataSecondTry
• Begin Raise ChangedEvents
• End Raise ChangedEvents
• Begin Raise PostBackEvent
• Provider: Button Click Event Method is called
• End Raise PostBackEvent
• Begin LoadComplete
• Provider: Connection Provider Method is called
• Consumer: Connection Consumer Method is called
• End LoadComplete
• Begin PreRender
• Provider: OnPreRender
• Consumer: OnPreRender
• End PreRender
• Begin PreRenderComplete
• End PreRenderComplete
• Provider: SaveViewState
• Consumer: SaveViewState
• Begin SaveState
• Provider: SaveViewState
• Consumer: SaveViewState
• End SaveState
• Begin SaveStateComplete
• End SaveStateComplete
• Begin Render
• Provider: RenderControl
• Provider: Render
• Provider: RenderBeginTag
• Provider: RenderContents
• Provider: RenderEndTag
• Consumer: RenderControl
• Consumer: Render
• Consumer: RenderBeginTag
• Consumer: RenderContents
• Consumer: RenderEndTag

Hidding Title Field in your Custom List Definition

Most of the time you want to get rid of the anyoing Default Field 'Title' you automatically get from the the Base List (Custom List) you are using in your Custom List Definition. Now there is not really a way to remove or delete this field, but you can hide it from your List by using the following tag:

<Field
ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}"
Name="Title"
StaticName="Title"
DisplayName="Title"
Type="Text"
FromBaseType="TRUE"
Required="FALSE"
Hidden="TRUE"
SourceID="http://schemas.microsoft.com/sharepoint/v3"
/>

Note, that I tried to hide the Title Field by just applying the Hidden="True" parameter. That did not work. I really had to provide FromBaseType="True" and Required="False" as well to make it work. Hope that helps you if you get in troubles trying to hide the field.

HRESULT: 0x81070201 Exception

Okay okay, this is actually something very basic, but it happend now a couple of times to me. If you work on a Feature that defines a custom SharePoint List, you can run into the following Error while activating it (in this case during Site Provisioning by definitions in onet.xml):

The element 'MyList' of type 'ListInstance' for feature 'MyListFeature' (id: 794958c5-fede-4e1f-aa96-d9fcd087945e) threw an exception during activation: Exception from HRESULT: 0x81070201

The reason for this error is, that SharePoint can't find the related schema.xml file for the list to define. This can happen, if

• You simply forgot to write an schema.xml file


• or, what is more realistic, the Name Attribute in ListTemplate is not the same as the Folder Name you have the schema.xml File stored in.

The Name-value of the ListTemplate tag must match the name of the folder you have your schema.xml file stored in:


<ListTemplate
Name="MyListDefinition"
Category="Custom Lists"
DisplayName="MyList"
...

Webpart beeing Provider and Consumer at the same time

This is basically a easy task to do, but the first time I really had to create such a webpart I made a tiny mistake during the implementation of the Provider/Consumer Interfaces and I ran into one of this terrible SharePoint errors.

The Problem:
I created a Webpart (based on System.Web.UI.WebControls.WebParts.WebPart) ...no problem
I added the bits needed to Consume from another WebPart (I have to say that I was using a own defined Interface, pretty simple one) ...no problem
I implemented another own defined Interface to act as a Provider WebPart for other webparts too... no problem
Building Solution, deploying it, adding the Webparts to a page ...no problem
Connecting my Webpart to a Provier Webpart ...no problem
Now, connecting a consumer to my Webpart... BIG PROBLEM!

The message I got trying to connect the a consumer webpart to my webpart was pretty strange: "There is a problem with one ore more connections, please check one of the webparts for more details" -> but there was no information to find -> thanks SharePoint...

anyway, I tried a hell of things till I found out what was actually the problem.

The Solution:
It is quit easy - To act as a Provider and Consumer Webpart at the same type, in the Consumer- as well as in the Provider-Implementation, the ConnectionProviderAttribute ID must be defined. I usually just defined the DisplayName by taking the first overload of ConnectionProvider. But in case of having multiple ways of communication, the provider and consumer attributes muts be uniquely signed.

Does not work:
[ConnectionProvider("A parameter value")]
public IMyProvider GetMyProvider()
{
return this;
}


Works:
[ConnectionProvider("A parameter value","ParamValue1")]
public IMyProvider GetMyProvider()
{
return this;
}

In the example above, the Provider Implementation gets a unique ID called "ParamValue1". However, note that the consuming Webpart must use the same ID-value to establish the connection. Otherwise, it will not work.

New Blog

Hi and welcome to my new blog.

Since the beginning of 2008 I am working for a new company. So I thought: New Company - New Blog!

In this BLOG I will mainly write about my daily work, which is all about developing Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS) solutions for customers in Switzerland.

Hope to server you soon with some interesting posts!

Have fun
Umhambi (Xhosa: Traveler)