Recently I was trying to use the new "smart http" Git protocol. When I'd try to clone a repo I'd get the following:

A search on the Google and a little tinkering revealed the fix: git config --system http.sslcainfo \bin/curl-ca-bundle.crt

Evidentially the request message isn't guaranteed to be around by the time you get to your response code. I found out this the hard way when I was getting sporadic failures accessing properties of the IncomingWebRequestContext in response code. To get around this I just stashed info (While in request code) I was interested in, in the outgoing message properties. Then I retrieve these properties in my response code.

Using the outgoing message properties approach is pretty easy. To give you a little background, I have an error handler behavior that attaches a specified error handler to all channel dispatchers in a particular service. I also have a custom error handler that logs exceptions to a specified object that implemented a particular logging interface. This error handler passes the request http info to the logger. Originally I was directly accessing the IncomingWebRequestContext in the HandleError method of the error handler to get this request info and would sporadically get the error in the title. Now in my error handler behavior I'm adding a message inspector that will add the request http info to the outgoing message properties (I'm piggy backing off the error handler behavior to do this because they are so closely related):

public class ErrorHandlerBehavior : IServiceBehavior
{
    public const string HttpRequestInformationProperty = "HttpRequestInformation";

    public void ApplyDispatchBehavior(
            ServiceDescription serviceDescription, 
            ServiceHostBase serviceHostBase)
    {
       foreach (ChannelDispatcher dispatcher in 
                serviceHostBase.ChannelDispatchers)
       {
            // Add the error handler...

            // Add the parameter inspector that gets the request info and
            // stores it in the outgoing message properties
            foreach (EndpointDispatcher endpoint in dispatcher.Endpoints)
                  endpoint.DispatchRuntime.MessageInspectors.Add(
                       new HttpRequestInformationInspector());
       }
    }
}

So now error handlers have this info at their disposal. Then in the message inspector we grab the http request info and stash it in the outgoing message properties:

private class HttpRequestInformationInspector : IDispatchMessageInspector   
{
    public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel, InstanceContext instanceContext)
    {
        HttpRequestInformation info = new HttpRequestInformation();

        string contentLengthHeader =
            WebOperationContext.Current.IncomingRequest.Headers[HttpRequestHeader.ContentLength];

        long contentLength;
        if (!string.IsNullOrEmpty(contentLengthHeader))
            long.TryParse(contentLengthHeader, out contentLength);
        else
            contentLength = -1;

        info.ContentLength = contentLength;
        info.Uri = OperationContext.Current.IncomingMessageHeaders.To;
        info.Method = WebOperationContext.Current.IncomingRequest.Method;
        info.ContentType = WebOperationContext.Current.IncomingRequest.ContentType;
        info.Accept = WebOperationContext.Current.IncomingRequest.Accept;
        info.UserAgent = WebOperationContext.Current.IncomingRequest.UserAgent;
        info.Headers = WebOperationContext.Current.IncomingRequest.Headers;

        OperationContext.Current.OutgoingMessageProperties.Add(
            HttpRequestInformationProperty, info);
        return null;
    }

    public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState) { }
}

public class HttpRequestInformation
{
    public Uri Uri { get; set; }
    public string Method { get; set; }
    public string ContentType { get; set; }
    public long ContentLength { get; set; }
    public string Accept { get; set; }
    public string UserAgent { get; set; }
    public WebHeaderCollection Headers { get; set; }
}

Note that I'm manually grabbing the content length from the headers. Interestingly the content length header may not always be present. And its absence may not mean that the content length is zero (That's why I return a negative number if it is absent). The problem is the IncomingWebRequestContext ContentLength property does not check for the existence of the header before it parses it. So if its not there (Which is what's going to happen with a GET request) it will throw a null ref exception (Which can be confusing). I have submitted feedback here it you want to read more about this and Microsoft's response.

So now it's available in response code:

public bool HandleError(Exception error)
{
    HttpRequestInformation info;

    if (OperationContext.Current.OutgoingMessageProperties.ContainsKey(
        ErrorHandlerBehavior.HttpRequestInformationProperty))
        info = (RequestInformation)OperationContext.Current.OutgoingMessageProperties[
            ErrorHandlerBehavior.HttpRequestInformationProperty];
    else
        info = new RequestInformation();

    LogHandler.Write(error, info);
    return true;
}

Do you know of a better way to handle this? If so, please leave a comment as I'm not 100% satisfied with this approach and would be interested in a simpler alternative.

I came across a weird issue with proxy's generated by the Axis2 code generator from a WCF WSDL. Basically there is ambiguity between the String type defined in the Microsoft WSDL for primitive types which gets generated in the proxy and the java.lang.String. Supposedly this issue has been fixed but I still had an issue with the code generator plugin that installs with the Eclipse Ganymede plugin manager. Anyway's, to work around it I just navigated to the error:

And specified the FQ name for the Java string type and it worked fine:

If you are receiving the above error message it may be that you installed the NantContrib task binaries under the \bin\tasks\net\20 folder (As the NantContrib readme.txt specifies). Evidently the "tasks" folder is now called "extensions" in Nant 0.86. So the proper path would be \bin\extensions\net\20.

Will Smith so kindly pointed out that the target file for web application projects is not installed by the .NET 3.5 redist (Along with msbuild). To fix this you can copy over the target file from a machine with VS2008 installed to the same folder on build server. The target file can be found under \MSBuild\Microsoft\VisualStudio\v9.0\WebApplications.

So I had FTP setup on a Server '03 box with an FTP site configured to use user isolation mode with active directory. Everything was working great then all of a sudden users cant login and this error appears in the System events in the event log:

This error, while true, doesn't really pinpoint the problem... But I found this wonderful article that suggested that the account used by the FTP site to access AD was changed. "Oh yeah!", I said, "I did change that, D'OH!". Easy enough to fix; just open a command prompt and use the adsutil.vbs to update the AD account in the IIS metabase.

c:\Inetpub\Adminscripts\adsutil.vbs set msftpsvc/{FTP_SITE_ID}/ADConnectionsUserName MyDomain\MyFTPADUsername

c:\Inetpub\Adminscripts\adsutil.vbs set msftpsvc/{FTP_SITE_ID}/ADConnectionsPassword S0m3P@$$W0rd 

Remember to include the domain name with the username.

If you are trying to use the SharPoint LookupField control you will probably want to explicitly bind it to a list. You can do this in markup by passing the ListId attribute as follows:

SharePoint:LookupField ID="ContactTypeLookup" runat="server" ListId="253C5ECA-D17B-460F-A16F-FEEE749D8B1F" ControlMode="New" FieldName="ContactType" />

But what if you want to bind it to a list by name or set the list id in code? The first thing you might do is remove the ListId attribute in the markup and set the ListId property of the LookupField as so:

When you do you will get this lovely error:

The problem is that the LookupField control uses the list defined in the ItemContext property (Which is a SPContext object). Using good ole' reflector you will find that this property originates from the base class Microsoft.SharePoint.WebControls.FormComponent. The ItemContext is lazily instantiated when the property is first accessed. At that time it creates a new SPContext based off the value set in the ListId property. Evidentially this property is accessed at some point before the page loads thus instantiating the ItemContext before you have a chance to set the ListId. So setting ListId after that point does no good. What you can do however is give it a new ItemContext based off the list you want as follows:

ContactTypeLookup.ItemContext = SPContext.GetContext(HttpContext.Current, 0, SPContext.Current.Web.Lists["ContactTypes"].ID, SPContext.Current.Web);

And make sure you remove the ListId attribute in the markup:

<SharePoint:LookupField ID="ContactTypeLookup" runat="server" ControlMode="New" FieldName="ContactType" />

That's all there is too it!

An unhandled exception of type 'Microsoft.SharePoint.SPException' occurred in Microsoft.SharePoint.dll

Additional information: One or more field types are not installed properly. Go to the list settings page to delete these fields.

If your getting this exception you may be incorrectly referring to fields that have a space or other special character in them. WSS encodes some characters using a _x0000_ format where the green zeros are the Unicode code point in hex of the character, left padded to four zeros. For example if you had a field called "Default Location" you would call it by its "encoded" version "Default_x0020_Location" where _x0020_ represents the space. You can also learn the underlying name of the field by using the Solution Generator and viewing the list definition: