Как переопределить автоматическое сопоставление папок и пространств имен VS2010 в новых файлах cs

Проекты часто разбиваются на папки, и эти папки обычно должны отображаться в пространства имен кода. Однако во многих из моих основных проектов у меня есть классы, которые я объединил в существующие пространства имен - например, у меня есть справочная библиотека MVC, которая добавляет дополнительные типы в System.Web.Mvc или System. ComponentModel.DataAnnotations , например.

В других проектах у меня может быть набор интерфейсов и набор реализаций этих интерфейсов по умолчанию; поэтому я мог бы разделить файлы кода на две отдельные папки (например, «Объекты» и «Интерфейсы»), но я не хочу иметь подпространства имен Объекты и Интерфейсы .

Точно так же я часто пишу методы расширения для типов в других библиотеках - например, System.String , которую я объединяю с пространством имен System , поэтому они уже «там», как только вы ссылаетесь на сборку.

Итак, учитывая структуру проекта, подобную этой (в ответ на первый ответ, этот проект предназначен для создания единой сборки со всеми пространствами имен; и может быть DLL, которая может быть подписана):

Our.Core.Library
|->System
|  |->StringExtensions.cs
|->System.Web.Mvc
|  |->AnotherModelBinder.cs
|->OurCoreClass.cs

В приведенном выше примере Я хочу, чтобы новые файлы, добавленные в корневой каталог, находились в пространстве имен Our.Core.Library , но я хочу, чтобы новые файлы, добавленные в папки System и System.Web.Mvc, находились в System ] и System.Web.Mvc соответственно. Но VS предоставит им пространство имен по умолчанию Our.Core.Library.System .

Это небольшая проблема, но я хотел бы иметь возможность переопределить пространство имен по умолчанию для определенной папки кода, чтобы я мог управлять им. Есть идеи, как этого добиться? Я пробовал пустое пространство имен по умолчанию для проекта, что логически могло заставить его работать для подпапок, но, очевидно, не для корня; однако страница свойств VS не принимает пустое пространство имен.

В идеале это было бы решение, которое я мог бы легко воспроизвести для всей нашей команды разработчиков, чтобы другие разработчики могли добавлять файлы кода, при этом придерживаясь структуры пространства имен, установленной на этапе архитектора / планирования.