Comment faire en sorte que les projets .NET Core copient les références NuGet pour générer la sortie?

Question

J'essaie d'écrire un système de plug-in avec .NET Core, et l'une de mes exigences est de pouvoir distribuer la DLL de plug-in avec ses dépendances à l'utilisateur pour l'installation. Cependant, je ne peux pas comprendre comment inclure mes dépendances NuGet en tant qu'artefact de construction et les exporter dans le dossier de construction, sans devoir utiliser dotnet publish tant que piratage. Est-il possible de spécifier cela dans csproj?

Answer 1

Vous pouvez ajouter ceci à un <PropertyGroup> à l'intérieur de votre fichier csproj pour faire respecter la copie NuGet assemblées à la sortie:

<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

Toutefois, notez que la sortie de la construction (bin/Release/netcoreapp*/*) n'est pas censé pour être portable et distribuable, la sortie de l' dotnet publish . Mais dans votre cas, la copie assemblées à la sortie de la construction est probablement très utile pour faire des tests. Mais notez que vous pouvez également utiliser l' DependencyContext api pour résoudre les Dll et leurs emplacements qui font partie de l'application graphe de dépendance au lieu d'énumérer un répertoire local.

Answer 2

Vous pouvez utiliser PostBuildEvent pour automatiser le déploiement du module de construction.

Pour obtenir NuGet assemblées dans le dossier de la version ajouter dans csproj de votre module

<PropertyGroup>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>

Définir ce module fichiers que vous voulez et où à l'aide d'Inclure ou d'Exclure (modifier le chemin d'accès que nécessaire)

<ItemGroup>
    <ModuleFiles
      Include="$(TargetDir)*.dll"
      Exclude="$(TargetDir)System*.dll;$(TargetDir)Microsoft*.dll"
      DestinationPath="$(SolutionDir)src\MyProject\Modules\MyModule\%(Filename)%(Extension)">
    </ModuleFiles>
</ItemGroup>

Réinitialiser votre dossier de création de valeur par défaut et ajouter PostbuildEvent

<Target Name="PublishModule" AfterTargets="PostBuildEvent" Inputs="@(ModuleFiles)" Outputs="@(ModuleFiles->'%(DestinationPath)')">
    <WriteLinesToFile File="$(SolutionDir)src\[YOURAPP]\app_offline.htm" />
    <Copy SourceFiles="@(ModuleFiles)" DestinationFiles="@(ModuleFiles->'%(DestinationPath)')" />
    <Delete Files="$(SolutionDir)src\[YOURAPP]\app_offline.htm" />
</Target>

Je suis, y compris app_offline de recycler application que si elle est déjà en cours d'exécution pour éviter de fichier en cours d'utilisation les erreurs.

Answer 3

J'ai "résolu" (créé contourner) ce de façon plus simple.

En post-construction

dotnet publish "$(ProjectFileName)" --no-build -o pub
xcopy "$(ProjectDir)pub\3rdPartyProvider.*.dll" "$(OutDir)"

pub est le dossier où vous voulez que votre publiés optez pour la mise en scène

REMARQUE: selon la version de l' dotnet.exe vous utilisez, commande --no-build peuvent ne pas être disponibles.

Par exemple, ne sont pas disponibles dans la v2.0.3; et disponibles en v2.1.402. Je sais que VS2017 Update4 avait v2.0.3. Et Update8 a 2.1.x

Mise à jour:

La configuration ci-dessus va travailler dans la base de débogage de l'environnement, mais de le mettre en serveur de build/environnement de production de plus n'est nécessaire. Dans cet exemple particulier que j'ai eu à résoudre, nous construisons Release|x64 et Release|x86 séparément. J'ai donc compté pour deux. Mais à l'appui de la post-construction dotnet publish de commande, j'ai d'abord ajouté RuntimeIdentifier de fichier de projet.

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
  <OutputPath>..\..\lib\</OutputPath>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x86'">
  <OutputPath>..\..\lib\</OutputPath>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

Pourquoi j'en avais besoin et pourquoi vous pouvez sortir sans elle? J'avais besoin de ce parce que mon build programme est configuré pour intercepter avertissement MSB3270, et échouer la compilation si elle apparaît. Cet avertissement, dit, "hey, certains fichiers dans vos dépendances sont de format incorrect". Mais vous rappelez-vous le but de cet exercice? Nous devons tirer les dépendances du paquet Dll. Et dans de nombreux cas, il n'a pas d'importance si cet avertissement est-il à la suite de post-construction ne se soucie pas. Encore une fois, c'est mon programme de construction qui s'en soucie. Donc, j'ai seulement ajouté RuntimeIdentifier 2 configurations-je utiliser lors de la production de construire.

Plein de Post construire

if not exist "$(ProjectDir)obj\$(ConfigurationName)" mkdir "$(ProjectDir)obj\$(ConfigurationName)"
xcopy  "$(ProjectDir)obj\$(PlatformName)\$(ConfigurationName)" "$(ProjectDir)obj\$(ConfigurationName)" /E /R /Y

if $(ConfigurationName) == Release (
    dotnet publish "$(ProjectFileName)" --runtime win-$(PlatformName) --no-build -c $(ConfigurationName) -o pub --no-restore --no-dependencies
) else (
    dotnet publish "$(ProjectFileName)" --no-build -c $(ConfigurationName) -o pub --no-restore --no-dependencies
)

xcopy "$(ProjectDir)pub\my3rdPartyCompany.*.dll" "$(OutDir)" /Y /R

Explication: dotnet publier est à la recherche d' obj\Debug ou obj\Release. Nous ne l'avons pas lors de la compilation, car construire crée obj\x64\Release ou obj\x86\Release. Ligne 1 et 2 à atténuer ce problème. Dans la ligne 3, je dis dotnet.exe d'utilisation spécifiques de configuration et d'exécution cible. Sinon, quand c'est en mode debug, je ne m'inquiète pas à propos d'exécution des trucs et des avertissements. Et dans la dernière ligne je prends simplement mon dll et le copier ensuite dans le dossier de sortie. Le travail est accompli.

Answer 4

En conjonction avec la réponse ci-dessus: cela fonctionne très bien dans la ligne de commande d'événement post-build: dans Visual Studio. Il parcourt une sélection de dll (System * .dll et Microsoft .dll) *, puis ignore la suppression de dll spécifiques. System.Data.SqlClient.dll et System.Runtime.Loader.dll

 for %%f in ($(OutDir)System*.dll $(OutDir)Microsoft*.dll) do if not %%f == $(OutDir)System.Data.SqlClient.dll if not %%f == $(OutDir)System.Runtime.Loader.dll del %%f