Programmgesteuertes Aktualisieren von Visual Studio-Projektreferenzen

Question

Ich möchte die Verweise in den Projekten in meiner Visual Studio-Lösung programmatisch aktualisieren.

Ich habe etwa 15 Projekte in meiner Lösung, und beim Entwickeln/Debuggen möchte ich, dass die Verweise auf die Projekte innerhalb der Lösung zeigen.

Als Teil meines Freigabeverfahrens muss ich manchmal eine Kopie eines Projekts erstellen und dann die Referenzen aktualisieren, um auf erstellte DLLs in einem bestimmten Ordner zu verweisen.

Ich kann die Struktur der Projektdateien nachvollziehen und weiß, wie Verweise in ihnen funktionieren, und ich überlege, ein Befehlszeilentool zu entwickeln, das die Projektdateien analysiert und Verweise nach Bedarf ändert.

Meine Fragen sind:
1. Hört sich das sinnvoll an?
2. Hat jemand Erfahrung damit und/oder wie wird der Wechsel zwischen Entwicklungs- und Freigabemodus gehandhabt?
3. Hat jemand irgendwelche Bibliotheken, die sich mit Parsing Visual Studio Projektdateien.

KLÄRUNG:

Vielen Dank für die Antworten. Vielleicht sollte ich ein paar Situationen klären, in denen ich dies verwenden möchte.

a) Meine Bewerbung enthält 15 Projekte. Ich versuche, die Lösung so klein wie möglich zu halten für das, woran ich arbeite, also sagen wir, ich habe 5 Projekte in meiner Lösung. Ich muss nun eines der Projekte, die nicht in der Projektmappe enthalten sind, debuggen/entwickeln, also füge ich dieses Projekt hinzu, aber ich muss: - die Referenzen in den ursprünglichen Projekten so einstellen, dass sie auf Projektreferenzen und nicht auf kompilierte DLLs verweisen - die Verweise in dem neu hinzugefügten Projekt so ändern, dass sie auf die entsprechenden Projektverweise verweisen

Ich möchte, dass mein Tool dies automatisch tut, und die einzige Möglichkeit, die ich derzeit kenne, besteht darin, die Projektdateien zu manipulieren

b) Als Teil eines Service Pack-Build-Verfahrens nehme ich eine Kopie eines der Projekte, nehme die erforderlichen Codeänderungen vor und baue mit Visual Studio. Dazu muss ich alle Verweise auf die kompilierten DLLs ändern

Answer 1

Ich denke, ein besserer Ansatz wäre die Verwendung von bedingten Blöcken für Ihre Referenzen direkt in der Projektdatei. Dann alles, was Sie tun müssen, ist ein bestimmtes Flag während der msbuild für die "Release"-Build und es wird die richtigen Referenzen abholen zu setzen.

Zum Beispiel

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

Answer 2

Tiger, Tiger ROAR !!!

Dies geschieht mit Hilfe von DTE und VSProject, um programmatische Referenzen hinzuzufügen. Ich kommentierte den Code für die Mehrheit der Erklärung. Aber um hinzuzufügen, habe ich eine Tonne von verschiedenen zusätzlichen Referenzen werfen, weil ich irgendwie faul bin. Aber nur mit Visual Studio sortieren und Sie sollten in Ordnung sein. Wenn aus irgendeinem Grund dies nicht kompilieren fühlen sich frei, mich anzuschreien.

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 3

Ich glaube nicht, dass es eine einfache Antwort auf Ihre erste Frage gibt. In der Regel würde ich empfehlen, diese Situation zu vermeiden. Es ist schwierig, manuell zu handhaben, und der Code, um es zu verwalten ist nicht trivial.

Allerdings bin ich bei meiner Arbeit in eine Situation geraten, in der ich das Problem einfach nicht umgehen konnte. In unserem Fall arbeiteten wir an der Veröffentlichung eines SDK, das eine Reihe von Beispielprojekten enthalten sollte. Die "Entwicklungs"-Version dieser Projekte verwendete sowohl Projektverweise als auch Verweise auf Bibliotheken von Drittanbietern.

Das bringt uns zu Nummer 3, die im Grunde genommen ja lautet. Ich habe tatsächlich eine Open-Source-Projekt mit einer Bibliothek, einem einfachen Windows-Dienstprogramm und einer NAnt-Erweiterung, um Projektreferenzen automatisch in DLL-Referenzen zu ändern . Es übernimmt auch das Verschieben dieser Bibliotheken von Drittanbietern in denselben lokalen Ordner und aktualisiert die Referenzen in der Projektdatei.

Diese Lösung ist nicht perfekt, und es gibt eine Menge Verbesserungen, die ich gerne noch hinzufügen würde, aber für unsere Situation funktioniert sie. Ein Teil unseres Freigabeskripts, das ganz in NAnt ist, führt diesen Prozess aus, um alle Verweise auf einen relativen Pfad auszutauschen. Dann können wir diese ganze Einrichtung einfach bündeln. Eines Tages werde ich vielleicht die Zeit finden, einen MSBuild Task zusammen mit dem Projekt hinzuzufügen.

Nochmals, ich denke, es ist am besten, dies so weit wie möglich zu vermeiden, aber wenn Sie wie ich nicht weiterkommen - der von mir veröffentlichte Code sollte zumindest helfen.

Answer 4

Das klingt nach einer seltsamen Situation.

Mein Vorschlag lautet wie folgt.

1. Trennen Sie die Projekte, die über vorgefertigte Versionen verfügen, in eine separate Lösung. Lassen Sie sie alle bauen nach

   \assemblies\fromsource

2. Kopieren Sie die vorgefertigten Dateien in;

   \assembly\prebuilt

3. Bevor Sie den Rest der Projekte entwickeln, kopieren Sie eines der beiden Verzeichnisse nach

   \assembly\development

4. Ändern Sie Ihre Projekte so, dass sie auf die Versionen in \assembly\development.

Sie bauen Ihr Produkt also immer gegen vorkompilierte Binärdateien in einem bekannten Ordner, so dass Sie Ihr Projekt nie ändern müssen. Aber Sie können nach Belieben zwischen den Versionen hin- und herwechseln.

Für Bonuspunkte, ändern Sie ein Prebuild-Ereignis, um die Dlls zu kopieren, bevor die Erstellung beginnt, und lassen Sie den Quellordner je nach Konfiguration variieren. Fügen Sie dann eine PREBUILT-Konfiguration neben DEBUG und RELEASE hinzu.

Answer 5

Ich denke, wenn Sie die Microsoft.Build.BuildEngine-Bibliothek verwenden, können Sie die Projekte nach dem Laden programmatisch bearbeiten.

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