Ramblings from an IT manager and long time developer.


Tool for working with .NET config file transforms

Check out this great tool for working with .NET config file transforms


Multiple app.config files (just like web.config files)

Good article from stackoverflow

Great article from:




Prevent ASP.NET web.config inheritance, and inheritInChildApplications attribute

If you have ever had the scenario where you have a main ASP.NET web application and then need to create one or more sub virtual folders that contain completely independant applications (different authentication, error pages, etc), then you have probably run up against the need to prevent the normal web.config inheritianace.  Do do this is pretty simple, just setup the PARENT web.config like this
<!-- Root web.config file -->
<?xml version="1.0"?>

  <location path="." inheritInChildApplications="false">


      <compilation debug="false" />

      <!-- other configuration attributes -->

The one catch when doing this is that you’ll probably notice Visual Studio compain about the “inheritInChildApplications” attribute.  Turns out this is because the Schema XSD files for web.config that shipped with VS2005/2008/2010 left out support for this attribute (Note: this doesn’t prevent your app from work, it just means VS IDE will complain).
To fix this, open up the following files located in %ProgramFiles%Microsoft Visual Studio XXXmlSchemas (XX is 8.0, 9.0, or 10.0 depending on your version)
  • DotNetConfig.xsd
  • DotnetConfig20.xsd
  • DotnetConfig30.xsd
  • DotnetConfig35.xsd
For each of the files — Find the <xs:element name=”location”> tag and change it to look like this
<xs:element name="location">
      <xs:any namespace="##any" processContents="lax" />
    <xs:attribute name="path" type="xs:string" use="optional" />
    <xs:attribute name="allowOverride" type="small_boolean_Type" use="optional" />
    <xs:attribute name="inheritInChildApplications" type="xs:boolean" use="optional" />
Basically what you are doing is adding this one line to that complex type declaration
<xs:attribute name="inheritInChildApplications" type="xs:boolean" use="optional" />
And thatsit — you’re good to go.


ASP.NET HttpModule Event Life cycle

MSDN Article:


In my recent quest to integrate support for SiteMinder into the ASP.NET Membership process I found myself looking into the details of ASP.NET Http Modules.  Once of the areas that I spent time on was understanding the exact order of events in the life cycle of a module.  Here is what I found.

The HttpApplication is usually un-heard of and it works quietly behind the scenes – well not really. If you have written a HttpHandler or HttpModule or any application with some sort of complexity before – you probably already know what its all about. The HttpApplication is the base class for all ASP.NET application objects, therefore, an HttpApplication class is created for each request. However, not to get too deep into the world of the HttpApplication, I want to focus this post on the sequence of events that are executed – its pipeline.

  1. BeginRequest
  2. AuthenticateRequest
  3. PostAuthenticateRequest
  4. AuthorizeRequest
  5. PostAuthorizeRequest
  6. ResolveRequestCache
  7. PostResolveRequestCache
  8. PostMapRequestHandler
  9. AcquireRequestState
  10. PostAcquireRequestState
  11. PreRequestHandlerExecute
  12. PostRequestHandlerExecute
  13. ReleaseRequestState
  14. PostReleaseRequestState
  15. UpdateRequestCache
  16. PostUpdateRequestCache
  17. EndRequest

Any HTTP module that subscribes to an HttpApplication event must implement the IHttpModule interface, also if you look at the list you will notice that each event has a corresponding post event. i.e AuthenticateRequest to PostAuthenticateRequest. These posts events are executed after its parent event has completed, therefore, PostAuthenticateRequest is raised after the AuthenticateRequest.

This is the very first event that is raised when ASP.NET responds to a request and it is always raised. Listen to this event for new requests.

As the name implies, this event fires on authentication of the user. Therefore, if you would like to know who is accessing your site, the “Post” of this event would be ideal to set a listener. It simply states that the request has been authenticated or the identity of the user has been established.

Authorizing the request is the next step right after the request has been authenticated. Trap “Post” of this event to determine if the user is authorized to access the particular resource or not.

Ok, it gets tricky. This event occurs after the authorize event and data is requested from cache. If the cache exist, the event handler such as a page will be bypassed and the cached request will be served. You can do several things here. Blow your mind!

A post event with no “Pre” – at least no access to it. This event get raised after the request has been mapped to a handler. So if you would like to know which handler will be executed, this is the place to be.

This executes right after the handler has been mapped to the request and it grabs the current state such as session state. Trap the “Post” event if you need to mess around with the session.

As the name implies, this event is raised just before the request handler that was mapped earlier on is executed such as a “.aspx” or “.asmx” page.

At this point in time all mapped handlers have been executed and state modules will start saving state data as required.

Completely opposite off the above, this event is raised to signal caching modules to save response data which may be used in future request during the ResolveRequestCache phase.

It has to end somewhere. The EndRequest is the last event raised.

I hope this post has helped you understand how the HttpApplication pipeline flows and also help you understand which events to trap to enable you to perform some tasks at the right time.


WSDL Contract First Development

Couple of good articles for Contract First Development


WSDL-First development for WCF


WSCF – Web Service ContractFirst


thinktecture (set of good tools)


Handcrafting WCF-frieldly WSDLs


A couple of great resources for Developer Cheat Sheets

Here are a couple of great sites that supply cheat sheets


Here are a couple of specific links to cheat sheets


And here are a bunch of cheat sheets all in one place for you to grab 🙂


aspnet-lifecycle-events-poster.pdf (60.92 kb)

aspnet-lifecycle-events-poster.png (96.79 kb)

aspnet-mvc-lifecycle-poster.pdf (489.01 kb)

css-v2-cheat-sheet.pdf (315.28 kb)

dotnet-string-formatting-cheet-sheet.pdf (123.71 kb)

HTML5-cheat-sheet.pdf (148.82 kb)

html-character-entities-cheat-sheet.pdf (958.89 kb)

javascript-cheat-sheet-v1.pdf (452.93 kb)

jquery-1.4-cheat-sheet.pdf (436.00 kb)

jquery-1.6-cheat-sheet.pdf (347.90 kb)

linq-cheat-sheet.doc (69.00 kb)

microformats-cheat-sheet.pdf (603.49 kb)

msajax-client-lifecycle-events-cheat-sheet.pdf (101.83 kb)

python-cheat-sheet.pdf (388.90 kb)

regular-expressions-cheat-sheet.pdf (647.55 kb)

rgb-hex-cheat-sheet.pdf (198.65 kb)

ruby-on-rails-cheat-sheet.pdf (752.11 kb)

sql-server-cheat-sheet.pdf (937.46 kb)

subversion-cheat-sheet.pdf (292.49 kb)

wpf-cheat-sheet.pdf (38.51 kb)

xhtml-cheat-sheet.pdf (71.99 kb)


How to use InternalsVisibleTo with strong named assemblies


Routinely I am forgetting how to do this 🙂 So to make life easier I am writting up a blog posting. 

When writting unit tests for VS2008/VS2010 you will may find yourself needing to access internals.  While it is possible to use the “_Accessor” classes, this is not always a friendly way to write tests (especially for complex objects and operations)

To that end, there is a nice and easy way (once you jump through a copy of configuration hoops) to handle this and that is via the “InternalsVisibleTo” attribute that lives at the assembly level.

I usually place my in the AssemblyInfo.cs file


[assembly: InternalsVisibleTo("MyProject.Tests")]


Now the trick comes when your assembly is signed with a Strong Name.  When this is the case, you will most likely receive the following error when you attempt to compile:


Error: "Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations"

To fix this, we must do two things.  The first is that you must sign the test assembly, and the second is that you must include the public key in the InternalsVisibleTo statement. 

To get the public key value from the .snk file, use the sn.exe utility included in the .NET SDK. You must do two things, first, create a .snk file that contains only the public key:


sn -p MyKey.snk MyKey.PublicKeyOnly.snk

Then, you can extract the public key value with this command:


sn -tp MyKey.PublicKeyOnly.snk

This will produce a similar output:

Public key is


Public key token is 2ff2b71993eeff95

Once you get this, copy the public key value (the really long one) and update the InternalsVisibleTo:


[assembly: InternalsVisibleTo("MyProject.Tests,  PublicKey=0024000004800000940000000602000000240000525341310004000001000100cfb8bc23b86a08e70d021dd53d3b0293e716e71015870bdcc58a0231a4228618851a83e06077f5a44f42beb2baf356ad2d344521a96b0081ed0f25f9227523e3625eda524efe1cf2e1e5e41f3693a76ec52347684b8129a4bb2d5fc49681adf33da0eecc4f81f011af4539d12abe1b4e760b5ce32d766db1012d44028381f0b4")]

Voila! You can now access the internals from your test project for strong named assemblies.


Xml Formatting

Looking for a way to format XML?

— some others


Tool for Validating and Formatting JSOn

Here is a great tool for validating and formatting JSON


StickOut: A Desktop Sticky Notes Application in the .NET Framework 2.0

Summary: StickOut is a desktop sticky note with multi-user support and Outlook integration. As a .NET Framework 2.0 Windows Forms application, it uses .NET Remoting to communicate with other StickOut users and exchange sticky notes with them. (85 pages)

Download the associated StickOut.msi code sample.

Original Article: