Предоставьте намек IntelliSense, что частичный класс не должен изменяться
В последнее время я использую довольно некоторое генерирование кода, как правило, в сочетании с частичными классами. В основном настройка выглядит следующим образом:
- Частичный класс, содержащий сгенерированный код. Некоторые из этого кода вызовут частичные методы. Код перегенерируется много времени. Генератор кода в некоторых случаях является настраиваемым инструментом.
- Частичные методы выполняются вручную в отдельном файле.
Проблема заключается в том, что, когда я использую функции Intellisense, такие как "метод генерации", они почему-то сгенерированы в файле, содержащем сгенерированный код. Очевидно, я этого не хочу.
Мой вопрос: возможно ли генерировать некоторый намек, который сообщает Intellisense, что он не должен касаться определенных файлов "cs" (но вместо этого другого частичного класса)?
Обновление
В ретроспективе я должен был заметить, что я использую собственный инструмент для генерации кода. Это не EF или простое преобразование; в генерации кода довольно много логики. Кроме того, он генерирует полное пространство имен и структуру классов с частичными классами. "Корневое пространство имен" найдено путем извлечения его из файла csproj
, а затем с использованием структуры папок для определения абсолютного пространства имен (это похоже на то, как это делает Linq2sql).
Ответ, предложенный xanatos (спасибо!), работает: intellisense сортирует свою операцию над именем, затем в алфавитном порядке сортирует по имени и затем выбирает первый элемент в списке. Это означает, что вы можете создать zzzz.foo.cs
, который (хотя и немного уродливый) будет работать нормально. Я только что провел несколько экспериментов и выяснил, что функция find all references
возвращает порядок, который VS использует. Как оказалось, он работает следующим образом:
Скажем, у вас есть настраиваемый инструмент, который работает с именем файла foo.bar
и преобразует его в foo.cs
. Пользовательский инструмент будет генерировать содержимое в виде строки и передавать его обратно в Visual Studio (это то, как работают пользовательские инструменты...). Результат будет в файле с именем foo.cs
.
Теперь я был очень удивлен, обнаружив, что Intellisense не сортирует его как foo.cs
, а скорее как foo.bar\foo.cs
. Другими словами: независимо от того, как вы называете вывод "cs" в своем настраиваемом инструменте, вам необходимо переименовать базовый файл foo.bar
в нечто вроде zoo.bar
.
Хотя это может быть обходным путем, я не согласен принять его в качестве ответа, потому что мне придется передавать файлы в моем проекте странные имена (имена имеют смысл...). Кроме того, некоторые из моих пользовательских инструментов имеют зависимости от их имен файлов, поэтому они также будут сломаны...
Поэтому я по-прежнему открыт для предложений о том, как исправить это правильно.
Ответы
Ответ 1
Из простого теста, который я сделал в VS2013, кажется, что Visual Studio 2013 добавляет метод к "первому" файлу, который он находит в обозревателе решений. Поэтому вы можете просто добавить .something.cs
к своему имени файла, например MyClass.generated.cs
vs MyClass.cs
. Имейте в виду, что VS2013, кажется, использует "полный путь", с упорядочением маршрутов на основе имени. Итак:
Z\MyClass.cs
появляется после
MyClass.generated.cs
(и Intellisense поместит код в MyClass.generated.cs
), даже если в обозревателе решений сначала будут упорядочены все папки.
Полный пример:
А\MyClass.gen3.cs
MyClass.gen2.cs
Z\MyClass.gen1.cs
Это должен быть порядок, "увиденный" Intellisense, поэтому он будет помещать новые классы в A\MyClass.gen3.cs
.
Ответ 2
Предполагая, что вы говорите об EF, я всегда меняю файл шаблона (.tt), так что имя файла автоматически сгенерированного файла [classname].model.cs. Это означает, что мой неполный файл, который по соглашению называется [classname].cs, сначала в алфавитном порядке и всегда кажется, что он выбран для автоматического генерации.
Все, что вам нужно сделать, это найти/заменить все:
fileManager.StartNewFile(entity.Name + ".cs");
С
fileManager.StartNewFile(entity.Name + ".model.cs");
Должно быть 3.
У этого есть другие преимущества, такие как автогенерируемые файлы, четко обозначенные в имени файла.
Я до сих пор не знаю, почему они не делали этого в первую очередь.
Если вы не говорите об EF, тот же трюк использования имени файла для их заказа должен работать.