HttpWebRequest, HttpWebResponse, and the WebException

Standard

Calling the GetResponse() method on the HttpWebRequest class yields some interesting results. It determines that a status code of anything else but 200 (OK) is an exceptional case and throws a WebException exception.

The following code demonstrates how to return the status code even if the URL in the request is not OK.

HttpStatusCode httpStatusCode;
HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create("http://invalidsitename.net/");
try
{
    using (HttpWebResponse httpWebResponse = (HttpWebResponse)httpWebRequest.GetResponse())
    {
        httpStatusCode = httpWebResponse.StatusCode; //OK
    }
}
catch (WebException webException)
{
    if (webException.Response != null)
    {
        HttpWebResponse httpWebExceptionResponse = (HttpWebResponse)webException.Response;
        httpStatusCode = httpWebExceptionResponse.StatusCode; //Something other than OK
    }
    else
    {
        throw webException; //Invalid host name
    }
}
return httpStatusCode;

SharePoint Guidance: Released

Standard

Microsoft patterns & practices SharePoint Guidance has been released to MSDN!

http://www.microsoft.com/spg

Updated: SharePoint Guidance 1.0 – Nov 2008

Here are a few of the topics you will find inside:

  • Architectural decisions about patterns, feature factoring, and packaging
  • Design tradeoffs for decisions many developers encounter, such as whether to use SharePoint lists or a database to store information
  • Implementation examples that are demonstrated in the Training Management application and in the QuickStarts
  • How to design a SharePoint application for testability, create unit tests, and run continuous integration
  • How to set up different environments including the development, build, test, staging, and production environments
  • How to manage the application life cycle through development, test, deployment, and upgrading
  • Team-based intranet application development
  • You might also see my name, along with the names of a couple of others from Avanade, in the Authors and Contributors section. (Updated to refer to SharePoint Guidance 1.0 – Nov 2008)

    Dynamic Cascading Drop Down Lists

    Standard

    Recently, I have been doing a lot of ASP.NET development inside of SharePoint. Once area that I have found to be quite tricky, although not SharePoint-specific, is dynamic ASP.NET controls. In particular, managing postbacks when you have dynamic ASP.NET controls.

    Here is a link to the source code for a Visual Studio 2008 solution, which demonstrates the use of dynamic cascading ASP.NET drop down lists that happen to query SharePoint.

    Nichols.DynCascadingControls.SharePoint.zip

    If you are not developing on a SharePoint box you can simply replace the SharePoint queries with some other data source such as a generic list.

    Please provide comments if you have any feedback.

    Creative Commons License This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

    SharePoint Guidance: Second Release

    Standard

    The second release of SharePoint Guidance from the Microsoft Patterns & Practices SharePoint Guidance team is now published on Codeplex at http://www.codeplex.com/spg.

    Updates included in this release:

    • Refactor code to leverage MVP pattern where applicable.
    • Refactor SPList-related SharePoint code with the Repository Pattern.
    • Unit tests for manager and presenter classes using TypeMock.
    • And much more…
    Disclaimer: This will evolve (and change) significantly. At this stage the RI provides a basic set of WSS features with accompanying guidance. This is not a CTP or a BETA.

    Stay tuned for new releases about every two weeks or so.

    SharePoint Guidance: First Release

    Standard

    The first release of SharePoint Guidance from the Microsoft Patterns & Practices SharePoint Guidance team is now published on Codeplex at http://www.codeplex.com/spg.

    Disclaimer: This will evolve (and change) significantly. At this stage the RI provides a basic set of WSS features with accompanying guidance. This is not a CTP or a BETA.

    Stay tuned for new releases about every two weeks or so.

    Deployment issues using Visual Studio 2008 SharePoint Workflow project templates (Access is denied.)

    Standard
    The addition of SharePoint sequential and state machine workflow project templates to Visual Studio 2008 did wonders for SharePoint workflow developers. Specifying SharePoint Debug Settings that allow you to do a “right-click Deploy” that GACs the DLL, installs and activates a workflow on a SharePoint instance, and associates it with a SharePoint list on that instance eliminates a lot of manual steps.
     
    There is one issue, however, that arises when the workflow project is under source control. This issue yields the following errors in Visual Studio:
     
    “Access is denied.”
    with
    “Cannot copy workflow.xml to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\[Project Name]\workflow.xml.”
    or

    “Cannot copy feature.xml to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\[Project Name]\feature.xml.”

     
    Unfortunately for the first few months I just dealt with this issue using this workaround:
     
    1. Open the path to the workflow feature folder.
    2. Delete feature.xml and workflow.xml.
    3. Go back to Visual Studio and click Deploy.
     
    I finally realized that when the Deploy command in Visual Studio for the workflow projects does a copy of the feature files to the 12 hive, it copies the read-only attribute as well if you do not have those files checked out in source control.
     
    If you are having this issue, simply check out feature.xml and workflow.xml from source control and your deployments with SharePoint workflow project templates should no longer have this error.

    SQL Server: Interesting Function and Stored Procedure Behavior

    Standard

    The other day out at Microsoft I ran into some interesting behavior in SQL Server regarding the difference between running a query in a table-valued function versus running it in a stored procedure.

    This particular query I was trying to run selects columns from an existing view that is part a database of the Microsoft product that I am currently working with. Unfortunately, this is no ordinary view. This view not only has two nested select statements, it joins on a table holding thousands and thousands of records. Looking at the estimated execution plan was ridiculous, having probably 50 or 60 processes.

    Running this query in a table-valued function, basically just running the view, causes the CPU on the server to soar to 100% and Management Studio to basically timeout. However, placing the same query in a stored procedure yields almost instant results.

    I talked this over with the resident SQL guru on the project and all we could come up with was that, because of the complexity of execution plan, the pre-compilation of the query in a stored procedure makes all the difference.