.NET FOLLOWER

    If an unexpected error occurs on a SharePoint environment, by default, you get a meaningless error message as the following: An unexpected error has occurred. Despite the given error message is considered as friendly one for users, we as developers want to have more information to detect the reason. SharePoint is built on ASP.Net technology, it means we can enable the detailed error message and, in addition, displaying of call-stack by changing some settings in a web.config file. We need to find the node customErrors and change its mode to “Off”, which specifies that custom errors are disabled and the detailed errors are shown to the local and remote clients. Then we need to find the node SafeMode and change its CallStack to “true”. CallStack attribute defines whether a call-stack and an exception message are displayed when a system-level exception takes place while ASP.NET processes a request from the local and remote clients. The last step is to save the made changes. The nodes we are interested in are shown below:

Before:

<customErrors mode="On" />
<SafeMode MaxControls="200" CallStack="false" ... >

After:

<customErrors mode="Off" />
<SafeMode MaxControls="200" CallStack="true" ... >

The required web.config file containing main settings locates in \inetpub\wwwroot\wss\VirtualDirectories\<SHAREPOINT APP PORT NUMBER>. For SharePoint 2007 it’s usually enough to make changes in the given file only. As for SharePoint 2010, the changes also should be applied to a number of additional web.config files in 14 hive (\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14) of SharePoint 2010. If you make a search for web.config inside the 14 folder you likely will find more than 30 different files. I recommend firstly to make changes in web.config files locating in \14\TEMPLATE\ADMIN and \14\TEMPLATE\LAYOUTS and then check whether you still get not detailed error message. If so, continue making the changes file by file until the message will get more detailed.

Related posts:

• SharePoint: How to Restore a SharePoint Site from a Database Backup
• SharePoint: The specified SPContentDatabase has been upgraded to a newer version
• SharePoint: How to shrink transaction log file

    Deploying a .wsp-file on SharePoint 2010, you may stumble over the next error message:
Install-SPSolution : Admin SVC must be running in order to create deployment timer job.

How have I got it? In SharePoint 2010 Management Shell I had successfully performed the following command to upload my SP2010 solution package into the system:

Add-SPSolution "C:\WSPDeployment\My2010Solution.wsp"

Then I had tried to run the next one to deploy the uploaded solution:

Install-SPSolution -Identity My2010Solution.wsp -GACDeployment -AllWebApplications

and after that I received the mentioned error.

Now, how to fix it. It’s needed to go to Administrative Tools -> Services and manually start the service called SharePoint 2010 Administration. Not to have such error in the future, change service’s Startup type to Automatic.

Having made this, I run Install-SPSolution once again and received a new error:
A deployment or retraction is already under way for the solution “My2010Solution.wsp”, and only one deployment or retraction at a time is supported.

It looked like an appropriate deployment job was added to the list of timer jobs, but the attempt to execute the job failed due to unstarted SharePoint 2010 Administration service. I found a solution here. We need to cancel the deployment job by performing the next steps:

1. Grab the id of the job by running the command: stsadm -o enumdeployments. Yep, the old friend, stsadm helps us out 🙂 Look through the result, find the required deployment job and grab the id. The result should look like

   C:\...red\Web Server Extensions\14\BIN>stsadm -o enumdeployments
   
   <Deployments Count="1">
      <Deployment JobId="2de92a5f-6c70-4325-ac2c-293a34dd9c67">
         <Title>Microsoft SharePoint Foundation Solution Deployment for "My2010Solution.wsp"</Title>
         <Type>Deployment</Type>
         <State>Pending</State>
         <Schedule>12/16/2011 3:47 PM</Schedule>
         <File>My2010Solution.wsp</File>
         <ServerType>Front-end Web server</ServerType>
         <Target>http://mySPServer/</Target>
      </Deployment>
   </Deployments>
   

2. Using the found id, cancel the job by means of the command stsadm-o canceldeployment-id “found Job id”. For example, in my case it’s

   stsadm -o canceldeployment -id "2de92a5f-6c70-4325-ac2c-293a34dd9c67"

   If it succeed you get “Operation completed successfully” message.

3. Run again stsadm -o enumdeployments to make sure that the given deployment job disappeared

Ok, now you can repeat deployment of your solution, run Install-SPSolution again. The issues was overcome in my case.

    This post is about the same LookupField bug I faced in SharePoint 2007 and described here
http://dotnetfollower.com/wordpress/2011/02/sharepoint-lookupfield-bug/. Briefly, LookupField doesn’t save selected value after an “idle postback”. I’ve analyzed the code of LookupField control from SharePoint 2010, the bug still remains. The steps to reproduce are absolutely identical. They have changed a little bit method SetFieldControlValue (method, where the problem was), now it looks like the following:

private void SetFieldControlValue(object value)
{
    if ((this.m_value != value) || !this.m_hasValueSet)
    {
        this.Clear();
        this.m_value = value;
        this.m_hasValueSet = true;
        if (this.DataSource != null)
        {
            // some code is skipped
            if (this.m_tbx != null)
            {
                DataRowView view = null;
                if (this.m_selectedValueIndex >= 0)
                {
                    view = this.m_dataSource[this.m_selectedValueIndex];
                    this.m_tbx.Text = view["TextField"] as string;
                }
                if (this.Page != null)
                {
                    string str = "0";
                    if (this.m_selectedValueIndex >= 0) // (***) here is the problem
                    {
                        view = this.m_dataSource[this.m_selectedValueIndex];
                        str = ((int)view["ValueField"]).ToString(CultureInfo.InvariantCulture);
                    }
                    else if (this.Page.IsPostBack) // get picked value only if option stored in SPListItem is invalid (m_selectedValueIndex < 0)
                    {
                        str = this.Context.Request.Form[this.HiddenFieldName];
                        if (string.IsNullOrEmpty(str))
                        {
                            str = "0";
                        }
                    }
                    this.Page.ClientScript.RegisterHiddenField(this.HiddenFieldName, str);
                }
            }
        }
    }
}

     Despite changes, they still use m_selectedValueIndex to detect whether they should get value from the hidden html-feild or not. But I’m repeating myself, m_selectedValueIndex reflects the option stored in SPListItem, we shouldn’t take m_selectedValueIndex into account here. When SPListItem is being saving, SharePoint uses the Value property to get the option picked by user on the page. It’s more interesting that inside Value property they rightly get the value from hidden html-field and don’t analyze m_selectedValueIndex.

public override object Value
{
    get
    {
        this.EnsureChildControls();
        if (this.m_tbx != null)
        {
            if (this.Page.IsPostBack) // if it's postback, always get the picked value
            {
                string str = this.Context.Request.Form[this.HiddenFieldName];
                return (string.IsNullOrEmpty(str) ? 0 : int.Parse(str, CultureInfo.InstalledUICulture));
            }
            return  ((this.m_selectedValueIndex >= 0) ? this.m_selectedValueIndex : 0);
        }
        // some code is skipped
    }
}

     To eliminate the bug you still can use FixedLookupField from the previous post http://dotnetfollower.com/wordpress/2011/02/sharepoint-lookupfield-bug/

Related posts:

• SharePoint: LookupField bug