NDepend is a very nice .Net Code Metric Analyzer tool that analyzes your application by using some predefined Code-Matrices. it will analyze your Assemblies for dependencies and will provide a clear picture of what is happening inside your application in the form of reports, diagrams and metrics. It is easy to use and with its powerful Code Query Language (CQL) you can build your own queries to inspect your application. it can be integrated with MSBuild or Nant Tasks.
you can download it here
After Attending a seminar on Microsoft Infrastructure and security it was revealed to me that a lot of work is going on in this field as well. a breed of products are availalbe like Microsoft ForeFront,MOM, SMS, Exchange Server 2007 etc.
More detailed information about infrastructure optimization is available on the following link:
http://www.microsoftio.com/
Introduction:
VS2005 takes a lot of time to build 'Web Site Projects' which is frustrating and cumbersome.
Here are some optimizations that will make the build process much faster.
Step 1: Changing Target Platform
Description:
By default project target platform is set to ‘Any CPU’ or ‘Mixed platforms’ in VS2005
Resolution:
Go to Properties by Right Clicking your Solution. Under Configuration Properties-> Configuration menu change the projects target platform from "Any CPU or Mixed platforms" to "x86".if x86 does not exists then create it from Configuration manager by selecting new category from 'Active Solution Platform'.
You will see a performance boost for all your Class library projects.
Step 2: Enable Batch Compilation
Description:
Turning batch=true in Web.Config means that all your stuff within one directory is compiled into one Dll at once. Switching batch=false means Dll's for every single page. As I mentioned, on my machine the batch=true option is very slow. Every time when I start debugging by F5 the whole app is compiled and for every page an xml file is generated and so on... Turning off batch compilation makes start debugging rocket fast.
Resolution:
In Web.Config File under compilation tag set batch=false.
Step 3: Leveraging Server-Side Compilation
Description:
Visual Studio 2005 is leveraging ASP.Net 2.0 server-side compilation. The IDE is primarily validating that the site will compile. For most edit/run iterations it's not really necessary to validate/build the entire site on every F5 or solution build. While this does improve build performance because ASP.Net is only compiling the files needed for the request on F5, it doesn't help the developer identify all the compilation issues within the IDE before running.
Resolution:
Change Build options for the web site project: (Property pages <shift><F4> -> Build)
“Start Action (F5)” should be either "build page" or "no build". - Improves F5 performance
“Build Solution Action” unchecks “Build Web as part of solution.” - Makes <ctrl><shift><B> very fast.
Step 4: Resolve Dueling Assembly References
Description:
The “easiest quick fix” way to resolve this issue is to modify one or more of your assembly file-based references to not be “automatic refresh enabled”. You can do this by deleting the .refresh files within your \bin directory that produce that shared conflict. This will avoid having VS auto-update the assemblies, and so will prevent the Dueling Assembly Reference update conflict altogether. You might find it useful to quickly disable this behavior by deleting the .refresh files as a stop-gap, and then re-enable the auto-refresh behavior once you fix the shared assembly conflicts.
Resolution:
Navigate to your website bin Directory and delete all *.refresh files.
Step 5: Disabling HTML Schema Validation
Description:
VS2005 has a background thread that continuously monitors all open aspx files for errors.
Resolution:
On the Tools menu, click Options.
In the Options dialog box, expand the Text Editor node and the HTML node, and then click Validation.
To disable validation, clear the Show errors check box and then click OK.
Step 6:Disable Antivirus On Access Scanning
Description:
VS2005 hits the file-system a lot, and obviously needs to reparse any file within a project that has changed the next time it compiles. One issue I've seen reported several times are cases where virus scanners, Spybot detectors, 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. Check for this if you are seeing build performance issues, and consider disabling the directories you are working on from being scanned by other programs. I've also seen reports of certain Spybot utilities causing extreme slowness with VS
Debugging - so you might want to verify that you aren't having issues with those either.
Resolution:
Watch out for Virus Checkers, Spy-Bots, and Search/Indexing Tools.
Results:
Initially my project was taking around 4-5 mins to compile, but after optimizing it was reduced to 10 secs.