Deep Insights in Microsoft .NET

http://cduu.wordpress.com/2011/04/02/change-appdata-personal-profile-location-in-windows-7/ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ -> to change user profile folder

I was recently told that mentioning that I had solved problems which nobody had solved before in my job is a sign of arrogance. I beg to differ. There is no arrogance here. Difficult problems are solved by hard work and creativity not brute IQ or intelligence alone. You have to be persistent and you have to keep at the problem all the time till a solution is found. You have to volunteer to solve the problem when nobody is willing to entertain it. So, these people who write books like Mark Zuckerberg was an accidental billionaire is just full of it. Nothing could be further from the truth. He did a lot of hard work with determination and focus - he did not get anything free. So, don't think you are arrogant just because you mention the truth in your resume. Another thing... There maybe a senior developer who may not seem like he can be a great manager because of what he is doing right now. This is also totally untrue. You can't judge how good or bad someone will do i...

I was having this debate with some colleagues recently. In the name of agile, we cannot develop something just for a demo, which you will throw away after that, and then develop another part of the work to be done and then expect things to work out. If the problem is complex, the complexity has to be handled with you hands on its horns. The more time you spend on such a problem, the better you will understand it and tackle it. Doing stuff around it, or over it, actually produces a worse result. Because each time you are not considering the full problem, so your solution is flawed to begin with. Considering the entire problem is difficult, but going over it again and again makes it easier to understand and work with it. QA people also get a consistent application to test. Otherwise they may think your first solution handled some test cases and ignore that later - without knowing solution 2 is totally different than 1, and everything needs to be tested again. It is not true tha...

I got this weird error today while deploying to Windows Azure. First I installed the latest SDK updates and when that did not fix the issue, I removed the reference to this dll from the web project because it was referencing another dll which was referencing this dll. Not sure why this warning happened. Because I did not have multiple versions of this dll in my system as well. http://social.msdn.microsoft.com/Forums/en/MediaServices/thread/03a7f909-9edf-447a-af04-f73edcdc3113

It is simple - you cannot change what has already been shipped. You will always want to do major changes or refactor code especially if you came to the project new. It can be daunting to move forward when you have to consider backwards compatibility. The solution is to keep the old interfaces and entities in place. Create new interfaces and new entities and then use these interfaces and entities. And write code to route calls from the older interfaces to the new interfaces and translate the state from older entities to the new entities.

I have often heard the argument that static methods in C# are thread safe because their parameters are instance values. Or something to that effect. I never really accepted this nonsense but I heard it too many times and started to believe it. Today, I saw something which has fully shown me that this is not true. When multiple threads can enter a method, the safest way and the least complex way to prevent concurrency is to let it be an instance method and let different instances of the object run on different threads. Many guys may say otherwise. But I just saw a case where it clearly is not thread safe and I need to lock stuff to protect it. What is the point of writing static methods and putting lock statements all over the code? - Better for it to be instance methods and do away with this contention to begin with. The best multi-threaded code is code where you split the work and share no resources, so stuff can actually run in parallel and do not have to deal with conten...