Archives / 2008 / July
  • tsvn:logtemplate : Enforcing strict format to SVN check-in mails.

    TortoiseSVN is a free open-source client for the Subversion version control system. Sometimes you want to have a more detailed information about a file/directory than just the icon overlay.

    Tortoise SVN provides some very useful properties for this purpose; tsvn:logtemplate is one of them -

    tsvn properties

    "tsvn:logtemplate is used with projects which have rules about log message formatting. The property holds a multi-line text string which will be inserted in the commit message box when you start a commit. You can then edit it to include the required information."

    Tortoise SVN: Enter Log Message

    This is the log template we used -

    Task Id:<Task ID>

    Code Review: <Reviewer's name>

    User Impact: <details of the implementation/changes as seen in the application. This is more from the user’s perspective or how the users will feel the implementation or see the changes in application>

    Technical Details: <technical details of the task>

    Unit tested: <(Yes/NO). Also mention the unit test case id>

    Developer Notes: <reference to other developers for any dependency for this check-in>

    QA Notes: <it contains impact/effected areas for the fix>

    The log template can be customized as per the project requirements and can be used to implement strict log format.

    Adding this to your svn repository is easy :

    1. Select a SVN folder to which you want to apply this go to Subversion properties( right click -> Properties->Subversion tab.)

    2. Select tsvn:logtemplate from the combo properties combo box.

    3. Add the above templates(or your own) to text area below combo box.

    4. If you want to apply the property to every file and folder in the hierarchy below the current folder, check the Recursive checkbox.

    5. Click on Set to add that property to the list.

    6. Check-in all the folders and files so that everyone else in your team can use the same template.


    Check this link to know more about other project settings available in TortoiseSVN  and how to use them -


  • Debugging classic ASP web application with Visual Studio 2005

    Finally, I got it; after a long and tiring evening of hit and trial I was able to hit a breakpoint in my asp page :)

    So you might think how come I suddenly moved from and Reporting services to classic asp, a long story in short is that right now I am assigned a task to migrate our company's timesheet application from classic asp to This is the first time I am working on asp application and in first look application looked like it's from some other world, but somehow I was able to get it working in VS 2005.

    Now came the real twist, I was able to access the users page of timesheet but not the admin, every time I tried running any admin page I was redirected to client page. As an developer for the last 3 years I was so used to debug my application using VS debugger that I just added a breakpoint in application and hit F5(hoping that I will be able to step through the code); but what's this, breakpoints were never hit, no symbols were loaded :(


    So as you can imagine I just did some hit and trial without any luck. After searching for a while I landed to a few useful links -

    But even after following all these steps nothing happened. Finally I bumped (lucky me) into this thread

    Visual Studio 2005 debugging not working for ASP pages

    and as author said...VOILA it worked, breakpoint was hit, thank god.

    So I just thought to note down steps I followed and what worked.

     1. Enable ASP server-side script debugging in website's configuration properties -


     2. Run the application (F5) and then attach to the Dllhost.exe process -

    a. Go to Debug->Attach to process menu in VS.

    b. Check "Show processes from all users" check box.

    c. Select dllhost.exe (Script code, T-SQL code) and click attach.


    That's it, breakpoints will get hit and you can debug your application.

    But still there are some things which are not required but worth mentioning -

     1. Almost in all related articles it was mentioned that you need to enable asp debugging in your asp projects configuration properties, but in my scenario I had added my application as local IIS website and its properties didn't had any such option. Even, It's not required to enable native code Debugger.


     2. Its mentioned that you need to add your user account or IWAN_MACHINENAME account to your systems "Debugger Users" group, but I tried it without that and debugging worked perfectly.


    I guess it was a good start to my new project, learned quite a few new/good things.


  • Troubleshooting SQL Server Reporting Services

    In my last post Grant O pointed out that I missed the troubleshooting section and same feedback came from my manager too; So I decided to add that section to the document.

    But when I was writing the various things which can go wrong during reporting services installation, I realized that its better to note down other troubleshooting cases too. So I added all possible scenarios(I had faced and from my bookmarked links) and categorized them as per my understanding. Lets see whether its helpful to you all or not :)

    Diagnosing reporting services issues

    1. Reporting Services records information in a variety of log files. Use the following log files to discover information about server operations and report server applications that run on the local computer:

      · Report Server Execution Log

      · Report Server Service Trace Log

      · Report Server HTTP Log

      · Windows Application Log

      · Windows Performance logs

      · Setup log files

      Reporting Services Log Files -

    2. Check Reporting Services Trace Logs to find the issues and see detailed stack trace information; SSRS provides four trace log files, which are located at \Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles
    3. Enable Remote Errors (Reporting Services Configuration) so as to display additional information about error conditions that occur on remote servers –

    4. Get more details about cause and resolution of Reporting Services Errors –

    5. Get more information about report server events, recorded in the Microsoft Windows Application Log file

      Reporting Services Errors and Events –

    6. Check this post for more help on how you can diagnose your problem –

    Troubleshooting Reporting services installation –

    1. Check the Setup Log files to find the cause -

    2. Make sure you have all SQL server service packs installed on your report server.

      SQL Server 2005 Service pack 2 -

    3. Install latest Cumulative update package for SQL Server 2005 Service Pack 2 on your report server.

      The SQL Server 2005 builds that were released after SQL Server 2005 Service Pack 2 was released -

    4. ASP.NET must be registered with Internet Information Services –
      1. Run aspnet_regiis -i from the %windir%\Microsoft.Net\Framework\v2.0.50110 folder.
      2. Run iisreset to restart IIS.

      ASP.NET IIS Registration Tool (Aspnet_regiis.exe) -

    5. Verify all services are running and features are enabled
      1. Click Start, point to All Programs, point to Microsoft SQL Server 2005, point to Configuration Tools, click SQL Server Surface Area Configuration.
      2. In Surface Area Configuration for Services and Connections, verify that the Report Server Windows service is running. If the report server database is hosted on the local Database Engine instance, verify that the SQL Server (MSSQLSERVER) is also running.

        SQL Server 2005 Surface Area Configuration

      3. In Surface Area Configuration for Features, verify that Scheduled Events and Report Delivery is enabled. Verify that HTTP and Web Service Requests is enabled. Verify that Windows Integrated Security is enabled.


    Troubleshooting Report Server Issues

    1. Check Trace log for the Report Server Web service (i.e. \Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles\ ReportServer_<timestamp>.log) to get more details.
    2. Verify that the SQL Server (MSSQLSERVER) service is started. On the computer that hosts the instance of the Database Engine, click Start, click Administrative Tools, click Services, and scroll to SQL Server (MSSQLSERVER). If it is not started, right-click the service, select Properties, in Startup Type select Automatic, click Apply, click Start, and then click OK.
    3. Make sure that Database Engine instance that hosts the report server database is configured for remote connections –

    4. If Windows Firewall is turned on, make sure that the port report server is configured to use is not closed –

    5. Verify that report server virtual directory properties are set correctly.
        1. Make sure that report server or Report Manager virtual directories are present and mapped to Microsoft .NET Framework version 2.0 or later
        2. Make sure proper authentication is configured for SSRS virtual directories in IIS(default is windows integrated security) –



        3. If you have reinstalled IIS 6.0 after SSRS was installed then you need to create SSRS virtual directories, use Reporting Services Configuration tool to recreate them.

        4. You can reset the virtual directory properties to default by using Reporting Services Configuration tool to make sure correct configuration is there–


    6. Verify that the URL you are specifying is correct for your deployment, if you installed Reporting Services as a named instance, the default virtual directory might include the instance name. To verify you can try browsing directly from IIS.
    7. Make sure that required features are turned on in configuration files –

    Troubleshooting Report Manager Issues

    1. Check Trace log for the Report Manager (i.e. \Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles\ ReportServerWebApp_<timestamp>.log) to get more details
    2. On a new installation, only local administrators have sufficient permissions to work with content and settings so make sure user account from which you are trying to access report manager is having sufficient permissions –

    3. Your report server must run in native mode. You cannot use Report Manager with a report server that is configured for SharePoint integrated mode -

    Troubleshooting Issues related to Web application Integration

    1. Enable impersonation in your Web application. Modify the Web.config file for your client app. Simply add the following line within the <system.web> configuration element to do this:

      <identity impersonate="true" />

    2. If your reporting services and data are on different servers then you must configure your network to allow Kerberos delegation, so that you don’t face “double hop" issue with IIS.

      How to use Kerberos authentication in SQL Server -

    3. If you are using report viewer controls in your application then make sure that report viewer Redistributable is installed on your web server:

      Microsoft Report Viewer Redistributable 2005 SP1 (Full Installation) -

    4. Check whether report viewer control is configured properly or not:

      Configuring ReportViewer for Asynchronous Rendering -

      SQL Server 2005 Reporting Services ReportViewer Control and IE7 –

    Troubleshooting Issues in Report Processing

    You can face session timeouts or some other processing errors when you have reports containing a large amount of data; there is no sure shot solution for this but there are a few workarounds for it as mentioned here :

    Processing Large Reports -

      1. Session Timeout during execution -
      2. Out of memory exceptions, increase the memory used by report server –

    Troubleshooting Report Design and Layout Issues

    1. Troubleshooting Report Problems –