#visual-studio #visual-studio-2019 #csproj
#visual-studio #visual-studio-2019 #csproj
Вопрос:
У меня есть решение Visual Studio с проектом, над которым я работаю (основной проект). Решение ссылается на другой проект, который требуется основному проекту в качестве зависимости (проект зависимостей).
Решение и основной проект расположены в одном каталоге:
/mycode/main_project/main_project.sln
/mycode/main_project/main_project.csproj
Проект зависимостей находится в другом каталоге:
/mycode/dependency_project/dependency_project.csproj
Оба этих проекта находятся под управлением исходного кода. Я хочу создать какой-то конфигурационный файл для основного проекта, который не находится под управлением исходного кода, чтобы другой разработчик мог клонировать оба проекта, где захочет, и просто редактировать файл конфигурации, не контролируемый исходным кодом, чтобы позволить решению основного проекта находить проект зависимостей.
В настоящее время основное решение находит проект зависимостей, используя относительный путь:
../dependency_project/dependency_project.csproj
Если я заставлю всех разработчиков клонировать эти два проекта в один и тот же каталог, основное решение будет успешно связано с проектом зависимостей, и все будет хорошо. Однако я бы предпочел, чтобы другой разработчик мог размещать проект зависимостей там, где он хочет.
Поддерживает ли сообщество Visual Studio 2019 какой-либо файл конфигурации решения, который может игнорироваться системой управления версиями и использоваться для разрешения пути к проекту зависимостей?
Ответ №1:
Файлы решений очень примитивны и не предлагают такой динамической функциональности. Однако, если вам не нужно dependency_project отображаться в IDE, вы все равно можете ссылаться на него, main_project.csproj и это дает вам больше возможностей. Он все равно должен нормально работать, даже если проект не отображается в обозревателе решений.
Например, вы можете ссылаться на него через переменную среды с ожидаемым путем по умолчанию, если эта переменная не задана:
<PropertyGroup>
<DependencyProjectPath Condition=" '$(DependencyProjectPath)' == ''>../dependency_project/dependency_project.csproj</DependencyProjectPath>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="$(DependencyProjectPath)" />
</ItemGroup>
Если вы установите переменную DependencyProjectPath среды перед открытием решения (поскольку VS наследует переменные среды с того места, где оно было запущено), оно переопределит здесь настройку по умолчанию (на основе Condition атрибута).
Комментарии:
1. Это хорошее потенциальное решение. Однако одна из причин, по которой я связываю его как ссылку на проект, заключается в том, что при отладке я могу перейти непосредственно к коду dependency_project . При поиске ошибок или проблем удобно иметь возможность перейти непосредственно к коду зависимости, чтобы увидеть, связана ли проблема с базовой библиотекой, а не с кодом, использующим эту библиотеку, или дважды проверить логику библиотеки и убедиться, что я просто неправильно ее использую. Смогу ли я по-прежнему входить в код с помощью отладчика? Или это решение приведет к потере этой функциональности?
2. Что касается отладки, пока вы загружаете символы (или даже используете встроенные символы), исходные метаданные в символах должны указывать на исходные файлы, где они существуют на вашем компьютере. Переход в будет работать нормально. Я часто загружаю символы и вводю код в репозитории, совершенно не связанные с тем, в котором я работаю.