Ich habe eine Lösung mit mehreren Projekten. Ich versuche, AssemblyInfo.cs-Dateien zu optimieren, indem ich eine lösungsweite Assembly-Info-Datei verknüpfe. Was sind die Best Practices dafür? Welche Attribute sollten in der lösungsweiten Datei enthalten sein und welche sind projekt- / montagespezifisch?
Bearbeiten: Wenn Sie interessiert sind, gibt es eine Folgefrage Was sind die Unterschiede zwischen AssemblyVersion, AssemblyFileVersion und AssemblyInformationalVersion?
Antworten:
Wir verwenden eine globale Datei namens GlobalAssemblyInfo.cs und eine lokale Datei namens AssemblyInfo.cs. Die globale Datei enthält die folgenden Attribute:
[assembly: AssemblyProduct("Your Product Name")]
[assembly: AssemblyCompany("Your Company")]
[assembly: AssemblyCopyright("Copyright © 2008 ...")]
[assembly: AssemblyTrademark("Your Trademark - if applicable")]
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
[assembly: AssemblyVersion("This is set by build process")]
[assembly: AssemblyFileVersion("This is set by build process")]Die lokale AssemblyInfo.cs enthält die folgenden Attribute:
[assembly: AssemblyTitle("Your assembly title")]
[assembly: AssemblyDescription("Your assembly description")]
[assembly: AssemblyCulture("The culture - if not neutral")]
[assembly: ComVisible(true/false)]
// unique id per assembly
[assembly: Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")]Sie können die GlobalAssemblyInfo.cs wie folgt hinzufügen:
AssemblyCultureAttributeverdient eine bessere Erklärung. Das Attribut sollte am besten vollständig fehlen (es sei denn, es handelt sich um eine Satellitenbaugruppe). Wenn Sie Satellitenbaugruppen in großem Maßstab verwenden, sind möglicherweise drei und nicht zwei Ebenen von Baugruppeninformationsdateien erforderlich (globale Baugruppe, Hauptbaugruppe und Satellitenbaugruppe, die in diesem Fall nur die Kultur angeben).
In meinem Fall erstellen wir ein Produkt, für das wir eine Visual Studio-Lösung mit verschiedenen Komponenten in ihren eigenen Projekten haben. Die gemeinsamen Attribute gehen. Die Lösung enthält ungefähr 35 Projekte und eine allgemeine Assembly-Information (CommonAssemblyInfo.cs) mit den folgenden Attributen:
[assembly: AssemblyCompany("Company")]
[assembly: AssemblyProduct("Product Name")]
[assembly: AssemblyCopyright("Copyright © 2007 Company")]
[assembly: AssemblyTrademark("Company")]
//This shows up as Product Version in Windows Explorer
//We make this the same for all files in a particular product version. And increment it globally for all projects.
//We then use this as the Product Version in installers as well (for example built using Wix).
[assembly: AssemblyInformationalVersion("0.9.2.0")]Die anderen Attribute wie AssemblyTitle, AssemblyVersion usw. werden pro Baugruppe bereitgestellt. Beim Erstellen einer Assembly werden sowohl AssemblyInfo.cs als auch CommonAssemblyInfo.cs in jede Assembly integriert. Dies gibt uns das Beste aus beiden Welten, in denen Sie möglicherweise einige gemeinsame Attribute für alle Projekte und spezifische Werte für einige andere haben möchten.
Hoffentlich hilft das.
<Compile Include="$(MSBuildThisFileDirectory)..\Common\CommonAssemblyInfo.cs"/>, einer MSBuild-Direktive, die sich möglicherweise sogar in einer gemeinsam genutzten Common.targetsDatei befindet. Yay Code Wiederverwendung.
Die von @JRoppert vorgestellte Lösung ist fast die gleiche wie meine. Der einzige Unterschied besteht darin, dass ich die folgenden Zeilen in die lokale AssemblyInfo.cs-Datei eingefügt habe, da sie mit jeder Assembly variieren können:
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
[assembly: AssemblyVersion("This is set by build process")]
[assembly: AssemblyFileVersion("This is set by build process")]
[assembly: CLSCompliant(true)]Ich verwende auch (im Allgemeinen) eine allgemeine Baugruppeninformation pro Lösung, mit der Annahme, dass eine Lösung eine einzelne Produktlinie / ein freisetzbares Produkt ist. Die allgemeine Assembly-Info-Datei enthält außerdem:
[assembly: AssemblyInformationalVersion("0.9.2.0")]Dadurch wird der vom Windows Explorer angezeigte Wert für "ProductVersion" festgelegt.
MSBuild Community Tasks enthält eine benutzerdefinierte Aufgabe namens AssemblyInfo, mit der Sie Ihre Assemblyinfo.cs generieren können. Die Verwendung Ihrer csproj-Dateien erfordert eine kleine manuelle Bearbeitung, lohnt sich jedoch.
Meiner Meinung nach ist die Verwendung einer GlobalAssemblyInfo.cs mehr Mühe als es wert ist, da Sie jede Projektdatei ändern und daran denken müssen, jedes neue Projekt zu ändern, während Sie standardmäßig eine AssemblyInfo.cs erhalten.
Bei Änderungen an globalen Werten (z. B. Unternehmen, Produkt usw.) sind die Änderungen normalerweise so selten und einfach zu verwalten, dass ich nicht denke, dass DRY eine Überlegung sein sollte. Führen Sie einfach das folgende MSBuild-Skript aus (abhängig vom MSBuild Extension Pack ), wenn Sie die Werte in allen Projekten einmalig manuell ändern möchten:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="UpdateAssemblyInfo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<AllAssemblyInfoFiles Include="..\**\AssemblyInfo.cs" />
</ItemGroup>
<Import Project="MSBuild.ExtensionPack.tasks" />
<Target Name="UpdateAssemblyInfo">
<Message Text="%(AllAssemblyInfoFiles.FullPath)" />
<MSBuild.ExtensionPack.Framework.AssemblyInfo
AssemblyInfoFiles="@(AllAssemblyInfoFiles)"
AssemblyCompany="Company"
AssemblyProduct="Product"
AssemblyCopyright="Copyright"
... etc ...
/>
</Target>
</Project>Um eine Datei für mehrere Projekte freizugeben, können Sie eine vorhandene Datei als Link hinzufügen.
Fügen Sie dazu eine vorhandene Datei hinzu und klicken Sie in der Dateiauswahl auf "Als Link hinzufügen". (Quelle: free.fr )
Was in die freigegebene Datei eingefügt werden soll, würde ich vorschlagen, Dinge zu platzieren, die für mehrere Assemblys freigegeben werden. Dinge wie Urheberrecht, Firma, vielleicht Version.
Die Verwendung einer einzelnen AseemblyInfo.cs-Datei für mehrere Projekte wird nicht empfohlen. Die AssemblyInfo-Datei enthält Informationen, die möglicherweise nur für diese bestimmte Assembly relevant sind. Die zwei offensichtlichsten Informationen sind das AssemblyTitleund AssemblyVersion.
Eine bessere Lösung könnte darin bestehen, targetsDateien zu verwenden , die von MSBuild verarbeitet werden, um Assembly-Attribute in mehr als ein Projekt zu "injizieren".
Eine Sache, die ich als nützlich empfunden habe, ist das Generieren der AssemblyVersion-Elemente (usw.) durch Anwenden der Tokensubstitution in der Vorbereitungsphase.
Ich benutze TortoiseSvn und es ist einfach, daraus SubWCRev.exeeine Vorlage AssemblyInfo.wcrevzu machen AssemblyInfo.cs. Die relevante Zeile in der Vorlage könnte ungefähr so aussehen:
[assembly: AssemblyVersion("2.3.$WCREV$.$WCMODS?1:0$$WCUNVER?1:0$")]Das dritte Element ist dann die Revisionsnummer. Ich verwende das vierte Element, um zu überprüfen, ob ich vergessen habe, neue oder geänderte Dateien festzuschreiben (das vierte Element ist 00, wenn alles in Ordnung ist).
Fügen Sie übrigens AssemblyInfo.wcrevIhre Versionskontrolle hinzu und ignorieren AssemblyInfo.cs Sie sie , wenn Sie diese verwenden.