Mixing SetEnvironmentVariable and getenv is asking for trouble, as we recently found to our dismay (and exasperation!). It took some serious debugging to figure out the actual problem – let’s see if you can figure it out. Here’s some C++/CLI code that uses getenv to read the value of an environment variable and print it to the console. 1: public ref class EnvironmentVariablePrinter 2: { 3: public : 4: void PrintEnv(String ^key) 5: { 6: IntPtr ptr = Marshal::StringToHGlobalAnsi(key); 7: const char

Attach to what? To the process you want to debug, of course. How many developers attach to and debug arbitrary processes running on their machines? Very few, I’d imagine. And I’d think that even those few people typically prefer Windbg or an equivalent debugger to the one supplied with Visual Studio. Which means that aside from ASP .NET developers, almost all of us using Visual Studio attach to the application that we are working on and nothing else. To attach 1. You summon the “Attach to Process

The syntactic sugar offered by anonymous methods makes them great candidates for writing event handlers; together with smart type inference, they reduce the amount of code written by an order of magnitude. And that’s without considering the power offered by closures. With event handlers, closures allow you to kind of “stuff” extra parameters into the handler, without changing the actual number of formal parameters. This blog post shows a situation where an anonymous method acting as an event handler

You're writing this really cool and innovative class to calculate the first hundred thousand natural numbers. You think about the API, and you realize that returning an array of the numbers a) might take a long time to complete, and b) is going to cause memory usage to spike up like mad. So you decide to stream them instead, returning an IEnumerable<T> instance instead of an array. Being a crack C# developer, you use the incredibly powerful yield keyword, rather than rolling your own implementation

My colleague Soundar discovered this rather interesting behavior. 1: class Test 2: { 3: public static void Main() 4: { 5: Test test = null ; 6: 7: Console.WriteLine(" {0} ", test); 8: Console.WriteLine(" {0} ", null ); 9: } 10: } If you run this code, you’ll find that while line 7 prints an empty line, line 8 causes an ArgumentNullException. Note that the test reference is also null, so it should certainly surprise you that the two lines result in different behavior at runtime

If you’ve done any multithreading programming at all, you must be aware of the volatile modifier. When a field is marked volatile, it tells 1. the JIT compiler that it can’t hoist the field because it may be modified by multiple threads 2. the CLR that the field must be read to and written from with acquire and release semantics . Given what you’ve read above, the post’s title doesn’t make sense. A local variable, by definition, cannot be accessed from multiple threads. An object referred to by a

ForEachMethodInFile is a Visual Studio macro that lets you do custom actions for each method defined in the current file. I’ve used it in the past to generate logging code to log the start and end of each method, to generate default error handling code etc..  And today someone over at CodeProject wanted to generate a breakpoint at the start of each method. The common thread here is the performing of some custom action for each method in the current file. I figured it would be useful for a lot

WinMacro is a tiny little application that can record and replay keyboard and mouse actions that you do on your Windows desktop. It’s similar to the macro facility in Word and Excel, but works across applications. I wrote the initial version nearly 5 years back, and it proved to be very popular, with approximately 30000 downloads and tons of email from users. Most of the emails were appreciative, and some of them touching, especially those that described how WinMacro was helping people do a better

In the previous blog post, we found that mutating a struct inside a class works if the struct is declared as a field, but doesn’t work if it is declared as a property. The reason is fairly obvious – if struct fields also returned a copy, then there wouldn’t be any way of mutating the instance at all, even from within the declaring class. 1: struct S 2: { 3: public int X; 4: } 5: 6: class C 7: { 8: public S S; 9: 10: void SetX() 11: { 12: this .S.X = 1; // Won't work if this.S returned a copy

Take a look at the following short snippet of code. 1: using System; 2: 3: struct S 4: { 5: public int X; 6: } 7: 8: class C 9: { 10: /* More code here */ 11: } 12: 13: class Test 14: { 15: public static void Main() 16: { 17: C c = new C(); 18: c.S.X = 1; 19: } 20: } Without knowing the type definition of C, can you tell whether the code will compile, much less work? Turns out that you can’t. It depends on whether the S in c.S is defined as a field or a property. 1. class C { public S S; } 2. class