Debugging

Automated Web Testing with Visual Studio 2008

dbottjer — Tue, 28 Apr 2009 06:32:03 GMT

Tulsa Developers User Group | Automated Web Testing with Visual Studio 2008 (Review)

Corey Roth presented tonight on automated web testing with Visual Studio 2008 at the Tulsa Developers User Group. Visual Studio can be used to record an action such as logging into a web application. Alternatively, users can inspect screen values for specific results. The test would pass if the expect value is present and fail if the value is missing. Visual Studio must be installed to execute the tests.

A tests project actually generates .NET Code (C# or VB.NET). The tool can also be used to show raw header information and cookies. One drawback is that only Internet Explorer is supported.

Additional Information:

Follow me on twitter @dbottjer

Technorati Tags: Web Automated Tested,Tulsa Developers User Group

Increase SharePoint execution Timeout

Dennis Bottjer — Tue, 14 Apr 2009 09:40:55 GMT

Execution Timeout Issue:

After six minutes (360 seconds) of execution a SharePoint page will timeout. Now for most situations a six minute execution timeout seems very generous. However, it is likely that this default execution timeout may be reached during such tasks as Feature Activation. Features are activated from a SharePoint Application Page and unless specially coded (not likely) a Feature will execute code in a synchronous manor. Features containing code to create nested site hierarchies can be quite time consuming.

Solution:

SharePoint uses a web.config located under:

Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS

to set the default executionTimeout. The default executionTimeout (See Below) value is 360 seconds or six minutes. Increasing this value will allow our Feature code more time to complete execution before timing out.

Sample Web.Config

<system.web>
    <compilation batch="false" batchTimeout="600" maxBatchSize="10000" maxBatchGeneratedFileSize="10000" />
    <httpHandlers>
      <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory, System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </httpHandlers>
    <customErrors mode="On" />
<httpRuntime executionTimeout="360" />
    <globalization fileEncoding="utf-8" />
</system.web>

Technorati Tags: Increase SharePoint Execution Timeout

403 Error when accessing SearchSPSettings.aspx

dbottjer — Tue, 05 Feb 2008 14:35:00 GMT

Problem: We were installing code on a MOSS 2007 Medium Farm Deployment. We noticed the servers were missing sever WSS/MOSS 2007 related patches. We applied the missing patches but then realized Search was no longer functioning properly. One of the most noticeable issues was we could no longer access the "Search Settings" page under the primary SSP. Prior to applying the patches this page was accessible but now we just saw a 403 Forbidden Error. The event logs and the SharePoint logs weren't much help either. Basically, we knew the problem had something to do with permissions but we couldn't find any hits where to look. Additionally, this seemed to be the only page having issues.

Solution: After searching several blogs and MSDN I finally found a single post http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2793573&SiteID=17&mode=1 by Jörgen Bjerkesjö that provided the solution. The problem is caused by the local wss_wpg server account not having write access to the %windir%\tasks folder, usually c:\windows\tasks folder. This folder is used by Windows Task Scheduler. So to fix the problem the wss_wpg account needs to be given write access to the c:\windows\tasks folder on the index server.

Note: The c:\windows\tasks folder is a hidden folder by default.

Steps:

On Index Server or all server in farm
Open a command prompt and type attrib -s %windir%\tasks <enter>
Browse to %windir%\tasks, right click and select properties. Add the WSS_WPG group and grant Read & Write permissions on the tasks folder.
Open a command prompt and type attrib +s %windir% \tasks <enter>

Technorati Tags: [SSP Error],[MOSS 2007],[Search Settings 403],[Search Settings Error]

Error 1718. File FileName was rejected by digital signature policy.

dbottjer — Fri, 16 Nov 2007 03:13:39 GMT

Leveraging Virtual Machines is a great way to develop against SharePoint. I was trying to update Visual Studio 2005 on a dev VM to SP1 and kept receiving "Error 1718. File FileName was rejected by digital signature policy." The cause of this error is actually related to a lack of Virtual Memory. However, I still received the error after increasing the virtual memory. The HotFix available in this http://support.microsoft.com/kb/925336 MS Support Article resolved the issue.

PEX Dynamic Test Generation

dbottjer — Wed, 14 Nov 2007 17:16:29 GMT

Found this project, http://research.microsoft.com/Pex/ from MS Research which apparently dynamically generates tests and code analysis during active development. Interesting way to enforce code quality and just prove requirements are being met.

ASP.NET Debug=true Performance Considerations

dbottjer — Wed, 10 Oct 2007 13:36:00 GMT

I'm sure, like me, you've seen plenty of production web.config files with debug=true set. Most senior ASP.NET developers will recognize that debug should be set to false for the production build. However, this small detail is often over looked. So what does this setting really do and does it have any significant impact on a production site?

When debug is set to true, the following occurs:

Pages are not batch compiled.
Pages do not time out. When a problem occurs, such as a problem with a Web service call, the Web server may start to queue requests and stop responding.
Additional files are generated in the Temporary ASP.NET Files folder.
The System.Diagnostics.DebuggableAttribute attribute is added to generated code. This causes the CLR to track extra information about generated code, and it also disables certain optimizations.

Source of Information: http://msdn2.microsoft.com/en-us/library/ms998549.aspx

Thoughts On Recursion

dbottjer — Tue, 10 Jul 2007 10:45:00 GMT

Recursion is a computer science concept in which a method / function essentially calls itself until some condition is met. Recursion can be an elegant solution to some logic problems. However, I believe there are some potential dangers in using recursion that should carefully be consider. Recursion is not an impossible concept to grasp it is just one that takes some thought. The skill level of those maintaining an application should be considered before implementing recursion as it is a more advanced programming concept and could lead to serious performance issues of not implement correctly.

namespace RecursionTest
{
    class Program
    {
        static void Main(string[] args)
        {
               System.Console.WriteLine(calcFactorial(4));
               System.Console.ReadLine();	
         }


        static int calcFactorial(int n)
        {
            return n * calcFactorial(n - 1);
        }

    }
}

Did you spot the bug in the code above? The code never stops when the factorial is complete resulting in an infinite loop. To fix the code we need to add a simple constraint or check.

namespace RecursionTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(calcFactorial(4));
            Console.ReadLine();
        }


        static int calcFactorial(int n)
        {
            if (n == 1)
            {
                return 1;
            }
            else
            {
                return n * calcFactorial(n - 1);
            }
        }
    }
}

The recursive code above is very clean however as demonstrated it is easy to forget the constraint and introduce an infinite loop. I would also like to point out that from a performance standpoint recursion may not be the best choice. It is often faster to use a looping structure where possible. Finally, one must consider the impact recursion has on the managed stack in .NET. Basically the deeper a thread's stack becomes the more difficult it becomes for the Garbage Collector to determine what should be collected and what is still in use.

Loosing ASP.NET Session State in IIS6

dbottjer — Wed, 09 May 2007 19:25:00 GMT

Last year we deployed a new underwriting system. Since the Fall of 2006 we have been steadily releasing updates to the system. Supporting the large user-base of this application has required us to improve our debugging and performance monitor skills. For example, we have become huge fans of unit testing and made strides to better understand memory management and profiling. To protect the health of the application we needed to understand the recycling of application pools / worker processes.

Thoughts on Application Pool Recycling and Application Availability explains in detail how IIS6 is designed to gracefully transfer client connections to the new worker process. In general devising a health strategy and recycling application pools is a good idea. It is a bad idea to be overly aggressive in the recycling of Application Pools. For example, recycling an application pool every hour would be very aggressive. If application pool recycling is required that frequently I would profile the application's memory usage to determine how garbage collection is working. Perhaps objects aren't being disposed of in a timely manor. It is always a good idea to create a connection or instantiate an object as late as possible and dispose of them as soon as possible. Furthermore, forced Garbage Collection like the GC Collect method is not recommend b/c it can corrupt Garbage Collection Statistics.

When recycling an application pool for an application that maintains session state, the way in which the session state is maintained should be considered. For example, maintaining In-Process session state will result in a loss of session state when the Application Pool is recycled. As a result users may be forced to login to an application again.

Why do I lose ASP Session State on IIS6 further explains the loss of session state when maintaining state in-process. A better strategy may be to store session state out of process.

DoNotExposeGenericLists recommends Collection<T> over List<T>

dbottjer — Wed, 09 May 2007 18:55:00 GMT

DoNotExposeGenericLists is a Code Analysis rule exposed within Visual Studio when List<T> is publically exposed. For example, List<T> may be exposed through properties, methods, parameters, etc. Why does DoNotExposeGenericLists recommend that I expose Collection instead of List? [David Kean] explains that Collection<T> is the better choice b/c it exposes 4 overidable methods. The methods are ClearItems, InsertItem, RemoveItem and SetItem. Events can be raised from within these four methods to provide a notification when changes are made to the Collection.

Web Services and UTF8Encoded ByteArrays

dbottjer — Tue, 01 May 2007 10:06:00 GMT

Our business partner began reporting all bullet points were being converted to question marks during the archiving of Word Docs. An early hunch that perhaps our FTP component was defaulting to ASCII transfer mode instead of Binary proved incorrect. With this option ruled out we knew our electronic document repository was properly receiving both the control file and the Word Doc. We began to suspect the web service exposed by our application which returns a document and metadata for archiving. We were using a byte array to store, in this case, the word document and write it to the http response stream. However, we were not specifying the encoding type which was our fatal mistake.

1: StringWriter sw = new StringWriter();

   2:  XmlTextWriter xw = new XmlTextWriter(sw);

3:

   4:  // Save Approval Document to Text Writter.

   5:  doc.WriteTo(xw);

6:

   7:  // Added this line to specify encoding and resolve bullet point issue.

   8:  UTF8Encoding encoding = new UTF8Encoding();

9:

  10:  // Convert Approval Document To Byte Array.

  11:  byte[] docAsBytes = encoding.GetBytes(sw.ToString());

12:

  13:  vvDoc.FileBinary = docAsBytes;