t; z(@rax != 0x0000000080020003)

The application will break where the function returns the error HRESULT.

    class Base
    {
        public Base(int input)
        {
            VirtualMethod();
        }
        public virtual void VirtualMethod()
        {
        }
    }

    class Derived : Base
    {
        int _val;

        public Derived(int input) : base(input)
        {
            _val = 2 * input;
        }

        public override void VirtualMethod()
        {
            Console.WriteLine("Value is: " + _val.ToString());
        }
    }

If you create an instance of Derived like 

    Derived d = new Derived(5);

the output is not 10 as expected because the constructor of Derived has not been called yet when VirtualMethod is called in Base's constructor. The question is what if you do need to call virtual methods during object creation time. Also do we have to keep track which method is virtual when we make method calls in a constructor? A non-virtual method today may very well be changed to virtual by someone else tomorrow. One solution I found is to have a separate Initialize method to call virtual methods. For example,

    class Base
    {
        public Base(int input)
        {
            // Called in Intialize instead of in Constructor
            // VirtualMethod();
        }

        public virtual void Initialize()
        {
            VirtualMethod();
        }

        public virtual void VirtualMethod()
        {
        }
    }

    class Derived : Base
    {
        int _val;

        public Derived(int input)
            : base(input)
        {
            _val = 2 * input;
        }

        public override void VirtualMethod()
        {
            Console.WriteLine("Value is: " + _val.ToString());
        }
    }

To create a Derived instance, you need to call

    Derived d = new Derived(5);
    d.Initialize();

The problem is that the caller has to remember to call Initialize after creating the object. I choose to hide the constructor and have a static factory method for clients to create objects, which guarantees that the Initialize method being called. For example,

    class Base
    {
        protected Base(int input)
        {
            // Called in Intialize instead of in Constructor
            // VirtualMethod();
        }

        protected virtual void Initialize()
        {
            VirtualMethod();
        }

        public virtual void VirtualMethod()
        {
        }
    }

    class Derived : Base
    {
        int _val;

        public static Derived CreateInstance(int input)
        {
            Derived d = new Derived(input);
            d.Initialize();
            return d;
        }

        protected Derived(int input)
            : base(input)
        {
            _val = 2 * input;
        }

        public override void VirtualMethod()
        {
            Console.WriteLine("Value is: " + _val.ToString());
        }
    }

Creating a Derived object will be like:

    Derived d = Derived.CreateInstance(5);

I can also go a step furthur to have a rule that the constructor can only be used to initialize fields and never to make method calls. All method calls go into Initialize method. This way there is no more need to keep track whether a method is virtual or not.

1. Immutable
2. Thread-safe: multiple threads can access the same instance in any way without causing inconsistent state.
3. Conditionally thread-safe: weaker than thread-safe in that some sequences of method calls need external synchronization. For example, for a class implementing Stack, the class implementation can do proper locking within individual methods like Push and Pop, but it still does not protect against multiple threads calling Push followed by Pop. In this case, the client needs to do synchronization.
4. Thread-compatible: even weaker in that each method may need external synchronization, but it still allows client to write thread-safe code.
5. Thread-hostile: no way for client to write thread-safe code. For example, if private static state access is not synchronized, there is no way for client to know and do synchronization on its own.

So a better question is: can the class be used in a thread-safe way? That is the reason that in general, a class needs to synchronize access to the static state, but not the instance state.

Please See https://msdn.microsoft.com/en-us/library/k2xkefex.aspx for more info. The upgrade wizard is confusing in this case. We are relying on the Visual Studio standard upgrade mechanism, which (in VS 2008) does not allow external packages like VSTO to modify the wizard UI. So no matter what the real reason to upgrade (Office version upgrade in this case), you always see the message that the solution used a previous version of Visual Studio. Hopefully we can ask the Visual Studio Platform team to make the upgrade wizard extensible in the next version.

... EXCEL.EXE    5940    CreateFile    D:\temp\bbbb.xlsx    SUCCESS    Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: Read, ...

However, there can be many CreateFile calls. You have to go through them carefully. With that information, I tried to call:

HANDLE hFile = CreateFile(  _T("d:\\temp\\bbbb.xlsx"),

                            GENERIC_READ,          // open for reading

                            FILE_SHARE_READ,

                            NULL,                  // default security

                            OPEN_EXISTING,         // existing file

                            FILE_ATTRIBUTE_NORMAL,

                            NULL);            

However It does not work. I suspected whether the information I got from ProcessMonitor is correct. After some searching, I learned that FILE_OBJECT structure actually contains this information. You could use WinDBG to get it. What I did is to choose File->Kernel Debug...->Local. Then use Process Explorer to obtain the file handle address of the file and issue !fileobj on it like: 

lkd> !fileobj 0x8939F1C8

The output is like:

\temp\bbbb.xlsx

Device Object: 0x89e51900   \Driver\Ftdisk
Vpb: 0x89e21070
Event signalled
Access: Read Write SharedRead

It basically has the same information as what I got from ProcessMonitor. Now staring at it longer, I realized I didn't read Raymond Chen's blog carefully: the FILE_SHARE_* mode needs to be compatible with previous access mode. In my case, the file has been opened as GENERIC_READ | GENERIC_WRITE, the share mode in the latter CreateFile has to be at least FILE_SHARE_READ | FILE_SHARE_WRITE. Changing that and the file can now be opened.

1. If the dependent classes are hard to set up, take too long to run, or are still at an early development stage, mocking can make writing tests easier, and help the tests run faster and be more stable.
2. We can test more thoroughly by manipulating the mock objects to produce input that cannot easily be done with real objects.
3. If a bug is introduced in one class, ideally you will only have one test case fail. We only need to look at the class under test and do not need to worry about the dependent classes. It saves test maintenance and debugging time.

The disadvantages of mocking are:

1. It can be extra overhead. To do "pure" unit test, you either create many mock classes or have test code that are specifically for mocking if you use dynamic mocking. The test code can take longer to write and be harder to read and maintain.
2. With mocking, unit tests are testing less. It doesn't test the potential bugs coming from the interaction between classes. Some may argue that's the point of unit testing. Collaboration between classes should be tested by integration tests or functional tests. However, unit tests are our first line of defense. If we can catch bugs early with actually less effort by not mocking, I see no reason to mock unless there are other benefits.
3. If we are doing mocking blindly, we can miss the opportunity of using tests to make our classes more testable. For example, at an extreme, without any mocking, we can change all the interfaces to only use primitive types to achieve the goal of test in isolation. In some cases, it may indeed make sense to change the interface instead of mocking. If we always mock, it can be harder to see that.

To me, it feels more natural initially not to mock even though it means I may not be doing "pure" unit testing [1]. I'll only mock when it's necessary or it's really better than using the real objects. If we are constantly running tests (unit test or not), when tests fail, the first thing to look at is the last batch of check-ins. So the gain of mocking may not be substantial in a lot of cases. I think if our goal is to have "clean code that works," we basically want to spend minimum effort to have good design with maximum code coverage. It should be secondary whether we are doing "pure" unit tests or not.

[1] In Mocks Aren't Stubs, Martin Fowler differentiates between Classical TDDers and Mockist TDDers. Classical TDDers (Fowler being one) actually treat unit tests as mini-integration tests. I feel more comfortable with the classical TDD approach.

Keyword: unit test, mock, Martin Fowler

<configuration>

<system.diagnostics>

<trace autoflush="true" indentsize="4">

<listeners>

<add name="myListener" type="System.Diagnostics.Eventing.EventProviderTraceListener, System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="{BF8671E1-2B70-41f3-AE0C-993C6A7D6763}" />

<remove name="Default" />

</listeners>

</trace>

</system.diagnostics>

</configuration>

I put the event provider ID as initializeData and it seems to work. With that config file, you can simply use Trace.WriteLine("my message").

To start a trace session, do:

logman start mysession -p {BF8671E1-2B70-41f3-AE0C-993C6A7D6763} -o mytest.etl -ets

After you are done with tracing, you can stop by

logman stop mysession -ets

Then you can use tracerpt to dump the log to readable format.

tracerpt mytest.etl

ETW tracing is very customizable, but for doing simple tracing for debugging, it seems logging a message is enough. One advantage of using ETW tracing is performance. I did some simple measurement with a loop like:

            Stopwatch timePerParse = Stopwatch.StartNew();            
            for (int i = 0; i < 50000; ++i)            
            {                
                Trace.WriteLine("this is using Trace");
            }
            timePerParse.Stop();
            MessageBox.Show(timePerParse.ElapsedMilliseconds.ToString());

The result is like (on a 2.4 GHz machine):

Note: EventProviderTraceListener currently is only supported on Vista.

Keywords: ETW tracing EventProviderTraceListener System.Diagnostics.Eventing.EventProviderTraceListener logman.exe tracerpt.exe

I am creating a hierarchy of pure abstract classes to be accessed by user and another hierarchy of classes having the implementation. For example,

    public abstract class Foo
    {
        public abstract void Bar();
    }

    public abstract class SubFoo : Foo
    {
        public abstract void Baz();
    }

    public class FooImpl : Foo
    {
        public override void Bar()
        {
            // implementation
        }
    }

Now if I try to create a class like:

    public class SubFooImpl : SubFoo, FooImpl
    {
        public void Baz()
        {
            // implementation
        }
    }

I get syntax error because SubFooImpl cannot inherit from both Foo and FooImpl. The problem here is that SubFooImpl needs to assume the identity of SubFoo and also borrows implementation from FooImpl. You can only use interface in this case. The code will be like:

    public interface IFoo
    {
        void Bar();
    }

    public interface ISubFoo : IFoo
    {
        void Baz();
    }

    public class FooImpl : IFoo
    {
        public void Bar()
        {
            // implementation
        }
    }

    public class SubFooImpl : FooImpl, ISubFoo
    {
        public void Baz()
        {
            // implementation
        }
    }

This is an example that guidelines of programming is not something we can blindly follow. Without understanding the reasoning and context, they can still lead to the wrong choice.

Keywords: .Net, abstract class, interface