Came across a gnarly difference in behavior between .NET runtime and Mono runtime. Take a look at this snippet.

One of the most ubiquitous patterns in life is the template. It enables us to generalize behavior - thus ignoring or postponing complexity.

Continuing the topic of smartening up Visual SourceSafe - how might we compensate for its inability to lock a branch?

One way would be to notify those concerned when a revision a.k.a. check-in occurs. Certainly one approach would be to create a CruiseControl.NET project that merely notifies when check-ins occur.

For a low-tech solution I use this approach. No attempt was made on usability - so improvements should come easy.

When is it okay to use fields? When are properties yagni? This was the topic of an email thread I was recently involved in. A friend of mine had determined to answer - once and for all - the overhead of using properties. The results of his testing indicated that property-usage has negligible impact on execution time. That in all but the most dire situations, property-usage is not a performance variable.

I actually looked into this about two years ago. I wrote a console app that benchmarked field/property access and mutation. The results were similar. But what I found useful was to compare the MSIL operations. The attached source is similar to that original code. It was compiled, tested, and disassembled under mono on Linux. You can run the binary as console app or nunit test fixture.

In software development process, one of the things that developer is afraid of is breaking the build. Usually I do is to create another source code tree, then get the lastest code, then manually copy over changes from my working branch; finially start a release build from this test branch to verify everything is compilable. This process is very lengthy and time consuming if you have tons of code.

Everyone needs the ability to monitor performance and track statistics inside applications. As developpers our code is a black box when running. We can't really tell how many times a loop is runs or how long an operation has taken, other then using log files. Another sexy way is to use the PerformanceCounter class. It lets your report statistics that can be viewed using the "PerfMon.exe". The bueaty is you can create custom counters to be used any way you please. Lets go over the steps to register and use some custom performance counters.

If a user wants the ability to customize buttons on a form, or a trader needs to develop custom formulas to execute his trading strategies then use CodeDom. These types of requirements can be easily accomplished using the CodeDom namespace. The System.CodeDom namespace is very powerful because it lets you compile source code at run time. The output is an assembly that can exist in memory or saved on your disk. We can use this feature of .NET to create customizable functions in our applicationswithout the need to compile and release new version.

I have a good amount of experience in real-time trading systems. One area of expertise is in developing GUIs that can handle real-time updates. I want to explain and show you some of the techniques I use when developing a GUI to handle this many updates.

Task:

• Create a GUI to receive real-time updates and display them in a grid.
• Use a DataTable and bind it to a Grid.
• Use a background Thread to simulate real-time updates.

Issues to be aware:

• Updates can and will be occurring faster then you GUI can handle.
• The GUI must always be responsive. Users do NOT like it when the application freezes because of updates occuring.
• Updates will not be real-time. It will appear to be real-time because of the implementation, but users should not see any noticeable delays.

I am not really going up against these guys, and not because I don't think 1 person could do it better. I just wanted to choose an interesting project to show you how easy socket communication is in .NET. The objective is to show you how to connect or listen on a socket, plus transmit and receive data.

I am organizing the solution into 3 parts: Client, Server, and Shared. The Client is a simple front-end to input messages that will be sent and display messages received. The Server will listen for client connection and route messages to the clients. The Shared project is where the standard communication engine will be developed the Client and Server will need a reference and re-use the same communication engines. The Client and Server will only need to implement specific functions unrelated to communications.

Do you run out of memory becuase everything is cached in memory and hit the limitation imposed by 32-bit machines?
Do you need to preserve objects when your application restarts?