See my comments interspersed

>A bit off topic, Viv
>
>I'm not into EF and WPF yet, just trying to find my way / get used to and discover
>
>Some of the tough ones
>
>(1) Finding a good name for classes/methods

For methods, start with the good VerbNoun combination, such as WriteErrorLog or CalculateTax. Refactor as needed.

>
>(2) Namespaces. Name of them and how many
>Too many = having a lot of 'using'

Look at how the framework is organized. Pick one top level namespace and follow it down a couple of paths. That should give you some ideas.

>
>(3) Extension methods or static classes for a type of functionality
>Too many extension methods clutter up intellisense
>Putting things in static classes does not clutter up intellisense but you have to remember them

Why static classes?

>(4) Doing it right the first time (Namespace/ class/method names)
>It takes time to figure out how to organize them. And the day after I may have changed my mind

That's called refactoring. Don't worry about getting things right the first time. After you've been working with .NET a while, more and more good names will come earlier in the process.

>(5) testing - a lot of time involved
>I have found a way - may not the best one
>
>All classes that need testing have a static method TestSuiteRun() which is conditionally compiled ( #define TESTSUITE in the project properties)
>I have a static class TestSuite, with a Run() method that uses reflexion to find all the static TestSuiteRun() in all the classes and invoke them

That doesn't sound like a good unit testing methodology. A great book is "The Art of Unit Testing"

>
>Takes a bit of work to add it to the classes that need it - but then it's only once