Где разместить dll для неуправляемых библиотек?

Я пытаюсь создать пакет Nuget для библиотеки, которая зависит от ghostscript и поэтому ссылается на gsdll32.dll - неуправляемую библиотеку. Я не могу просто включить эту стандартную ссылку dll. Где я могу поместить это в структуру каталогов nuget?

Ответы на вопрос(5)

Добавитьbuild папка к пакету и, если пакет, например, имеет идентификаторMyPackage, добавьте целевой файл MSBuild с именемMyPackage.targets в эту папку. Важно, чтобы.targets файл имеет то же имя, что и.nuspec файл. в.nuspec файл, который вы должны иметь раздел, как это:

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

Это добавит элемент MSBuild в файл проекта, указывающий на.targets файл.

Кроме того, чтобы зарегистрировать только управляемые библиотеки, добавьте раздел, подобный следующему:

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

.targets файл должен выглядеть примерно так:

<?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>

Сейчас,all файлы - включая неуправляемые файлы - будут скопированы в выходную папку проекта (например, \ bin \ debug) после сборки.

 10 мар. 2016 г., 23:19
Вы сделали мой день (период).
 George Mauer09 окт. 2015 г., 19:09
Я ценю это, Ларс. Можете ли вы отредактировать это в своем ответе? Ссылки на блоги, как правило, перестают работать.
 22 февр. 2017 г., 00:46
@ J & # xE9; r & # xF4; мне это немного поздно, но я думаю, что на ваш вопрос все же стоит ответить. Существует небольшая (и определенно не очевидная) ловушка для файла .target: имя должно совпадать с именем пакета. Когда это так, цель автоматически добавляется в файл .csproj при установке пакета. Вы можете проверить свои на & lt; Импорт & gt; ссылка на вашу цель в пакетах где-то ближе к концу. Только тогда это будет работать. Никакой другой магии.
 26 нояб. 2018 г., 11:09
@ElliotWoods В файле .nuspec (docs.microsoft.com/en-us/nuget/reference/nuspec). Файлы .targets должны быть настроены в соответствии с тем, куда вы положили свои собственные файлы. В этом примере они помещены в папку с именемlib
 18 июл. 2017 г., 15:34
Вы можете избежать жесткого кодирования точного пути следующим образом:<MyPackageFiles Include="$(MSBuildThisFileDirectory)..\myfile.dll

Ответ на форуме Nuget:http://nuget.codeplex.com/discussions/352689

pranavkm: The SQLCE package has a similar issue that we handle via PS scripts. Checkout out the scripts at https://bitbucket.org/davidebbo/nugetpackages/src/1cba18b864f7/SqlServerCompact/Tools.

Я в основном заставил это работать, используя метод Ларса Майкла, но одну вещь, которую мне нужно было добавить, это ответ Джеймса Эби. Visual Studio пыталась зарегистрировать все DLL в моемlib каталог, поэтому я добавилreferences элемент к метаданным в файле nuspec, чтобы сказать ему только регистрировать управляемую dll:

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

Также в

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

Я сначала попробовал идентификатор моей посылкиFANNCSharp-x64, но для этого нужно было полное имя пакета:FANNCSharp-x64.0.1.4.

 03 авг. 2017 г., 17:25
Я изменил исходный ответ, чтобы учесть то, что вы упоминаете. Благодарю.

Приведенная выше ссылка может работать, но на самом деле она изменяет ваше событие после сборки, чтобы пересылать файлы, что может на самом деле не решить вашу проблему, если у вас возникла ситуация, которую мы сделали.

Проблема, которую мы имели, была зависимой DLL, не могла быть зарегистрирована, но должна была существовать рядом с другой DLL, которая должна была быть зарегистрирована nugetso it needed to exist in the lib directory but not be registered.

Ссылка nuspec теперь позволяет вам указать, какие DLL вlib каталог явно зарегистрирован в проекте Visual Studio, вам просто нужно добавить в файл nuspec вmetadata область явнаяreferences list (если он не существует, по умолчанию nuget пытается зарегистрировать все под lib).

Вот пример файла nuspec того, что я имею в виду:

<?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>

Как вы видете,ceTe.DynamicPDF.Rasterizer.20.x86.dll нужно зарегистрироваться, ноDPDFRast.x86.dll просто должен существовать в этом каталоге для поддержки другой DLL и не будет зарегистрирован, но с помощью некоторой магии динамической ссылки в конечном итоге будет скопирована в место назначенияbin каталог в любом случае, потому что Visual Studio видит, что первая DLL зависит от второй.

Вот оригиналссылка nuspec.

 09 окт. 2015 г., 15:00
"...through some dynamic referencing magic will ultimately be copied over into the destination bin directory anyway...", Кажется, это не работает дляunamanged это вопрос, о котором идет речь.
 12 окт. 2015 г., 22:40
DPDFRast.x86.dll - это неуправляемая DLL.
 12 окт. 2015 г., 23:28
Ну, это не сработало в моем случае, ноstackoverflow.com/a/33041626/798781 сделал.

Одна проблема, с которой я столкнулся, заключалась в том, что путь к пакетам не всегда был в одном и том же месте относительно файла проекта. У меня сработало следующее:

Within the NuGet package, place your unmanaged DLLs in the lib\native folder.

Add the following script to the tools folder:

install.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)
Add a targets file to the build folder. (Change "MyPackage" to the name of your package). Using a unique name for the target, like "CopyMyPackage", avoids conflicts with other packages trying to define the "AfterBuild" target. This targets file makes use of the $(PackagesPath) property defined by the above script.

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>
Finally, add a "MyPackageReadMe.txt" to the Content folder. This will enable the package to install.

Смотрите также:http://alski.net/post/2013/05/23/Using-NuGet-25-to-deliver-unmanaged-dlls.aspx

Ваш ответ на вопрос