Как настроить HintPath из корня TFS

Я собираю шаблонный проект в Visual Studio для использования в моем отделе. Проект должен ссылаться на некоторые общие библиотеки, которые хранятся в другом месте в TFS. Проблема в том, что шаблон может использоваться в самых разных местах, и у меня возникают проблемы с надежной настройкой HintPath для обработки всех местоположений.

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

<Reference Include="Company.Common">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\Core Components\Libraries\Company.Common\Latest\Company.Common.dll</HintPath>
</Reference>

Но количество родителей, которые необходимо пройти, чтобы добраться до корня, может варьироваться.

Вместо установки 50 условных путей для ../, ../../, ../../../ и т. д. моей первой мыслью было установить абсолютную ссылку. Рабочие папки стандартизированы в нашей организации, поэтому локально ссылку всегда можно найти в C:\Projects\Core Components\...

Но это не будет работать для серверных сборок. Итак, я думаю, мне нужна какая-то переменная среды, которая работает с $/. Я представляю что-то вроде этого:

<Choose>
  <When Condition="Exists('C:\Projects')">
    <ItemGroup>
      <Reference Include="Company.Common">
        <HintPath>C:\Projects\Core Components\Libraries\Company.Common\Latest\Company.Common.dll</HintPath>
      </Reference>
    </ItemGroup>
  </When>
  <Otherwise>
    <ItemGroup>
      <Reference Include="Company.Common">
        <HintPath>$(TFSRoot)\Core Components\Libraries\Company.Common\Latest\Company.Common.dll</HintPath>
      </Reference>
    </ItemGroup>
  </Otherwise>
</Choose>

Но я не могу понять, как это сделать.

Обновлять:

В конце концов, мы настроили внутренний сервер Nuget. Я предлагаю всем, кто столкнулся с той же дилеммой, просто разобраться с любой бюрократической волокитой, которая мешает вам настроить Nuget. Мы провели 3 года, живя с этим хакерским способом ведения дел, и всегда были какие-то новые морщинки, требующие ручного вмешательства.


tfs environment-variables csproj tfsbuild visual-studio-templates
person friggle    schedule 18.11.2014    source источник
comment
Если это сложно, то вы, вероятно, делаете это неправильно.   -  person MrHinsh - Martin Hinshelwood    schedule 19.11.2014
comment
Я добавил конструктивный комментарий. Я прокомментировал выше, что вы делаете это неправильно, добавив, что если вам нужно попытаться перепрыгнуть через все вышеперечисленные обручи, то, очевидно, есть проблема с подходом. NuGet, как указано ниже, является решением вашей проблемы. Двоичные зависимости — это путь вперед, и следует избегать зависимостей кода.   -  person MrHinsh - Martin Hinshelwood    schedule 20.11.2014
comment
Спустя годы я, наконец, последовал очевидному совету. Nuget — решение этой проблемы.   -  person friggle    schedule 24.10.2018

Ответы (2)


arrow_upward
5
arrow_downward

У меня есть два предложения, как решить эту проблему. Хороший путь и лучший путь.

Хороший способ (и наиболее распространенный) — это если у вас есть некоторая общая библиотека X, и вам нужно использовать ее в приложениях A, B и C. В проекте A у вас будет папка lib, в которую вы зарегистрируете копию X. .dll. Проект B имеет собственную папку lib и собственную копию X.dll (не обязательно ту же версию X, от которой зависит A). И так далее. В этой модели сопровождающие A/B/C сами выбирают, когда загружать новую версию X и обновлять свою папку lib.

Лучше всего использовать NuGet (менеджер пакетов). Project X будет публиковать каждую новую версию в канале NuGet где-нибудь, а A/B/C подпишется на этот канал NuGet, а сборка Visual Studio/TFS автоматически загрузит пакеты NuGet по мере необходимости. Это также дает некоторую дополнительную гибкость, поскольку Project A может либо сказать: «Я завишу от X версии 3.2», либо сказать «Я завишу от последней версии X», а NuGet сделает всю работу.

person Dylan Smith    schedule 18.11.2014
comment
Я бы предположил, что лучший способ @dylan действительно единственный жизнеспособный способ. - person MrHinsh - Martin Hinshelwood; 19.11.2014

arrow_upward
4
arrow_downward

Есть два способа, которые я могу придумать, чтобы достичь того, что вы ищете. Один из них — использовать встроенные макросы VS, другой — создать переменную среды на сервере сборки, а затем сослаться на нее в своем проекте или файле MSBuild:

<Reference Include="EntityFramework.SqlServer">
  <HintPath>..\..\packages\EntityFramework.6.1.2\lib\net45\EntityFramework.SqlServer.dll</HintPath>
  <HintPath>$(SolutionDir)packages\EntityFramework.6.1.2\lib\net45\EntityFramework.SqlServer.dll</HintPath>
  <HintPath>$(ENVIRONMENT_VARIABLE)packages\EntityFramework.6.1.2\lib\net45\EntityFramework.SqlServer.dll</HintPath>
</Reference>
person Nick Wilton    schedule 10.02.2015