que - microsoft archivos dll

¿Dónde colocar dlls para bibliotecas no administradas?

Question

Estoy intentando crear un paquete Nuget para una biblioteca que depende de ghostscript y, por lo tanto, hace referencia a gsdll32.dll, una biblioteca no administrada. No puedo simplemente incluir una referencia dll estándar. ¿Dónde pongo esto en la estructura del directorio nuget?

Answer 1

En gran parte conseguí que esto funcionara usando el método de Lars Michael, pero una cosa que necesitaba agregar proviene de la respuesta de James Eby. Visual Studio intentaba registrar todos los archivos DLL en mi directorio lib , así que agregué un elemento de references a los metadatos en el archivo nuspec para indicarle que solo registre el archivo DLL administrado:

<references>
    <reference file="FANNCSharp.dll" />          
</references>

También en

<MyPackageFiles Include="$(MSBuildProjectDirectory)/../Packages/MyPackage/lib/*.*"/>

Primero probé la identificación de mi paquete FANNCSharp-x64 , pero necesitaba el nombre completo del paquete: FANNCSharp-x64.0.1.4 .

Answer 2

La referencia anterior puede funcionar, pero en realidad modifica su evento posterior a la compilación para transferir los archivos, lo que puede no solucionar su problema si tiene la situación que tuvimos.

El problema que teníamos era que una DLL dependiente no se podía registrar, pero tenía que existir una junto a otra DLL que necesitaba ser registrada por nuget, así que tenía que existir en el directorio lib pero no estar registrada.

La referencia de nuspec ahora le permite especificar qué DLL en el directorio lib se registran explícitamente en el proyecto de Visual Studio ahora, simplemente necesita agregar a su archivo nuspec en el área de metadatos una lista de referencias explícitas (si no existe el comportamiento predeterminado). de nuget es intentar registrar todo bajo lib).

Aquí hay un ejemplo de archivo nuspec de lo que quiero decir:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
        <id>SomePackageID</id>
        <version>1.0.1</version>
        <title>Some Package Title</title>
        <authors>Some Authors</authors>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>Blah blah blah.</description>
        <references>
            <reference file="ceTe.DynamicPDF.Rasterizer.20.x86.dll" />          
        </references>
    </metadata>
    <files>
        <file src="//SomeNetworkLocation/ceTe.DynamicPDF.Rasterizer.20.x86.dll" target="lib/ceTe.DynamicPDF.Rasterizer.20.x86.dll" />
        <file src="//SomeNetworkLocation/DPDFRast.x86.dll" target="lib/DPDFRast.x86.dll" />
    </files>
</package>

Como puede ver, ceTe.DynamicPDF.Rasterizer.20.x86.dll debe registrarse, pero DPDFRast.x86.dll simplemente debe existir en ese directorio para admitir la otra DLL y no se registrará, sino mediante algunas referencias dinámicas. La magia finalmente se copiará en el directorio de destino bin de todos modos porque Visual Studio ve que la primera DLL depende de la segunda.

Aquí está la referencia nuspec original.

Answer 3

Respuesta en el foro de Nuget: http://nuget.codeplex.com/discussions/352689

pranavkm: el paquete SQLCE tiene un problema similar que manejamos a través de scripts PS. Verifique los scripts en https://bitbucket.org/davidebbo/nugetpackages/src/1cba18b864f7/SqlServerCompact/Tools .

Answer 4

Un problema que tuve fue que la ruta de los paquetes no siempre estaba en el mismo lugar en relación con el archivo del proyecto. Lo siguiente me funcionó:

1. Dentro del paquete NuGet, coloque sus DLL no administradas en la carpeta lib / native.

2. Agregue el siguiente script a la carpeta de herramientas:

instalar.ps1

#This script creates or updates a PackagesPath property in the project file
param($installPath, $toolsPath, $package, $project)

$project.Save()

#Load the csproj file into an xml object
[xml] $xml = Get-Content -path $project.FullName

#grab the namespace from the project element 
$nsmgr = New-Object System.Xml.XmlNamespaceManager -ArgumentList $xml.NameTable
$nsmgr.AddNamespace(''a'',$xml.Project.GetAttribute("xmlns"))

#find or create the property
$property = $xml.Project.SelectSingleNode("//a:PropertyGroup//a:PackagesPath", $nsmgr)
if (!$property)
{
    $property = $xml.CreateElement("PackagesPath", $xml.Project.GetAttribute("xmlns"))
    $propertyGroup = $xml.CreateElement("PropertyGroup", $xml.Project.GetAttribute("xmlns"))
    $propertyGroup.AppendChild($property)
    $xml.Project.InsertBefore($propertyGroup, $xml.Project.ItemGroup[0])
}

#find the relative path to the packages folder
$absolutePackagesPath = (get-item $installPath).parent.FullName
push-location (split-path $project.FullName)
$relativePackagesPath = Resolve-Path -Relative $absolutePackagesPath
pop-location

#set the property value
$property.InnerText = $relativePackagesPath

#save the changes.
$xml.Save($project.FullName)

3. Agrega un archivo de objetivos a la carpeta de compilación. (Cambie "MyPackage" al nombre de su paquete). El uso de un nombre único para el destino, como "CopyMyPackage", evita conflictos con otros paquetes que intentan definir el objetivo "AfterBuild". Este archivo de objetivos hace uso de la propiedad $ (PackagesPath) definida por el script anterior.

MyPackage.targets

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
  <Target Name="CopyMyPackage" AfterTargets="AfterBuild"> 
    <ItemGroup> 
      <MyPackageSourceFiles Include="$(PackagesPath)/MyPackage.*/lib/native/*.*"/> 
    </ItemGroup> 
    <Copy SourceFiles="@(MyPackageSourceFiles)" DestinationFolder="$(OutputPath)" > 
    </Copy> 
  </Target> 
</Project>

4. Finalmente, agregue un "MyPackageReadMe.txt" a la carpeta de Contenido. Esto permitirá que el paquete se instale.

Véase también: http://alski.net/post/2013/05/23/Using-NuGet-25-to-deliver-unmanaged-dlls.aspx

Answer 5

Agregue una carpeta de build al paquete y, si el paquete, por ejemplo, tiene el id MyPackage , agregue un archivo de destino de MSBuild llamado MyPackage.targets a esta carpeta. Es importante que el archivo .targets tenga el mismo nombre que el archivo .nuspec . En el archivo .nuspec debe tener una sección como esta:

<files>
    <file src="lib/*.*" target="lib" />
    <file src="build/MyPackage.targets" target="build" />
</files>

Esto agregará un elemento de MSBuild en el archivo de proyecto que apunta al archivo .targets .

Además, para registrar solo las dll administradas, agregue una sección como esta:

<references>
    <reference file="MyManaged.dll" />
</references>

El archivo .targets debería verse así:

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
  <Target Name="CopyMyPackageFiles" AfterTargets="AfterBuild"> 
    <ItemGroup> 
      <MyPackageFiles Include="$(MSBuildThisFileDirectory)../lib/*.*"/> 
    </ItemGroup> 
    <Copy SourceFiles="@(MyPackageFiles)" DestinationFolder="$(OutputPath)" > 
    </Copy> 
  </Target> 
</Project>

Ahora, todos los archivos, incluidos los archivos no administrados, se copiarán en la carpeta de salida del proyecto (por ejemplo, / bin / debug) después de la compilación.