For that last half a year or so I have been using a solution that I call scratch pad to try out ideas.  For example if I have an idea for some sort of crazy layout panel that I want to try out, but don’t wont to mess around with the project that it is destined for, then I make a new project (or reuse an existing one) in my ScratchPad.sln and try out the idea.  This has worked really well for me, because I typically find it hard to decide on the best way to do something to start with which makes me procrastinate doing it.  Since the scratch pad doesn’t matter and I don’t have to worry about making a mess it is much easier for me to just jump in and try something out.

Today I was trying to solve an issue with nunit not setting the correct path for the assembly I was testing’s config file.  Well it wasn’t setting the expected path anyway.  It took me a little while to find out where the application was looking for the config file.  Eventually I discovered the following property: AppDomain.CurrentDomain.SetupInformation.ConfigurationFile.  Hopefully this can be of some use to you in the future.

I had an interesting problem today.  I was running through a foreach loop and generating a linq query with a predicate based on the element I was currently at.  Something a little like this:

            foreach (var sm in new SMRepository())
            {
                var bgvm = new GroupViewModel(this) { Descriptor = sm, Date = DateTime.Today };
                var gb = _workingBSet.Where(b => b.SM == sm);
                bgvm.B = gb; 
            }

Of course the example doesn’t compile and the names have been messed with but you get the idea.  Anyway a problem arose because the query hadn’t actually been run yet.  So when it did come time to run the query all of the results were the same because only the final value of the sm variable was used.  To get around the problem you can either get the count before moving onto the next one, or if you do want the deferred execution you can just make a separate method that does the work.  Something like this:

        void doSomething()
        {
            foreach (var sm in new SMRepository())
            {
                AddGroup(sm);
            }
        }

        private void AddGroup(SM sm)
        {
            var bgvm = new GroupViewModel(this) { Descriptor = sm, Date = DateTime.Today };
            var gb = _workingBSet.Where(b => b.SM == sm);
            bgvm.B = gb;            

            Groups.Add(bgvm);
        }

This avoids the problem because the same local variable is not captured by the closure (which is created by the lambda expression).  I hope this proves useful to someone.