Deep Insights in Microsoft .NET

http://www.csharp-examples.net/reflection-callstack/ http://www.csharp-examples.net/reflection-calling-method-name/ This works pretty well.

It can be a nightmare when every line of code uses unity block and hides the path of code execution unnecessarily. A developer can become quickly overwhelmed trying to figure out how to find out the "real" class whose object is being used. The simplest way is to go to the interface and find references, which will show you all classes which implement the interface. In a bad design, there will always be just one class which implements this interface and which is unnecessarily called via unity. Unity is gr8 - but please use it when plugin is really required.

I was initially using the async delegate pattern to make logging asynchronous in the application. The problem is that whether you use this way or thread pool, ultimately, it uses thread pool threads and because everything is busy logging, your application will be slow. Timers may fail to function, and generally, you have lost the advantages of making logging asynchronous. So, I used a pattern I did a few years ago - with a small tweak. Always make error/fatal/warning logs synchronous, for the rest append to a string builder, then use a timer (a single timer) which runs every 1000 ms and which will clear the string builder "buffer" and do whatever you want to do within this. This way, you use minimal thread pool threads, and your logging is still asynchronous enough...

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.