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!

Content Type ID's

You are right - we all know how Content Type Id's are constructred. But let me post it here again:

The first part of a CT ID is based on a hexadecimal number that identifies its base content type (see list below) followed by 00 as a seperator. The last part of a CT ID is a GUID that uniquely identifies the CT. For each level o inheritance the seperator will be added to the end of the ID plus another GUID.

So, that's easy and actually not the reason why I wrote this entry. Main reason is, that I always have to look up the base intheritance ID's. So the list below will be my point of contact to get the right ID's easily. Maybe you can use it too:


Basic Types:

• 0x System
• 0x01 Item

List Types:

• 0x0102 Event
• 0x0103 Issue
• 0x0104 Announcement
• 0x0105 Link
• 0x0106 Contact
• 0x0107 Message
• 0x0108 Task
• 0x0110 BlogPost
• 0x0111 BlogComment

Document Types:

• 0x0101 Document
• 0x010101 Form
• 0x010102 Picture
• 0x010108 Wiki Document
• 0x010109 Basic Page
• 0x01010901 WebPart Page

Folder Types:

• 0x0120 Folder
• 0x012001 RootOfList
• 0x012002 Discussion

Microsoft TechDays Switzerland 2008

This years TechDays were taking place Wed and Thursday this week in Basel. The Sessions and Tracks were very interesting and again something no .NET developer should miss!

About the location - hmmm, the whole thing was taking place in sporthalls in the underground and yes I also think there could be better and nicer places for this event - maybe next year.

For all who did not have time to go to the TechDays I want to say that beginning of next week you will be able to download all presentations from the TechDays Homepage!!! I really recommend the Developer Tracks!!! Have a look

As usual, here are my "Best of TechDays":

Best Session:
Visual Studio 2008 für Web Anwendun­gen
from Sacha P. Corti

Best Speaker:
Ingo Rammer
thinktecture

Best News:
Future of distributed .NET Solutions
from Chris Horrocks



So let's stay tunned!

Microsoft AJAX Extensions and SharePoint Webparts - what a great team ;-)

Alright, here is a new topic for all of you guys need to include AJAX-functionality into your SharePoint Webparts. Just to say it right away: It is a long and anoying way - but when you finally got your AJAX enabled webpart up and running - your feeeeeeeelllll great!!!

So, lets's keep it short... these are the steps you need to get the Microsoft AJAX Extensions running on your SharePoint installation:

1. Download and Install the Microsoft ASP.NET AJAX Exentsions from http://www.microsoft.com/downloads/details.aspx?FamilyID=ca9d90fa-e8c9-42e3-aa19-08e2c027f5d6&displaylang=en
2. Follow the steps posted from Mike Ammerlaan to configure the web.config file(s) of your SharePoint Web Application - I recommend to do only the web.config bits and pieces explained on this blog: http://sharepoint.microsoft.com/blogs/mike/Lists/Posts/Post.aspx?ID=3
3. As you know, ASP.NET AJAX Framwork needs a Script Manager Object on each side hosting AJAX functionality. Even if the following Function works for most cases, I recommend you put the ScriptManager to your Master Page(s) - I really do. If you dont want to, you can try the following method (call it during your CreateChildControls activity to ensure that at least one Script Manager is present and registred):

private void EnsureScriptManager(){

ScriptManager scriptManager = ScriptManager.GetCurrent(this.Page);

if (scriptManager == null) {

scriptManager = new ScriptManager();

scriptManager.EnablePartialRendering = true; this.Controls.AddAt(0, scriptManager);

}

}

Et voila - AJAX is ready to be used... but one thing is left to say concerning the Update Panel (which you will most probably use):

1. To fix another issue with SharePoint and the Update Panel, I wrote another function to ensure this fix. Same as the previous function you can call it during the CreateChildControls method:

public static void EnsureUpdatePanelFixups(WebControl Parent)
{
// PostBack Fix
// Found here: http://www.capdes.com/2007/02/microsoft_office_sharepoint_se.html
Parent.Page.ClientScript.RegisterStartupScript(typeof(WebControl), "PostbackFix", "_spOriginalFormAction = document.forms[0].action;", true);

// Panel Fixup
if (Parent.Page.Form != null)
{
if (Parent.Page.Form != null)
{
string formOnSubmitAtt = Parent.Page.Form.Attributes["onsubmit"];
if (!string.IsNullOrEmpty(formOnSubmitAtt) && formOnSubmitAtt == "return _spFormOnSubmitWrapper();")
{
Parent.Page.Form.Attributes["onsubmit"] = "_spFormOnSubmitWrapper();";
}
}
}
}

Hope that helps to give you a first go on Microsoft APS.NET AJAX-enabled Webparts! As you will see, there are more traps and unbelievable shity things you will encounter during your AJAX implementation - but you will finally be very very pleased with the new User Experience!

Have FUN

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.

Get rid of SharePoint Error page

Sometimes it is necessary to get the real ASP.NET Error message instead of a nice formated SharePoint error message like this one:



You can change the web.config file of your SharePoint site to display ASP.NET error messages by changing the following

• <sharepoint><safemode maxcontrols="200"><callstack="true" ...
• AND <system.web><customerrors mode="Off" ...

Et Voila:

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)