Bug or new convention for namespace declaration in .Net 4.0

Visual St开发者_运维技巧udio 2010, .Net 4.0

I'm generating some Domain Service Classes and this is how visual studio includes the namespaces:

namespace MyCoolProject.Web.Services
{
    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.ComponentModel.DataAnnotations;
    using System.Data.Linq;
    using System.Linq;
    using System.ServiceModel.DomainServices.Hosting;
    using System.ServiceModel.DomainServices.Server;
    using Columbus.Web.Data;
    using Microsoft.ServiceModel.DomainServices.LinqToSql;


    // Implements application logic using the JanDoetsDataContext context.
    // TODO: Add your application logic to these methods or in additional methods.
    // TODO: Wire up authentication (Windows/ASP.NET Forms) and uncomment the following to disable anonymous access
    // Also consider adding roles to restrict access as appropriate.
    // [RequiresAuthentication]
    [EnableClientAccess()]
    public class AnnouncementService : LinqToSqlDomainService<MydataDataContext>
    {......................

the namespaces needed by this class are included inside the namespace declaration, in other words the using bla bla bla lines are inside the MyCoolProject.Web.Services namespace declaration and not outside. Is this a new convention or a vs2010 bug?

Placing using directives inside a namespace is possible since .NET 1.0. This is done to avoid namespace polution because the types include by the using directives are only visible inside the namespace containing the using statements. So they just changed the code generator to adhere to the recommended practice to put using directives in the deepest possible namespace. Placing the the using directives outside any namespace performs the include in the global root namespace.

Have a look at StyleCop rule SA1200 for some more details.

UPDATE

The answer is a bit unprecise - the placement of the using directive is a C# thing and therefore it should read "is possible since C# 1.0" instead of "is possible since .NET 1.0".

It has always been the convention to place using statements inside namespaces (based on StyleCop rules), but the default template in Visual Studio has them outside so that has become the most common usage.

There is a good reason why the auto-generated files place the using statements inside the namespace though: It affects the order that references are resolved. If you defined a class in the MyCoolProject.Web namespace that shared a name with a class used in Columbus.Web.Data then the usage of that class will resolve to MyCoolProject.Web.Class if the usings are outside, or Columbus.Web.Data.Class if the usings are inside. So, by keeping the using statements inside the namespace, the auto-generated code is more robust to changes that you may make in the project.

This won't compile (because the MyCoolProject.Web.Console class does not define WriteLine):

using System;    
namespace MyCoolProject.Web.Services
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello there");
        }
    }
}

namespace MyCoolProject.Web
{
    public static class Console
    {

    }
}

Whereas this will:

namespace MyCoolProject.Web.Services
{
    using System;
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello there");
        }
    }
}

namespace MyCoolProject.Web
{
    public static class Console
    {

    }
}

Putting using directives inside the namespace is part of the internal Microsoft code style convention (as enforced by StyleCop). Personally I can't stand it, but it is what it is. I think I'm right in saying that the only circumstances under which it can actually make a difference are if you have multiple classes (in different namespaces!) defined in the same code file, which is widely considered a no-no.

It's been acceptable syntax since C# 1.0, I believe.

I'm not sure this is much of an underlying reason, but beware, at least in .NET 3.5, there's a bug that causes Linq to SQL not to work if you declare your using block outside of your namespace block in your partial class for your DataContext.