XAML binding CodeRush templates

When I first started coding in Silverlight, I could never remember the syntax for databinding in XAML. Everytime I had to do databinding I found myself referring to the documentation. The lack of intellisense or compile time syntax checking was no fun either. So after a few days I created a few CodeRush templates, which I still use to speed up development. You can download them at the end of this post. The templates are:

bp (Bind to Property):

bsr (Bind to Static Resource):

bc (Bind using Converter):

  

be (Bind to Element):

Download XAML binding CodeRush templates

Anti-virus and search indexing programs can affect Visual Studio build performance

On Scott Guthrie's blog, he has mentioned how sometimes anti-virus and search indexing programs can affect Visual Studio's build performance.

One issue I've seen reported several times are cases where virus scanners, spy-bot detecters, and/or desktop search indexing tools end up monitoring a directory containing a project a little too closely, and continually change the timestamps of these files (they don't alter the contents of the file - but they do change a last touched timestamp that VS also uses).  This then causes a pattern of: you make a change, rebuild, and then in the background the virus/search tool goes in and re-searches/re-checks the file and marks it as altered - which then causes VS to have to re-build it again.

Such programs are known to cause problems on production systems too.

(via: Visual Web Developer Team Blog)

External settings file for ClientSettingsSection (applicationSettings)

Very often we define application settings in application configuration sections and would like to isolate the configuration section into an external settings file. Creating external settings file using the configSource attribute for the predefined configuration sections (AppSettings, ConnectionStrings etc) is well documented. But the literature for custom configuration section is sparse.

Listed below is a sample configuration file that contains a configSource attribute being used in a ClientSettingsSection. I have kept only the essential parts of the file:

   1: <configSections>

   2:   <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup">

   3:     <section name="MyApplication.Properties.Settings" type="System.Configuration.ClientSettingsSection"/>

   4:   </sectionGroup>

   5: </configSections>

   6:  

   7: <applicationSettings>

   8:   <MyApplication.Properties.Settings configSource="BusinessLogic.config" />

   9: </applicationSettings>

Line 8: Using the configSource attributed to define an external settings file called "BusinessLogic.config"

A couple of things of note:
- Unlike how it does for predefined configuration sections, Visual Studio does not provide intellisense when trying to add the configSource attribute to ClientSettingsSection.
- The external settings file has to be in the same directory or subdirectory as the configuration file. So line 8 can be replaced with the following line:

<MyApplication.Properties.Settings configSource="ConfigFiles\BusinessLogic.config" />

Listed below is the "BusinessLogic.config" file

   1: <MyApplication.Properties.Settings>

   2:   <setting name="InitializationVector" serializeAs="String">

   3:     <value>1234567890abc!@#</value>

   4:   </setting>

   5:   <setting name="KeySize" serializeAs="String">

   6:     <value>256</value> 

   7:   </setting>

   8: </MyApplication.Properties.Settings>

 

Technorati Tags: asp.net, c#, vs2005

Getting line numbers in exception stack trace in a Windows Service

The Exception.ToString() method contains call stack information when the exception was thrown. However if the PDB files from the assemblies involved are available, this information also contains file names and line numbers at each level of the stack trace. Needless to say that this information can be very beneficial to the developer.

The CLR will look for the PDB files in the runtime working directory, which for most applications is the installation directory itself. However for windows services the working directory is the windows systems32 directory (For eg: C:\Windows\System32). So exceptions thrown in assemblies that are hosted in a windows service, the call stack rarely contains the file names and line numbers even when the right PDB files are available.

The working directory of a windows service can be changed using the following line:

   1: Environment.CurrentDirectory = System.AppDomain.CurrentDomain.BaseDirectory;

Once the working directory has been changed to the base directory, the CLR should pick up the right PDB files and the stack trace should contain line numbers.

Technorati Tags: vs2005, exceptions, c#, windows service

Shortcut: Launch Visual Studio Command Prompt from Visual Studio

In Visual Studio 2005:

1. Go to Tools > External tools
2. Click Add and enter the following information
1. Title: Cm&d
2. Command:  %comspec%
3. Arguments: /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"" x86
4. Initial Directory: $(ItemDir)
3. Click Apply / OK 

In Visual Studio 2008:

1. Go to Tools > External tools
2. Click Add and enter the following information
1. Title: Cmd
2. Command:  %comspec%
3. Arguments: /k ""C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"" x86
4. Initial Directory: $(ItemDir)
3. Click Apply / OK

Technorati tags: vs2005, vs2008

Visual C# 2005 shortcuts

I found a nice PDF file that lists the most frequently used shortcuts in Visual C# 2005. You can download it from the Visual C# 2005 Keyboard Shortcut Reference Poster page.

Technorati Tags: visual studio 2005, vs2005

Web service time out in Visual Studio 2005 debug mode

We use a web service to standardize US addresses (convert Av to Ave., LA to Los Angeles etc). The web service has been around since a long time and is used by a lot of applications written in .NET 1.1. But today when using it in Visual Studio 2005 I noticed something. It threw a WebException.Timeout  exception every time I invoked it while I was debugging. It worked fine when invoked while the application was running normally, just not while being debugged. That's when a colleague asked me to add the following lines to my machine.config file, after which every worked fine.

<system.diagnostics>
    <switches>
      <add name="Remote.Disable" value="1"/>
    </switches>
</system.diagnostics>

Symptoms: A web service method runs fine when invoked normally, but throws a exception when it is invoked from Visual Studio 2005 in debug mode. The web service method runs fine when invoked from Visual Studio 2003 in debug mode.

Cause:  It seems that the Visual Studio 2005 debugger some data to each outgoing request which is used for debugging. However, this data destroys the well-formedness of the request.