Что перечисляется в секции references ссылки проекта в visual studio или других ide

Обновлено: 07.07.2024

Сейчас мы рассмотрим более детально, что происходит во время выполнения программы из предыдущего занятия.

Программный код, который вы вводили на занятии 1, представляет собой набор инструкций на языке, понятном человеку. Это так называемый «исходный код», который, чтобы быть исполненным, должен быть преобразован в код, понятный компьютеру. «Построение» (build) и есть процесс формирования исполняемого кода в виде стандартного EXE-файла Windows. Результатом построения может быть и DLL (библиотека динамической компоновки), которую можно загрузить в Autodesk Inventor, однако это более сложная тема, и ее в данном курсе мы обсуждать не будем.

На следующем рисунке показана копия экрана с результатами построения проекта из предыдущего занятия: выходной ЕХЕ-файл и вспомогательные файлы с отладочной информацией (она используется при отладке в случае каких-либо проблем с исполняемым файлом). Путь, по которому создается ЕХЕ-файл, задается в установках проекта Visual Basic Express. Здесь он установлен по умолчанию — папка bin внутри папки проекта Visual Basic Express.


Выбор языка программирования и средств разработки

Visual Basic Express представляет собой интегрированную среду разработки (Integrated Development Environment, сокращенно IDE). Среда включает в свой состав различные инструменты, меню, командные панели, которые облегчают создание и работу с вашим программным кодом.

Система проектов Visual Basic Express состоит из решений (solution), файлов проектов и компонентов проектов (отдельных файлов, включенных в проект). Каждое решение представляет собой контейнер для одного или нескольких проектов. Каждый проект можно, в свою очередь, рассматривать как контейнер для его компонентов — исходных файлов, иконок и т.п., большая часть которых используется для формирования результирующих исполняемых файлов (EXE или DLL). Visual Basic Express предоставляет в наше распоряжение Обозреватель решения (Solution Explorer), который организует и отображает содержимое текущего решения в древовидном формате.


Интерфейс Visual Basic Express включает также текстовый редактор и конструктор оконных интерфейсов. Их отображение в главном окне среды разработки зависит от типа редактируемого файла. Текстовый редактор — это то место, где вы будете вводить текст вашей программы на Visual Basic. Этот редактор предоставляет в ваше распоряжение такие мощные инструменты как IntelliSense и сворачиваемые секции наряду с такими более традиционными средствами работы с текстом как закладки и нумерация строк программы.

IntelliSense — чрезвычайно удобный и полезный инструмент Visual Studio, который заметно повышает производительность программиста. В процессе ввода кода он автоматически выводит контекстно-чувствительные подсказки в зависимости от редактируемого объекта и вводимых символов. На следующем рисунке IntelliSense отображает доступные свойства и методы объекта ComponentOccurrence:



Визуальное в Visual Basic Express

Одной из наиболее сильных сторон Visual Basic Express является набор средств для создания интерфейса пользователя. При создании нового проекта вы можете выбрать вариант Приложение Windows Forms. При использовании этого шаблона автоматически создается главное окно приложения. Это окно называется формой, и вы можете разместить на ней элементы пользовательского интерфейса, называемые элементами управления, например, кнопки. Вы добавляете в форму элементы управления простым перетаскиванием их из Панели элементов в рабочую область формы. Панель элементов можно открыть, используя меню Вид > Панель элементов. Большая часть кода, необходимого для корректной работы элементов управления, добавляется в проект автоматически, что серьезно облегчает и ускоряет разработку приложения.

Обзор применения Visual Basic Express

В этом разделе вы создадите пустой проект, похожий на проект из первого занятия. Этот проект послужит отправной точкой для занятия 3.

    Создание приложения Windows Forms:
    Закройте в Visual Basic Express все открытые проекты. Затем создайте новый проект,
    используя меню Файл> Создать проект…Эта команда выведет на экран диалоговое окно «Создать проект», в котором вам предоставляется возможность выбрать шаблон проекта для создания плагина.


Поскольку вы работаете с Visual Basic Express, установленные шаблоны следует искать в разделе Visual Basic.
Список доступных шаблонов приложений располагается в центральной области диалогового окна. Выбор шаблона зависит от типа создаваемого приложения. Поскольку вы создаете простое EXE приложение с диалоговым интерфейсом, следует выбрать шаблон Приложение Windows Forms.

Теперь следует присвоить проекту имя. Для этого в нижней части диалога в текстовом поле Имя введите MyFirstInventorPlug-in и нажмите OK: В результате будет создано и открыто в редакторе Visual Basic Express новое решение, которое уже содержит ваш проект.


Но этот проект еще не в состоянии работать с Inventor API. Чтобы это стало возможным, требуется ввести в проект ссылку на интерфейсную DLL Инвентора с описанием его API — Autodesk.Inventor.Interop.dll.

Правым кликом на проекте в Обозревателе решений откройте контекстное меню и выберите пункт Добавить ссылку… С помощью вкладки Обзор внутри папки, в которой на вашем ПК установлен Inventor, найдите папку Public Assemblies. Путь к ней выглядит следующим образом:
C:\Program Files\Autodesk\Inventor 201x\Bin\Public Assemblies


Выделите файл Autodesk.Inventor.Interop.dll и нажмите OK.

Теперь ссылка на Inventor API включена в ваш проект.

Примечание:
Открыть Обозреватель объектов можно через меню Вид либо с помощью функциональной клавиши F2.


Чтобы построить проект, используйте пункт Построить <имя проекта> в меню Построение.


Visual Basic Express или Visual Studio Professional?

В данном руководстве использован Visual Basic Express. Эта бесплатная версия Visual Studio является прекрасным инструментом, который поможет вам начать разработку VB-кода для вашего плагина без дополнительных затрат на программное обеспечение. Microsoft позиционирует редакции Express как инструмент для студентов, любителей и прочих нерегулярно программирующих пользователей. Несмотря на присутствие большинства важных функциональных особенностей Visual Studio Professional, таких как IntelliSense, редакции Express все же имеют и ряд ограничений. Например, в Visual Basic Express доступно заметно меньшее количество шаблонов приложений, есть ограничения в средствах диагностики проблем и вариантах отладки кода. Если вы в дальнейшем намерены серьезно заниматься разработкой приложений, мы рекомендуем рассмотреть варианты приобретения более профессиональной версии семейства Visual Studio.

Что такое COM?

«Microsoft COM (Component Object Model) — технология, реализованная в семействе операционных систем Windows с целью обеспечить взаимодействие программных компонентов. COM используется разработчиками для создания многократно используемых программных компонентов, объединения компонентов в приложения и использования преимуществ служб Windows. Объекты COM могут создаваться различными инструментами разработки. Объектно-ориентированные языка типа С++ предоставляют программные механизмы для упрощения разработки COM-объектов.»
Перевод из MSDN Library.

Построение исполняемого кода

В данном руководстве вы сфокусируетесь на разработке приложения конкретного типа: сборки исполняемого кода (EXE), который взаимодействует с Inventor. EXE-приложения проще в разработке, и вам не придется тратить время на изучение надстроек Inventor AddIns в виде DLL, которые загружаются и работают в одном процессе с Инвентором. Разработка EXE для работы с Inventor проще и в части создания интерфейса. Обычно внешнему исполняемому приложению не требуется гладко встраиваться в пользовательский интерфейс самого Inventor, создавая, скажем, свои кнопки в ленте.

Схемы выполнения EXE программы

На последнем этапе этого процесса родной машинный код исполняется процессором компьютера.

Перед написанием кода для внешних компонентов или подключенных служб необходимо включить в проект ссылки на них. По сути, ссылка — это запись в файле проекта, которая содержит сведения, необходимые Visual Studio для поиска компонента или службы.

Чтобы добавить ссылку, в обозревателе решений щелкните правой кнопкой мыши узел Ссылки или Зависимости и выберите команду Добавить ссылку. Вы также можете щелкнуть узел проекта правой кнопкой мыши и выбрать пункт Добавить > Ссылка. Дополнительные сведения см. в разделе Практическое руководство. Добавление и удаление ссылок.

Добавление ссылки в Visual C++

Вы можете добавить ссылку на следующие типы компонентов и служб:

Приложения универсальной платформы Windows

другие сборки или библиотеки классов проектов в том же решении;

Ссылки на приложения UWP

Ссылки на проекты

Проекты универсальной платформы Windows (UWP) могут создавать ссылки на другие проекты UWP в решении либо на двоичные файлы или проекты, ориентированные на Windows 8.1, при условии, что эти проекты не используют интерфейсы API, которые являются устаревшими в Windows 10 и более поздних версиях. Более подробную информацию см. в разделе Перенос приложения из среды выполнения Windows 8 в UWP.

Если вы решили изменить целевую платформу проектов Windows 8.1 на Windows 10 или более поздней версии, ознакомьтесь со статьей Перенос, миграция и обновление проектов Visual Studio.

Справочник по пакетам SDK расширений

Если выяснится, что пакет SDK расширений, на который ссылается ваше приложение, не поддерживается, то вы должны выполнить следующие действия.

Посмотреть имя проекта, который вызывает ошибку. Платформа, для которой предназначен этот проект, указывается в скобках рядом с именем проекта. Например, MyProjectName (Windows 8.1) означает, что проект MyProjectName предназначен для платформы Windows 8.1.

Перейдите на сайт поставщика неподдерживаемого пакета SDK расширений и установите версию пакета SDK расширений с зависимостями, совместимыми с версией платформы, для которой предназначен ваш проект.

Если проект предназначен исключительно для Windows 10 и установленный в предыдущем шаге пакет SDK расширений имеет зависимость от пакета среды выполнения Microsoft Visual C++, то совместимой с Windows 10 версией этого пакета является v14.0, которая устанавливается вместе с Visual Studio.

Если установленный на предыдущем шаге пакет SDK расширений имеет зависимости от других пакетов SDK расширений, перейдите на сайты поставщиков, являющихся владельцами зависимостей, и установите версии этих зависимостей, совместимые с версией платформы, для которой предназначен ваш проект.

Перезапустите Visual Studio и откройте ваше приложение.

Щелкните правой кнопкой мыши узел Ссылки или Зависимости в проекте, который вызвал ошибку, и выберите команду Добавить ссылку.

Добавление ссылки во время разработки

При создании ссылки на сборку в проекте Visual Studio ищет сборку в следующих расположениях:

Каталог текущего проекта. (Можно найти эти сборки, используя вкладку Обзор .)

Другие каталоги проектов в одном решении. (Вы можете найти эти сборки на вкладке Проекты .)

  • Все проекты содержат неявную ссылку на библиотеку mscorlib.
  • Все проекты содержат неявную ссылку на System.Core , даже если System.Core была удалена из списка ссылок.
  • Проекты Visual Basic содержат неявную ссылку на Microsoft.VisualBasic.

Ссылки на общие компоненты во время выполнения

По умолчанию для свойства CopyLocal задается значение False , если сборка или компонент находится в глобальном кэше сборок или является компонентом платформы. В противном случае задается значение True. Ссылки проектов на проекты всегда имеют значение True.

Ссылки проектов на проекты

Ссылки проектов на проекты — это ссылки на проекты, которые содержат сборки. Вы добавляете их на вкладке Проекты диалогового окна "Диспетчер ссылок". Visual Studio может найти сборку, если задан путь к проекту.

Ссылки на общий проект

В отличие от большинства других типов проектов, у общего проекта нет двоичных выходных данных. Вместо этого код компилируется в каждый проект, который ссылается на него. Общие проекты позволяют писать общий код, на который ссылается несколько различных проектов приложений. Код компилируется как часть каждого ссылающегося проекта и может включать директивы компилятора, которые помогают внедрить функции конкретной платформы в общую базу кода. Добавьте ссылку на общий проект на вкладке Общие проекты диалогового окна "Диспетчер ссылок".

Ссылки на файлы

Ссылки на файлы — это прямые ссылки на сборки вне контекста проекта Visual Studio. Они создаются на вкладке Обзор диспетчера ссылок. Ссылку на файл следует использовать в случае, если имеется лишь сборка или компонент, но не проект, который создает ее в качестве выходных данных.

Для эффективной разработки и выполнения сборочного процесса в групповой среде, важно начать с создания правильной структуры проекта, одинаковой на всех компьютерах разработчиков и на сервере сборки (build server).

В этой главе даны рекомендации по:

К наиболее распространенным типам локальных проектов относятся Windows-приложения и библиотеки классов, хотя существует и множество других типов, в том числе проекты служб, консольных приложений, баз данных и т. д.

Файлы решений (с расширением .sln) объединяют в группу связанные проекты и применяются в основном для управления процессом сборки. С их помощью можно управлять зависимостями и порядком, в котором собираются содержащиеся в них проекты.

Внимание Проект может быть частью одного или нескольких решений, но решения не могут включать другие решения.

Рис. 3.1 иллюстрирует связь между проектами и решениями и типы файлов, в которых VSS хранит параметры уровней решения и проекта.

Solution - Решение
Dependencies - Зависимости
Project - Проект
User Specific File (Not Version Controlled) - Файл, специфичный для пользователя (вне системы контроля версий)
AppName - Имя приложения
Non-User Specific File (Version Controlled) - Файл, не специфичный для пользователя (в системе контроля версий)

Решения и сборочные зависимости

Файлы, включаемые в систему контроля исходного кода

Прочие файлы, в том числе пользовательский файл решения (.suo) и файл проекта (.csproj или .vbproj), тоже обновляются.

Разбиение решений и проектов на отдельные части

Способ разбиения решений и проектов существенно влияет на процессы разработки и сборки в среде групповой разработки.

Существует три основных модели разбиения решений и проектов. Их список дан в порядке предпочтительности:

  1. Единое решение.
  2. Единое решение, разбитое на части.
  3. Несколько решений.

Внимание Если у вас нет веских причин на то, чтобы задействовать модель на основе нескольких решений, избегайте ее и принимайте либо модель на основе единственного решения, либо (для больших систем) модель на основе решения, разбитого на части. С ними проще работать; к тому же, у них есть ряд важных преимуществ по сравнению с моделью на основе нескольких решений, о чем и рассказывается в следующих разделах.

По возможности применяйте модель на основе единственного решения

File Reference - Файловая ссылка
Project Reference - Ссылка на проект
Solution 1 - Решение 1
Project - Проект
Outer System Boundary - Внешняя граница системы
Inner System Boundary - Внутренняя граница системы
External Assemblies Third Party Components - Внешние сборки, в том числе компоненты сторонних поставщиков

Рис. 3.2. Модель на основе единственного решения

По возможности используйте именно эту модель, так как у нее есть ряд существенных преимуществ.

Преимущества

Недостатки

  • масштабирование этой модели ограничено. Даже если вам понадобится всего один проект из решения, придется получать исходный код всех проектов этого решения;
  • даже незначительные изменения в единственном файле исходного кода в одном проекте могут вызвать повторную сборку (rebuild) многих проектов в решении из-за зависимостей между проектами. Если в проекте, на который вы ссылаетесь, изменяется интерфейс сборки (assembly), вам потребуется перекомпилировать клиентский проект. А компиляция зависимых проектов может быть весьма длительной, особенно если в решении их много.

Для больших систем используйте модель, в которой решение разбивается на части

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

Это позволит вам и вашим коллегам работать над раздельными подсистемами меньшего размера в пределах внутренней системы.

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

На рис. 3.3 показана модель решения, разбитого на части. Обратите внимание на использование отдельных файлов решения, позволяющих работать с подсистемами меньшего размера в границах внутренней системы. Также заметьте, что в результате проекты содержатся более чем в одном файле решения. Например, проекты D и H размещаются в трех файлах решения, включая главный файл решения.

File Reference - Файловая ссылка
Project Reference - Ссылка на проект
Solution 1 - Решение 1
Project - Проект
Outer System Boundary - Внешняя граница системы
Inner System Boundary - Внутренняя граница системы
External Assemblies Third Party Components - Внешние сборки и компоненты оот сторонних поставщиков
Master Solution - Главное решение

Рис. 3.3. Модель решения, разбитого на части

  • все проекты содержатся в главном файле решения. Он используется сборочным процессом для сборки всей системы. Если вы работаете с файлом проекта верхнего уровня, вы работаете и с главным решением;
  • между индивидуальными проектами существуют ссылки на проекты;
  • для некоторых файлов проектов вводятся отдельные файлы решения. При желании можно создать файл решения для каждого проекта в системе. Каждый файл решения содержит файл основного проекта и все нижестоящие проекты, от которых он зависит, а также проекты, от которых зависят только что упомянутые нижестоящие проекты, - и так до конца по всей цепочке зависимостей;
  • отдельные файлы решения позволяют работать с подсистемами меньшего размера, по-прежнему используя основные преимущества ссылок на проекты. В каждом файле подрешения между составляющими его проектами создаются ссылки на проекты.
    Примечание Не разделяйте два ссылающихся друг на друга проекта между решениями, так как в этом случае вам потребуется файловая ссылка, чего по возможности следует избегать. Подробнее на эту тему см. раздел Ссылки на сборки в главе 4 "Управление зависимостями".

Преимущества

Недостатки

Используйте модель на основе нескольких решений, только если это действительно необходимо

  • нет главного файла решения;
  • между проектами в разных решениях используются файловые ссылки (хотя ссылки на проекты по-прежнему применяются в рамках проектов одного решения);
  • сценарий сборки системы, выполняемый на сервере сборки, последовательно компилирует каждое решение на основе известных отношений зависимости (dependency relationships). Сценарий сборки помещает результаты в фиксированное место на сервере.

Модель на основе несокльких решений показана на рис. 3.4.

File Reference - Файловая ссылка
Project Reference - Ссылка на проект
Solution - Решение
Project - Проект
Outer System Boundary - Внешняя граница системы
Inner System Boundary - Внутренняя граница системы
External Assemblies Third Party Components - Внешние сборки и компоненты от сторонних поставщиков

Рис. 3.4. Модель на основе нескольких решений

Преимущества

  • Каждый проект содержится только в одном решении. Поэтому добавлять и удалять проекты из системы проще.
  • Можно разделить систему на несколько решений, исходя из логических границ и не обращая внимания на зависимости между проектами. Так, разделение может быть основано на областях бизнес-функциональности.

Недостатки

Рекомендации по группировванию проектов в решения

Используйте согласованную структуру папок для проектов и решений

Определите общую корневую папку

Определите общую корневую папку, например C:\Projects в файловой системе и $/Projects в VSS. Она будет служить контейнером для всех разрабатываемых систем.

В общей корневой папке создайте корневые папки для всех систем, например C:\Projects\MyCompanysInsuranceApp и $/Projects/MyCompanysInsuranceApp соответственно.

Применяйте иерархическую структуру папок для решений и проектов

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

Рекомендуемая структура показана на рис. 3.5.

Включайте в имя решения слово Solution или Soln - так проще различать имена решения и проекта.

Рекомендуемая структура приведена на рис. 3.6. Заметьте, что папка проекта и виртуальный корень Microsoft Internet Information Server (IIS) совпадают.

Local File System - Локальная файловая система
VSS Project Structure - Структура проекта VSS
Project folder AND IIS Virtual Root - Папка проекта и виртуальный корень IIS

Рис. 3.6. Рекомендуемая структура Web-приложения

Чтобы создать новое Web-приложение с такой структурой

Как разбить Web-приложение на несколько проектов

Внимание Подход, при котором используется один проект, проще, так что разбивайте Web-приложение на несколько проектов, только если это действительно необходимо. Обычно такая необходимость возникает в очень больших Web-приложениях.

Дополнительные сведения

Как создать новый проект, отличный от Web-приложения

Далее рассказывается, как создать проект, отличный от Web-приложения, скажем, консольную или Windows-программу, библиотеку классов или сервис. Предполагается, что решение называется MyWinAppSolution, а проект - MyWinApp. Рекомендуемая структура приведена на рис. 3.7.

Local File System - Локальная файловая система
VSS Project Structure - Структура проекта VSS

Рис. 3.7. Рекомендуемая структура проекта для приложений, не связанных с Web

Чтобы создать новое приложение, отличное от Web, с такой структурой

О добавлении нового проекта и решения к Visual SourceSafe см. раздел Как зарегистрировать в VSS новое решение главы 6 "Работа с Visual SourceSafe".

Тщательно обдумайте соглашения об именовании

Тщательно и заранее обдумайте, как вы будете именовать проекты, сборки, папки и пространства имен. Хотя эти элементы можно переименовать на более поздних этапах цикла разработки, старайтесь этого избегать. О том, как переименовать проект, см. раздел Переименование проекта главы 6 "Работа с Visual SourceSafe".

Также стремитесь к непротиворечивости имен, поскольку это существенно упрощает организацию проекта.

Используйте общие имена для проектов и сборок

Имя выходной сборки должно всегда совпадать с именем проекта, в котором она создается. Например, сборка MyCompany.Utilities.Data.dll должна создаваться в проекте MyCompany.Utilities.Data.

При изменении имени выходной сборки измените имя проекта и наоборот.

Используйте общее имя корневого пространства имен

Корневое пространство имен, в котором вы размещаете ваши типы (структуры, классы, интерфейсы и т. д.), должно соответствовать имени проекта и сборки.

Так, в сборке MyCompany.Utilities.Data.dll корневое пространство имен должно называться MyCompany.Utilities.Data.

Используйте общие имена для папок VSS и локальных папок

Как уже говорилось, синхронизируйте имена папок решений и проектов с эквивалентными именами папок в VSS.

GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.

c-sharp / terminology_intro

Users who have contributed to this file

  • © 2020 GitHub, Inc.
  • Terms
  • Privacy
  • Security
  • Status
  • Help

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.


Недавно я допилил одну проблему, которая меня уже очень давно достает. Суть ее в том, что диалог Add Reference в Visual Studio не нужен, если вы берете сборку из одного из тех мест, где их ищет студия. Не нужен он потому, что студия вполне могла бы сама проиндексировать все пространства имен в этих сборках и при написании using Biztalk дать мне возможность добавить ссылку автоматически. Поскольку студия это делать не умеет, пришлось ей помочь.

Идея сама по себе простая, и состоит из 2 х частей, а именно:

  • Нужно найти все важные сборки и проиндексировать все их пространства имен.
  • При наведении курсора на using , нужно сделать поиск всех возможных сборок и показать меню.

Индексирование

База для пространств имен и путям к файлам сборок делается за секунды. Единственный трюк – это использование Cecil вместо извращений вроде Assembly.ReflectionOnlyLoad() , которые пытаются подгрузить зависимости и ещё невесть что. Быстренько находим все типы, записываем их простнанства имен в HashSet , и засовываем все это в базу. Как? Об этом сейчас и поговорим.

Во-первых, пути к файлам которые использует Add Reference находятся как минимум в 2 х местах – в реестре, и в папке PublicAssemblies. Чтобы найти те папки, которые указаны в реестре, я написал следующий код:

public static IEnumerable string > GetAssemblyFolders()

string [] keyNames = new []

var result = new HashSet string >();

foreach ( var keyName in keyNames)

using ( var key = Registry.LocalMachine.OpenSubKey(keyName))

foreach ( string subkeyName in key.GetSubKeyNames())

using ( var subkey = key.OpenSubKey(subkeyName))

if (subkey != null )

foreach ( string valueName in valueNames)

string value = (subkey.GetValue(valueName) as string ?? string .Empty).Trim();

if (! string .IsNullOrEmpty( value ))

Изначально у меня мало что работало, т.к. ключи на 32-битной и 64-битной системе разные. В очередной раз замечаю что с переходом на 64-битную систему начал писать более качественный код 🙂

Чтобы найти папку PublicAssemblies, нужно сначала найти где установлена Visual Studio:

public static string GetVS9InstallDirectory()

var keyNames = new string []

foreach ( var keyName in keyNames)

using ( var key = Registry.LocalMachine.OpenSubKey(keyName))

return key.GetValue( "ProductDir" ).ToString();

Имея список папок, можно в каждой искать все DLL-файлы и индексировать их. Помимо тех папок что всегда фигурируют в диалоге Add Reference, можно добавлять свои папки, что бывает удобно.

using ( var dc = new StatsDataContext())

var dirs = new HashSet string >();

dirs.Add( @"C:Program Files (x86)JetBrainsReSharperv4.5Bin" );

foreach ( var dir in GetAssemblyFolders()) dirs.Add(dir);

foreach ( string dir in dirs.Where(Directory.Exists))

string [] files = Directory.GetFiles(dir, "*.dll" );

var entries = new HashSet ();

foreach ( string file in files)

var ns = AddNamespacesFromFile(file);

foreach ( var n in ns)

Добавление происходит с помощью метода AddNamespacesFromFile() который, как я уже писал, использует Mono.Cecil.

private static IEnumerable AddNamespacesFromFile( string file)

HashSet result = new HashSet ();

var ad = AssemblyFactory.GetAssembly(file);

foreach (ModuleDefinition m in ad.Modules)

foreach (TypeDefinition type in m.Types)

if (type.IsPublic && ! string .IsNullOrEmpty(type.Namespace))

result.Add( new Namespace

С наполнением базы на этом все. Далее можно пользоваться результатами, хотя я помимо этого сделал фоновую утилиту которая позволяет освежать данные и добавлять новые пути.

Использование

Не имея лучших вариантов, я реализовал добавление ссылок как context action для ReSharper. Идея простая – пользователь наводит курсор на слово Biztalk в строке using Biztalk; и видит магическое меню, при выборе элементов которого автоматически добавляется ссылка в проект.

protected override bool IsAvailableInternal()

items = EmptyArray .Instance;

var element = GetSelectedElement ( false );

if (element == null )

var parent = element.ToTreeNode().Parent;

if (parent == null || parent.GetType().Name != "ReferenceName" || parent.Parent == null

string s = parent.Parent.GetText();

if ( string .IsNullOrEmpty(s))

var bulbItems = new HashSet ();

using ( var conn = new SqlConnection(

"Data Source=(local);Initial Catalog=Stats;Integrated Security=True" ))

var cmd = new SqlCommand(

using ( var r = cmd.ExecuteReader())

bulbItems.Add( new RefBulbItem(

Все интересное происходит в BulbItem ах, то есть желтых лампочках которые появляются в процессе вызова контекстного меню. Сама лампочка – это некий POCO который умеет в нужный момент добавить ссылку на определенную сборку.

protected override void ExecuteBeforeTransaction(ISolution solution,

JetBrains.TextControl.ITextControl textControl, IProgressIndicator progress)

var project = provider.Project;

if (project == null ) return ;

var fileSystemPath = FileSystemPath.TryParse(path);

if (fileSystemPath == null ) return ;

var assemblyFile = provider.Solution.AddAssembly(fileSystemPath);

if (assemblyFile == null ) return ;

var cookie = project.GetSolution().EnsureProjectWritable(project, out project, SimpleTaskExecutor.Instance);

Код выше удалось написать только с помощью члена команды JetBrains (planerist – спасибо!), т.к. у меня у самого не хватило усидчивости чтобы найти правильный способ.

Закладка References (только для языка Visual Basic)


Одной из особенностей этой закладки, предназначенной для разработчиков программ на языке Visual Basic, является кнопка Unused References, позволяющая выполнять поиск ссылок, которые можно удалить. Кроме того, можно добавлять пути к ссылкам (reference path), что дает возможность включать все сборки, расположенные в данном месте.

Закладка Resources

Ресурсы проекта можно добавлять и удалять с помощью закладки Resources, показанной на рисунке ниже. В приведенном примере в приложение были добавлены две пиктограммы. Ресурсами могут быть изображения, текст, файлы и другие сериализуемые классы.


Этот интерфейс существенно облегчает работу с файлами ресурсов во время проектирования.

Читайте также: