Deep Insights in Microsoft .NET

http://blogs.msdn.com/b/camerons/archive/2011/01/28/code-metrics-from-the-command-line.aspx You can use this from the command line by creating a folder, putting the below dlls there and setting this up as a post build event. Useful if you want to get it running without having others install the exe. FxCopCommon.dll FxCopSdk.dll Metrics.exe MetricsReport.xsd Microsoft.Cci.dll Microsoft.VisualStudio.CodeAnalysis.Common.dll Microsoft.VisualStudio.CodeAnalysis.DataflowModels.dll Microsoft.VisualStudio.CodeAnalysis.dll Microsoft.VisualStudio.CodeAnalysis.Interop.dll Microsoft.VisualStudio.CodeAnalysis.Phoenix.dll The post build command line is: $(SolutionDir)folderName\metrics.exe /f:"$(TargetPath)" /o:"$(SolutionDir)folderName\ Reports \$(TargetName).Metrics.xml"

I got this error on the EndPeek event handler of MSMQ in .NET 4.0 running Visual Studio 2010 on Windows 2003 Server R2. The error shows up as NULL, even though it goes into the MessageQueueException catch. And we find this error code on debugging. Error receiving/ processing MSMQ messages in QueueReceiver, exception: System.Messaging.MessageQueueException (0x80004005)    at System.Messaging.MessageQueue.AsynchronousRequest.End()    at System.Messaging.MessageQueue.EndAsyncOperation(IAsyncResult asyncResult)    at System.Messaging.MessageQueue.EndPeek(IAsyncResult asyncResult)    at OnlineAVL.Services.Core.MessageQueueReceiver`1._receiverMessageQueue_PeekCompleted(Object sender, PeekCompletedEventArgs e) It is more confusing because a simple sample application does not throw this error. I checked everything from project files to compiler and cleaning up code. After debugging for 2 days, I found that the problem is because BeginPeek() is ...

I spent quite some time debugging end of file was reached before parsing could be completed error when casting the body of an MSMQ message object to a byte array. This is an object serialized to XML, and then compressed using .net framework classes. Thought it was a clash between .net 4.0 & 3.5. Nope, turned out that to fix the issue did two things called flush on both serialization and de-serialization, then looked at the entity sent over the wire. The one which failed missed XML include attributes at the class level for some complex properties which were added later. Now works fine. This never gave an error directly. Random errors while de-serialization, so difficult to debug. And was not x64 os problem either ;-)

You might think that if you have a database server at location X and application servers accessing this database from multiple different locations outside the LAN, it will not affect the DB performance. But that is a wrong assumption. It is not just latency which is a problem for the app servers, your core database operations are also affected by this latency. The reason for this is because the database is transactional and atomic in nature. So if some servers are writing to it, and others are reading from it, then when there is latency over the line, this latency directly affects the lock time of the transactions. This will reduce database speed considerably. So, use web services to send remote requests and let that make a LAN call to the database to reduce this overhead. Then latency is an issue only for the network hop.