Linked are some videos which can give you a running head start: "Web Application Pen Testing Tutorials" however, firing off a tool or two at an application is not a reliable mechanism to ensure security. Since you stated: "we have developed an ASP.NET Based Enterprise Application", your best best is to work using say Agile or other SDLC based TEST CASES and create your own MISUSE cases. Link: "Software Security, Misuse, Fault Injection"
The reasoning/rational behind this comment is, you (the company, developers, etc.) are the ones who made the application. You know (have documented) how it is supposed to function, and what it is NOT supposed to do. You can create "specially targeted" attacks against your own application that can yield better results.
The issue with tools are, they are pre-programmed with "known knowns." Attacks and attackers all evolve. So relying on one tool can leave you still vulnerable if the author of the tool, was unaware of a new threat. This was the issue with JAVA recently where there were issues, Oracle would sandbox, an attacker would re-break it, they'd patch it, and another attacker would re-break that too.
For something like this (application testing), its a very broad thing. You can use fuzzers, networking tools, and a smorgasbord of everything and anything, and still get it wrong. It pays to begin from the ground up:
What does my tool do (test case)
How can someone abuse that my tool is supposed to do? (misuse/abuse case)
Test Case 1: Application takes input from user (a name)
Misuse Case 1: Rogue user tries to enter something other than a name (unicode, hex, etc.)
I decided to re-comment on this since I see the "hire a professional" answer. While this would a better thing to do since "professionals" tend to be better equipped and experienced to deal with this, they too can and so fail. An SDLC like approach should be at the forefront of developing secure code. Testing against (hiring a pro) this SDLC practice should come secondary. There is a HUGE difference in penetration testing, and application security. See: "Writing Secure Code"