Out-of-Place-Builds mit C#

Question

Ich habe gerade ein Out-of-Place-Build-System für unseren vorhandenen C++ - Code eingerichtet, der vererbte Eigenschaftenblätter verwendet, eine Funktion, die spezifisch für das Visual C++ - Produkt zu sein scheint. Das Erstellen von Out-of-Place erfordert, dass viele der Projekteinstellungen geändert werden, und die vererbten Eigenschaftsfenster haben es mir ermöglicht, alle erforderlichen Einstellungen zu ändern, indem Sie einfach ein Eigenschaftsfenster an das Projekt anfügen. Ich migiere unser Team von C++/MFC für UI nach C# und WPF, aber ich muss die gleiche Build-Funktionalität bereitstellen, hoffentlich mit dem gleichen Komfort. Ich kann anscheinend keine Möglichkeit finden, dies mit C# -Projekten zu tun. Ich habe zuerst nach einer MsBuild-Zieldatei gesucht, konnte aber keinen Weg finden, dies zu tun. Ich weiß, ich könnte MsBuild einfach für das Ganze benutzen, aber das scheint komplizierter als nötig. Gibt es eine Möglichkeit, ein Makro für ein Verzeichnis zu definieren und es beispielsweise im Ausgabepfad zu verwenden?

Answer 1

Ich bin nicht ganz sicher, was ein "Out-of-Place" Build-System ist, aber wenn Sie nur die kompilierten Dateien (oder andere Ressourcen) in andere Verzeichnisse kopieren möchten, können Sie dies tun, indem Sie binden Die MSBuild Build-Ziele.

In unseren Projekten verschieben wir die kompilierten DLLs in lib-Ordner und speichern die Dateien an den richtigen Stellen, nachdem ein Build abgeschlossen ist. Dazu haben wir eine benutzerdefinierte Build-Zieldatei erstellt, die die Target, Property und ItemGroup erstellt, die wir dann verwenden, um unseren externen Ausgabeordner zu füllen.

sieht unsere individuelle Ziele Datei ein bisschen wie folgt aus:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup> 
     <ProjectName>TheProject</ProjectName> 
     <ProjectDepthPath>..\..\</ProjectDepthPath> 
     <ProjectsLibFolder>..\..\lib\</ProjectsLibFolder> 

     <LibFolder>$(ProjectsLibFolder)$(ProjectName)\$(Configuration)\</LibFolder> 
    </PropertyGroup> 

    <Target Name="DeleteLibFiles"> 
     <Delete Files="@(LibFiles-> '$(ProjectDepthPath)$(LibFolder)%(filename)%(extension)')" TreatErrorsAsWarnings="true" /> 
    </Target> 
    <Target Name="CopyLibFiles"> 
     <Copy SourceFiles="@(LibFiles)" DestinationFolder="$(ProjectDepthPath)$(LibFolder)" SkipUnchangedFiles="True" /> 
    </Target> 

    <ItemGroup> 
     <LibFiles Include=" "> 
      <Visible>false</Visible> 
     </LibFiles> 
    </ItemGroup> 
</Project> 

Die CSPROJ Datei in Visual Studio dann mit diesem kundenspezifischen Zieldatei integriert:

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="3.5" ... > 
    ... 
    <Import Project="..\..\..\..\build\OurBuildTargets.targets" /> 
     <ItemGroup> 
     <LibFiles Include="$(OutputPath)$(AssemblyName).dll"> 
      <Visible>false</Visible> 
     </LibFiles> 
     </ItemGroup> 
    <Target Name="BeforeClean" DependsOnTargets="DeleteLibFiles" /> 
    <Target Name="AfterBuild" DependsOnTargets="CopyLibFiles" /> 
</Project> 

Auf den Punkt gebracht, das Build-Skript teilt MSBuild mit, dass es unser benutzerdefiniertes Buildskript laden soll, fügt dann die kompilierte Datei der LibFiles ItemGroup hinzu und bindet schließlich unsere benutzerdefinierten Build-Ziele DeleteLibFiles und CopyLibFiles in den Build-Prozess ein. Wir stellen dies für jedes Projekt in unserer Lösung so ein, dass nur die Dateien, die aktualisiert werden, gelöscht/kopiert werden und jedes Projekt für seine eigenen Dateien (dlls, Bilder usw.) verantwortlich ist.

Ich hoffe, das hilft. Ich entschuldige mich, wenn ich missverstanden habe, was du mit dem Out-of-Place-Build-System meinst, und das ist völlig nutzlos für dich!

Answer 2

Gibt es eine Möglichkeit ich ein Makro für ein Verzeichnis definieren und verwenden es in den Ausgabepfad

Haben Sie bei der Pre-Build-und Post-Build-Ereignisse eines Projekts ausgesehen hat?

Answer 3

Tatsächlich scheinen Pre-Build- und Post-Build-Ereignisse nur ein Ort zu sein, an dem Befehle vom Typ Batch-File hinzugefügt werden. Dies würde mir leider nicht helfen, Standard-Build-Verzeichnisse für unsere Projekte zu erstellen. Und diese Ereignisse zu erstellen Batch-Dateien scheint wie eine sehr 1980 Ansatz für eine moderne Sprache wie C#, IMO.

Nach dem Graben noch mehr und experimentieren, habe ich festgestellt, dass Sie eine <Import> Direktive in Ihre .csproj-Datei hinzufügen können. Wenn Sie dies tun, öffnet die IDE einen Warndialog, dass ein unsicherer Einstiegspunkt in Ihrem Projekt vorhanden ist - aber Sie können dies ignorieren und Sie können es überhaupt nicht erscheinen lassen, indem Sie einen Registrierungseintrag bearbeiten. Das würde mir eine Möglichkeit geben, die Variablen mit den benötigten Verzeichnispfaden in die .csproj-Datei zu bekommen.

Jetzt, um den Ausgabepath zu erhalten, um darauf zu verweisen - leider, wenn Sie eine Zeichenfolge wie "$ (MySpecialPath)/Debug" zum Ausgabepfadfeld hinzufügen und das Projekt speichern, werden die $ und() Zeichen konvertiert hex, und Ihre Datei wird in ein Debug-Verzeichnis unter dem Verzeichnis "$ (MySpecialPath)" gestellt. Arrgghh. Wenn Sie die .csproj-Datei in einem Texteditor bearbeiten, können Sie dies jedoch korrekt festlegen, und es scheint zu funktionieren, solange das <Import>-Tag vor der <PropertyGroup> angezeigt wird, die den Ausgabepfad enthält.

Also ich denke, die Lösung für mich wird eine Standard OurTeam.targets MsBuild-Datei an einem Standard-Speicherort erstellen, fügen Sie ein Installationsprogramm zum Ändern der Registrierung, so dass Warnungen nicht markiert, und erstellen Sie benutzerdefinierte Projektvorlagen, die < Importieren Sie > diese Datei, und legen Sie den Ausgabepfad fest, um die in der OurTeam.targets-Datei definierten Eigenschaften zu verwenden. Leider ist dies mehr Arbeit und eine weniger elegante Lösung als der Eigenschaftsblatt-Vererbungsmechanismus in C++.