Обновление программных ссылок Visual Studio программно

Question

Я хочу программно обновить ссылки в проектах в моем решении Visual Studio.

У меня примерно 15 проектов в моем решении, и когда я разрабатываю/отлаживаю, я хочу, чтобы ссылки указывали на проекты внутри решения.

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

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

Мои вопросы:
1. Значит ли это звук разумным, что нужно сделать
2. Кто-нибудь опыт этого и/или как они ручки переключения между развивающимися и освободить режимы
3. Есть ли у кого-либо библиотеки, которые занимаются анализом файлов проекта Visual Studio.

ПОЯСНЕНИЯ:

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

a) Мое приложение содержит 15 проектов. Я стараюсь как можно меньше поддерживать то, над чем я работаю, поэтому скажу, что у меня есть 5 проектов в моем решении. Теперь мне нужно отлаживать/разрабатывать один из проектов не в решении, поэтому я добавляю этот проект, но мне нужно: - установить ссылки в исходных проектах, чтобы указать ссылки на проекты, а не скомпилированные DLL - изменить ссылки в добавленный проект, чтобы указать на соответствующий проект ссылается

Я хотел бы мой инструмент, чтобы сделать это автоматически, и единственный способ, которым я знаю, так это в настоящее время манипулирует файлы проекта

б) в рамках сервиса Процедура сборки пакета Я беру копию одного из проектов, делаю необходимые изменения кода и строю с помощью Visual Studio. Для этого мне нужно изменить все ссылки на скомпилированные dlls

Answer 1

Я думаю, что лучшим подходом к этому было бы использование условных блоков в ваших ссылках внутри файла проекта напрямую. Тогда все, что вам нужно сделать, это установить определенный флаг во время msbuild для сборки «release», и он подберет правильные ссылки.

Например

<ItemGroup Condition="'$(IsRelease)'=='True'"> 
    <Reference Include="..." /> 
</ItemGroup> 
<ItemGroup Condition="'$(IsRelease)'!='True'"> 
    <Reference Include="..." /> 
</ItemGroup> 

Answer 2

Похож нечетная ситуацией.

Мое предложение.

1. Разделите проекты, в которых есть готовые версии, в отдельное решение.Пусть они все строят для

   \ сборок \ fromsource

2. Копирования скомпилированных из них в;

   \ сборки \ прекомпилированного

3. Перед разработки остальных проектов, либо скопировать каталог в

   \ Assembly \ развитие

4. Изменить свои проекты, чтобы указать на версию в \ сборка \ развитие.

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

Для получения бонусных очков измените событие предварительной сборки, чтобы скопировать DLL-файлы перед началом работы, и исходная папка зависит от конфигурации. Затем добавьте конфигурацию PREBUILT вместе с DEBUG и RELEASE.

Answer 3

Tiger, Tiger ROAR !!!

Это использование DTE и VSProject для программных ссылок. Я прокомментировал код для большинства объяснений. Но чтобы добавить, я бросил тонну разных дополнительных ссылок, потому что я немного ленив. Но просто соберите с Visual Studio, и с вами все будет в порядке. Если по какой-либо причине это не скомпилируется, не стесняйтесь кричать на меня.

 

using System; 
using System.Collections.Generic; 
using System.ComponentModel; 
using System.Linq; 
using System.Runtime.InteropServices; 
using System.Text; 
using System.Windows.Forms; 
using EnvDTE; 
using EnvDTE80; 
using EnvDTE90; 
using EnvDTE90a; 
using Extensibility; 
using Microsoft.VisualStudio.Shell; 
using Microsoft.VisualStudio.Shell.Design; 
using Microsoft.VisualStudio.Shell.Interop; 
using VSLangProj; 

namespace ConsoleApplication2 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      //Disclaimer: 
      //I am doing this through an extention, Getting 
      //a ref to DTE may not work quite the same for you as 
      //there are several different ways to do it. But the 
      //VSProject stuff shouldn't be an issue 

      //Get your DTE Reference, I'm using DTE2 from EnvDTE80 
      //I hadn't dug into whats the earilest compatible version 
      //The Package is Microsoft.VisualStudio.Shell.Package 
      DTE2 _appObject = Package.GetGlobalService(typeof(DTE)) as DTE2; 

      //This gets the first project in the solution set and casts it as a VSProject 
      //Note that Web projects use a different type , Something like VSWebProject 
      //or something I forget... 
      var pj = (VSProject)_appObject.Solution.Projects.Item(1).Object; 

      //Your dll path 
      pj.References.Add(@"c:\MyRefs\Pastry.dll"); 
     } 
    } 
} 

Answer 4

Я думаю, что если вы используете библиотеку Microsoft.Build.BuildEngine вы можете управлять проектами программно после загрузки.

http://msdn.microsoft.com/en-us/library/microsoft.build.buildengine.aspx

Answer 5

Я не думаю, что есть простой ответ на ваш первый вопрос. Как правило, я бы рекомендовал избегать этой ситуации. С этим трудно справиться вручную, а код для управления не является тривиальным.

Тем не менее, я столкнулся с ситуацией на своей работе, где я просто не мог решить проблему. В нашем случае мы работали над выпуском SDK, который должен был включать набор типовых проектов. «Разработка» этих проектов использовала как ссылки на проекты, так и ссылки на сторонние библиотеки.

Это подводит нас к # 3, что в принципе, да. Я действительно выпустил open source project with a library, a simple windows utility and a NAnt extension to automatically change project references to dll references. Фактически, он также обрабатывает перенос этих сторонних библиотек в одну и ту же локальную папку и обновляет эти ссылки в файле проекта.

Это решение не является совершенным, и есть много улучшений, которые я хотел бы добавить, но он действительно работает для нашей ситуации. Часть нашего скрипта выпуска, который находится в NAnt, запускает этот процесс, чтобы заменить все ссылки на относительный путь. Тогда мы можем легко объединить всю эту установку. Однажды, может быть, у меня будет время добавить задачу MSBuild вместе с проектом.

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

Answer 6

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

Он может заменить ссылки на ваше решение проектами при их добавлении и наоборот, если их удалить.

https://visualstudiogallery.msdn.microsoft.com/056617a4-da39-4d7b-8ecf-933009d9b721