DI Management Cryptography

This page contains useful free cryptographic software code that David Ireland has written or adapted in Visual Basic and ANSI C. It's updated frequently, so keep checking.

http://www.di-mgt.com.au/crypto.html

Tools for everyday development

1. Process Explorer

Process Explorer shows you information about which handles and DLLs processes have opened or loaded.

The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.

2. Debug View

DebugView is an application that lets you monitor debug output on your local system, or any computer on the network that you can reach via TCP/IP. It is capable of displaying both kernel-mode and Win32 debug output, so you don't need a debugger to catch the debug output your applications or device drivers generate, nor do you need to modify your applications or drivers to use non-standard debug output APIs.

Cool Features

• Win32 OutputDebugString
• Kernel-mode DbgPrint
• All kernel-mode variants of DbgPrint implemented in Windows XP and Server 2003

DebugView also extracts kernel-mode debug output generated before a crash from Window's 2000/XP crash dump files if DebugView was capturing at the time of the crash.

3. PsKill

Windows NT/2000 does not come with a command-line 'kill' utility. You can get one in the Windows NT or Win2K Resource Kit, but the kit's utility can only terminate processes on the local computer. PsKill is a kill utility that not only does what the Resource Kit's version does, but can also kill processes on remote systems. You don't even have to install a client on the target computer to use PsKill to terminate a remote process.

P.S: Filemon and Regmon have been replaced by Process Monitor on versions of Windows starting with Windows 2000 SP4, Windows XP SP2, Windows Server 2003 SP1, and Windows Vista. Filemon and Regmon remain for legacy operating system support, including Windows 9x.

4. Resource Refactor

Features for Resource Refactoring Tool

• Works with C#, VB.Net languages. Supports all project types that ships with Visual Studio 2005 including web sites and web application projects.
• A preview window to show changes.
• Finds other instances of the text being replaced in the project automatically.
• Lists existing resources by their similarity level to the text being replaced.
• Automatically replaces hard coded string with a reference to resource entry.

5. Ghost Doc

Automatically generates documentation for constructors,methods,properties and class. Integrates will with visual studio and style cop and is a must have to get rid of those style cop warnings.

6. Microsoft StyleCop

StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project. This is a definite must have. It enforces consistent looking code across the whole project with multiple developers with varied tastes and preferences.

7. Microsoft FxCop

FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines for Class Library Developers, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.

FxCop is intended for class library developers. However, anyone creating applications that should comply with the .NET Framework best practices will benefit. FxCop is also useful as an educational tool for people who are new to the .NET Framework or who are unfamiliar with the .NET Framework Design Guidelines.

FxCop is designed to be fully integrated into the software development cycle and is distributed as both a fully featured application that has a graphical user interface (FxCop.exe) for interactive work, and a command-line tool (FxCopCmd.exe) suited for use as part of automated build processes or integrated with Microsoft Visual Studio® .NET as an external tool.

Links

Sysinternals Suite
FxCop
The Visual Studio Code Analysis Team Blog
StyleCop
Introducing StyleCop on legacy projects
Ghost Doc
Resource Refactor

Unit Testing Silverlight Apps

Inarguably SL2 applications are  a whole new experience of developing cross platform applications from managed code environments.

Unit Testing becomes very vital while developing for cross browser enterprise class applications. Visual Studio's tight integration of the Unit Testing framework is such an invaluable tool in the code production pipeline. Now, with the release of a unit testing framework for SL2 applications, the same experience can be leveraged.  SL2 applications can be developed in a test driven fashion now. It perfectly suits an agile team. A team which is constantly driven by change and is delivering on a constant basis, almost every day in some cases. Much like a team which does not have a release model. (Check out Jeff Wilcox's blog). I guess the Silverlight test framework was itself developed using an agile methodology.

The SL Unit testing framework has  proved to be an invaluable tool personally for me. It allows me to test SL applications on 3 different browsers (cheap guess if you are thinking which browsers ) even though i target IE mainly. :P.  I'll write about it with a test application soon in my next blog. Till then, check out these links..

Some Links:

Silverlight Toolkit - You can find components like dockpanel, treeview etc for SL 2, themes and of course the source code for controls with unit tests and the unit test framework itself.

Jeff Wilcox - The guy who develops actively on the SL unit test framework at MS.

Scott Gu's small demo program on SL unit testing - (If you don't know this man, you are not worth living, jump off a building NOW!)

MS Silverlight Unit Test Framework - MS unit test framework for SL 2.

A good one

A Simple Multi-threaded Logger

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;
using System.Threading;
using System.IO;

namespace SudhirMurthy.Logger {

  public interface ILog {

    void LogToDisk(string msg);

  }

  interface ILoggerService {
    ILog ILog {
      get;
    }
  }

  public class LogFile : ILog {

    static List<string> messages;

    //WriteToDisk delegate
    private delegate void WriteToDisk(object sender, string fileName);

    //WriteToDisk event
    private static event WriteToDisk writeToDisk;

    public static void WriteLog(string fileName) {
      //Raise the event    
      writeToDisk(new object(), (fileName));
    }

    public void SendToDisk(object sender, string fileName) {

      StreamWriter sw = File.CreateText(fileName);
      foreach (string s in messages) {
        sw.WriteLine(s);
      }
      sw.Close();
    }

    public LogFile() {
      messages = new List<string>();
      WriteToDisk mydelegate = new WriteToDisk(SendToDisk);
      writeToDisk = new WriteToDisk(SendToDisk);
    }

    public List<string> Messages {
      get {
        return messages;
      }
    }

    #region ILog Members

    public void LogToDisk(string msg) {
      Monitor.Enter(this);
        messages.Add(msg);
      Monitor.Exit(this);
    }

    #endregion
  }

  public class LoggerService : ILoggerService {

    //TODO: Need to make it threadsafe..    
    private static ILog logInstance = null;

    public LoggerService() {
      logInstance = new LogFile();
    }

    #region ILoggerService Members

    public ILog ILog {
      get {
        return logInstance;
      }
    }

    #endregion
  }

  public class LoggerClient1 {

    LoggerService logService;

    public LoggerClient1() {
      logService = new LoggerService();
    }

    public void Log() {
      logService.ILog.LogToDisk(string.Format(
        "I am Logging: {0}", this.ToString()));
    }
  }

  public class LoggerClient2 {
    LoggerService logService;
    public LoggerClient2() {
      logService = new LoggerService();

    }
    public void Log() {
      logService.ILog.LogToDisk(string.Format(
        "I am Logging: {0}", this.ToString()));
    }
  }

  public class TestApp {

    LoggerClient1 a;
    LoggerClient2 b;

    public TestApp() {

      a = new LoggerClient1();
      b = new LoggerClient2();
    }

    public void logClient1() {
      for (int i = 0; i < 1000000; i++) {
        a.Log();
      }
    }

    public void logClient2() {
      for (int i = 0; i < 1000000; i++) {
        b.Log();
      }
    }
  }

  class Program {
    
    static void Main(string[] args) {

      TestApp app = new TestApp();
      Thread t1 = new Thread(new ThreadStart(app.logClient1));
      Thread t2 = new Thread(new ThreadStart(app.logClient2));
      

      try {      
        t1.Start();        
        t2.Start();        
      } catch (Exception) {
        throw;
      }
      t1.Join();
      t2.Join();

      //The main thread should technically wait until
      //t1 and t2 should have finished and then execute
      //the following
      LogFile.WriteLog("log.txt");
    }

  }

}

I have demonstrated a simple multi-threaded logging mechanism here. The threads t1 and t2 share the static instance variable 'List<string> messages' while logging. The LoggerClient classes LoggerClient1 and LoggerClient2 each use the LoggerService to log messages. The log is finally written to disk by the the main thread. The LogFile class uses the Monitor.Enter(this) and Monitor.Exit(this) methods to allow locking while shared access to writing the log. This synchronizes the threads t1 and t2 to perform shared access writes without corrupting or overlapping the write operations. Another important thing to notice here is the methods t1.Join() and t2.Join() which is used to make the main thread wait until the threads t1 and t2 have finished executing.

If you try removing the Monitor.Enter(this) and Monitor.Exit(this) lines from the above code, you end up getting weird line numbers in your log.txt file. (enable line no's in visual studio and see log.txt). i.e the count of the log will never be as expected (2 million in the above case). By putting the above lines back, you get the expected value which is 2million lines of log. :). It takes about 5-6 seconds on my dual core for threads t1 and t2 to finish logging and the main thread to write to disk. :).  A bloated 93.4 MB file!!

My thread on MSDN Forums.

C0de