Структурировать решение Visual Studio в Subversion и сохранить ссылки на проекты - PullRequest
0 голосов
/ 04 июня 2019

Имея структурированное a Решение Visual Studio таким образом (после просмотра SO вопроса * 15621 ):

sln/
    dll/
        trunk/dll.vbproj        
    exe/
        trunk/exe.vbproj

Здесь exe.vbproj имеет ссылку на dll.vbproj.Все должно быть хорошо, если я создаю каждый проект с MSBuild .

Теперь я хочу пометить проекты dll и exe:

sln/
    dll/
        tags/1.0.0/dll.vbproj
        trunk/dll.vbproj       
    exe/
        tags/1.0.0/exe.vbproj
        trunk/exe.vbproj

Я добавил глубину в одинбольше каталога.Следовательно, я не смогу построить exe/tags/1.0.0/exe.vbproj, если не исправлю ссылку на путь dll/tags/1.0.0/dll.vbproj вручную.

Я что-то не так сделал? Нет ли способа избежать ручного редактирования?

1 Ответ

1 голос
/ 11 июня 2019

Обычно, когда мы добавляем ссылку на проект в dll в одном exe-проекте, щелкнув правой кнопкой мыши проект добавить ссылку на проект, изменение в файле exe.xxproj должно выглядеть следующим образом:

  <ItemGroup>
    <ProjectReference Include="..\..\DllName\trunk\DllName.vbproj">
      <Project>{1fe037b8-5561-4aa0-895d-8bad9eadad20}</Project>
      <Name>DllName</Name>
    </ProjectReference>
  </ItemGroup>

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

  <!--When in a trunk folder-->
  <ItemGroup Condition="'$(ProjectDir)'=='$(SolutionDir)$(AssemblyName)\trunk\'">
    <ProjectReference Include="..\..\dll\trunk\dll.vbproj">
      <Project>{1fe037b8-5561-4aa0-895d-8bad9eadad20}</Project>
      <Name>dll</Name>
    </ProjectReference>
  </ItemGroup>

  <!--Not in a trunk folder-->
  <ItemGroup Condition="'$(ProjectDir)'!='$(SolutionDir)$(AssemblyName)\trunk\'">
    <ProjectReference Include="$(SolutionDir)dll\tags\$(VersionNumber)\dll.vbproj">
      <Project>{1fe037b8-5561-4aa0-895d-8bad9eadad20}</Project>
      <Name>dll</Name>
    </ProjectReference>
  </ItemGroup>

И для этого скрипта, когда он находится в папке тегов. Для поиска мы используем путь: $(SolutionDir)dll\tags\$(VersionNumber)\dll.vbproj. Но значение $ (VersionNumber) нам неизвестно. ($(SolutionDir), $(ProjectDir) - это предопределенные значения)

Таким образом, значение этого зависит:

1.Если каждый раз, когда у вас будет обновленная версия проекта, вы будете удалять или перемещать старые версии.

Я имею в виду для fileversion 1.0.0.0, там есть папка 1.0.0.0 под тегами fodler, когда вы обновляете ее до 2.0.0.0, существует только одна папка 2.0.0.0 вместо папок 1.0.0.0 и 2.0.0.0 в папке тегов. Для этой ситуации: Путь может быть что-то вроде: $(SolutionDir)dll\tags\$(VersionNumber)\dll.vbproj

2.Если вы предварительно определили свойство $ (VersionNumber) в файле .xxproj, путь может быть: $(SolutionDir)dll\tags\$(VersionNumber)\dll.vbproj

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

3. Теперь все, что нам нужно сделать, это получить значение свойства AssemblyFileVersion в процессе сборки. Для вашей ситуации вам нужно получить номер AssemblyFileVersion перед сборкой, пожалуйста, проверьте First Direction в этой теме для более подробной информации.

Для шаблонов: измените с <Pattern>\[assembly: AssemblyVersion\(.(\d+)\.(\d+)\.(\d+).(\d+)</Pattern> на <Pattern>\[assembly: AssemblyFileVersion\(.(\d+)\.(\d+)\.(\d+).(\d+)</Pattern>, если вы структурируете их по версии файла.

$ (VersionNumber) должен быть таким:

<PropertyGroup>
    <VersionNumber>$(FirstNum).$(SecondNum).$(ThirdNum).$(FourthNum)</VersionNumber>
</PropertyGroup>

Так что следите за своим исходным постом:

Я сделал что-то не так? Нет ли способа избежать ручного редактирования?

Все, что вы сделали, для вашей конкретной ситуации, ничего плохого. Есть некоторый способ избежать ручного редактирования, но я не уверен, удовлетворяет ли этот способ вашим потребностям. Иногда, когда мы хотим избежать какого-либо ручного редактирования, нам требуется гораздо больше работы для достижения этого подхода. Надеюсь, все выше помогает:)

...