Я пишу Add-in для студии, который бы позволил более эффективно компилировать проекты gcc компилятором, которым мы пользуемся.
На данный момент самой важной и насущной проблемой является управление компилятором, получение текущих настроек и установка своих, и вот тут начинаются проблемы 🙁
Для любого Add-in доступен объект типа EnvDTE2, который предоставляет доступ ко всему, что есть в студии, т.е. например EnvDTE.Solution.Projects возвращает набор проектов, без всякой привязки к конкретному языку, этого достаточно для создания всяких формочек и настроек, но не достаточно для того, чтобы можно было управлять компилятором. Поиски в документации MSDN выявили пространство имен Microsoft.VisualStudio в котором есть интересные классы – такие как VCProject, VCProjectEngine, которые предоставляют все необходимые средства для управления C++ проектом и всеми его тонкими настройками.
Существует лишь одна проблема – как получить объект VCProjectEngine?
Майкрософт пишет, что это можно сделать к примеру при помощи CoCreateInstance – но в реальности этот метод вызывает проблемы, которые выражаются в странном поведении VS2005.
Существует еще один способ, недокументированный.
Мы можем получить список C++ проектов таким образом:
Projects projects = (Projects)dte.GetObject(“VCProjects”);
После этого мы делаем следующее:
VCProjectEngine engine = (VCProjectEngine)projects.Properties.Item(“VCProjectEngine”);
К сожалению этот метод не работает 🙂 Хотя тот источник, из которого я его почерпнул пишет, что именно при помощи него они все сделали.
Последняя строчка вызывает InvalidCastException, т.е. объект возвращается, но он не является тем, что нам нужно.
Update
Получить объект VCProject и VCProjectEngine удалось.
Поиски по форумам увенчались успехом и в одном из постов какого-то чина из майкрософт я нашел подходящий код, который без всякого хакерства работает как положено 🙂
Projects projects = (Projects)_applicationObject.Solution.Projects;
VCProject vcproj = null;
foreach (Project p in projects)
{
vcproj = p.Object as VCProject;
}
Debug.Assert(vcproj != null);
Суть заключается в том, что проект из объектной модели automation хранит ссылку на объект VCProject – ну а дальше мы просто этот объект извлекаем.
Теперь для того, чтобы получить настройки компилятора нам надо получить ссылку на текущую конфигурацию. Для этого мы воспользуемся свойством Configurations.
И хотя это не текущая конфигурация, но все же то, что надо 🙂
Debug.Assert((vcproj.Configurations as IVCCollection).Count != 0);
VCConfiguration conf = (vcproj.Configurations as IVCCollection).Item(1) as VCConfiguration;
Самый главный момент, понятый мной – это то, что в пространстве Microsoft.VisualStudio в качестве контейнера используется не System.Array, а IVCCollection – эта неочевидность вынудила меня потратить лишний час на понимание сути проблемы – почему нельзя было извлечь объект из контейнера.
Теперь мы получаем ссылку на элемент Tool – это непосредственно та вещь, которая позволяет управлять всеми настройками компилятора.
Debug.Assert((conf.Tools as IVCCollection).Count != 0);
VCNMakeTool tool = (conf.Tools as IVCCollection).Item(1) as VCNMakeTool;
Так как в нашем случае используется Makefile project – то мы приводим к типу VCNMakeTool
Собсно все – теперь мы получили полный контроль над процессом компиляции.
В принципе – это лишь первый шаг – поскольку нужно отказываться от промежуточной стадии в виде makefile и создавать свой тип проекта со своими настройками сборки программы, а соответственно и совершенствовать Add-in дальше.
