Seit der Rückkehr des Dotnet-Core in das .csproj
-Format gibt es einen neuen automatisch generierten MyProject.AssemblyInfo.cs
, der unter anderem enthält.
[Assembly: AssemblyCompany("MyProject")]
[Assembly: AssemblyVersion("1.0.0.0")]
Beachten Sie, dass dies automatisch bei jedem Build neu erstellt wird . Früher wurde die Datei im Verzeichnis/obj/gefunden. Jetzt scheint sie nur im Arbeitsspeicher zu sein, da die Datei nicht auf der Festplatte gefunden werden kann und auf den Fehler geklickt wird Nachricht öffnet keine Datei.
Da sie dort definiert sind, kann ich sie im klassischen AssemblyInfo.cs
nicht selbst definieren.
Wo/wie kann ich das Unternehmen und die Version eines Projekts definieren?
Wie Sie bereits bemerkt haben, können Sie die meisten dieser Einstellungen in .csproj steuern.
Wenn Sie diese in AssemblyInfo.cs lieber beibehalten möchten, können Sie automatisch generierte Assembly-Attribute deaktivieren.
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
Wenn Sie sehen möchten, was unter der Haube passiert, checken Sie Microsoft.NET.GenerateAssemblyInfo.targets in Microsoft.NET.Sdk aus.
Diese Einstellungen wurden in die .csproj-Datei verschoben.
Standardmäßig werden sie nicht angezeigt. Sie können sie jedoch in Visual Studio 2017 auf der Registerkarte Package
der Projekteigenschaften ermitteln.
Nach dem Speichern finden Sie diese Werte in MyProject.csproj
.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
<Version>1.2.3.4</Version>
<Authors>Author 1</Authors>
<Company>Company XYZ</Company>
<Product>Product 2</Product>
<PackageId>MyApp</PackageId>
<AssemblyVersion>2.0.0.0</AssemblyVersion>
<FileVersion>3.0.0.0</FileVersion>
<NeutralLanguage>en</NeutralLanguage>
<Description>Description here</Description>
<Copyright>Copyright</Copyright>
<PackageLicenseUrl>License URL</PackageLicenseUrl>
<PackageProjectUrl>Project URL</PackageProjectUrl>
<PackageIconUrl>Icon URL</PackageIconUrl>
<RepositoryUrl>Repo URL</RepositoryUrl>
<RepositoryType>Repo type</RepositoryType>
<PackageTags>Tags</PackageTags>
<PackageReleaseNotes>Release</PackageReleaseNotes>
</PropertyGroup>
In der Registerkarte mit den Eigenschaften des Datei-Explorers wird FileVersion
als "Dateiversion" und Version
als "Produktversion" angezeigt.
Ich mache Folgendes für meine .NET Standard 2.0-Projekte.
Erstellen Sie eine Directory.Build.props
-Datei (z. B. im Stammverzeichnis Ihres Repos) Und verschieben Sie die gemeinsam genutzten Eigenschaften aus der .csproj
-Datei in diese Datei.
MSBuild wird es automatisch abholen und auf den automatisch generierten AssemblyInfo.cs
anwenden.
Sie werden auch auf das Nuget-Paket angewendet, wenn Sie eines mit dotnet pack
oder über die Benutzeroberfläche in Visual Studio 2017 erstellen.
Siehe https://docs.Microsoft.com/de-de/visualstudio/msbuild/customize-your-build
Sie können jederzeit Ihre eigenen AssemblyInfo.cs hinzufügen, was InternalsVisibleToAttribute
, CLSCompliantAttribute
und anderen, die nicht automatisch generiert werden, von Nutzen ist.
<project name> > Add > New Folder
. Add > New Item...
.Wenn Sie Ihre Attribute zurück in AssemblyInfo.cs verschieben möchten, anstatt sie automatisch generieren zu lassen, können Sie sie in MSBuild unterdrücken, wie natemcmaster in seiner Antwort zeigt.
Ich möchte dieses Thema/Antworten mit den folgenden erweitern. Wie bereits erwähnt, kann diese automatisch generierte AssemblyInfo ein Hindernis für die externen Tools sein. In meinem Fall hatte ich mit FinalBuilder ein Problem, dass AssemblyInfo nicht durch die Build-Aktion aktualisiert wurde. Anscheinend ist FinalBuilder auf ~proj
-Datei angewiesen, um den Speicherort von AssemblyInfo zu finden. Ich dachte, es war irgendwo unter Projektordner zu suchen. Nein, also das ändern
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
hatte nur den Job, erlaubte benutzerdefinierte Assembly-Informationen, wenn sie von VS IDE/MS Build erstellt wurden. Aber ich brauchte FinalBuilder auch ohne manuelle Manipulationen an der Assembly-Infodatei. Ich musste alle Programme, MSBuild/VS und FinalBuilder, zufrieden stellen.
Ich habe das Problem gelöst, indem ich einen Eintrag zur vorhandenen ItemGroup
hinzugefügt habe.
<ItemGroup>
<Compile Remove="Common\**" />
<Content Remove="Common\**" />
<EmbeddedResource Remove="Common\**" />
<None Remove="Common\**" />
<!-- new added item -->
<None Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
Mit diesem Element findet FinalBuilder nun die Position von AssemblyInfo und ändert die Datei. Die Aktion None
lässt zu, dass MSBuild/DevEnv diesen Eintrag ignoriert und meldet nicht länger einen Fehler basierend auf der Compile
-Aktion, die normalerweise mit dem Assembly Info-Eintrag in proj
-Dateien geliefert wird.
C:\Programme\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.DefaultItems.targets (263,5): Fehler: Es wurden doppelte 'Compile'-Elemente eingefügt. Das .NET SDK enthält standardmäßig "Compile" -Elemente aus Ihrem Projektverzeichnis. Sie können diese Elemente entweder aus Ihrer Projektdatei entfernen oder die Eigenschaft 'EnableDefaultCompileItems' auf 'false' setzen, wenn Sie sie explizit in Ihre Projektdatei einschließen möchten. Weitere Informationen finden Sie unter https://aka.ms/sdkimplicititems . Die doppelten Elemente waren: 'AssemblyInfo.cs'