Ghostscript に依存するライブラリ用の Nuget パッケージを作成しようとしているため、管理されていないライブラリである gsdll32.dll を参照しています。標準の dll 参照を含めることはできません。これを nuget ディレクトリ構造のどこに配置すればよいですか?
6 に答える
上記の参照は機能しますが、実際にはビルド後のイベントを変更してファイルをプッシュするため、実際に問題が解決されない場合があります。
私たちが抱えていた問題は、依存する DLL を登録できず、nuget で登録する必要がある別の DLL と並んで存在する必要があったため、lib ディレクトリに存在する必要がありましたが、登録されていませんでした。
nuspec 参照により、libディレクトリ内のどの DLL が Visual Studio プロジェクトに明示的に登録されるかを指定できるようになりました。メタデータ領域のnuspec ファイルに明示的な参照リストを追加するだけです (これが存在しない場合は、既定の動作)。 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ディレクトリにコピーされます。最初の DLL が 2 番目の DLL に依存していること。
元のnuspec リファレンスは次のとおりです。
Lars Michael の方法を使用して主にこれを機能させましたが、追加する必要があったことの 1 つは、James Eby の回答です。Visual Studio はlib
ディレクトリ内のすべての dll を登録しようとしていたためreferences
、nuspec ファイルのメタデータに要素を追加して、マネージド dll のみを登録するように指示しました。
<references>
<reference file="FANNCSharp.dll" />
</references>
また、
<MyPackageFiles Include="$(MSBuildProjectDirectory)\..\Packages\MyPackage\lib\*.*"/>
最初にパッケージの id を試しましたFANNCSharp-x64
が、完全なパッケージ名が必要でした: FANNCSharp-x64.0.1.4
。
Nuget フォーラムでの回答: http://nuget.codeplex.com/discussions/352689
pranavkm: SQLCE パッケージには、PS スクリプトを介して処理する同様の問題があります。https://bitbucket.org/davidebbo/nugetpackages/src/1cba18b864f7/SqlServerCompact/Toolsでスクリプトをチェックアウトし ます。
私が抱えていた問題の 1 つは、パッケージ パスがプロジェクト ファイルに対して常に同じ場所にあるとは限らないことでした。以下は私のために働いた:
NuGet パッケージ内で、管理されていない DLL を lib\native フォルダーに配置します。
次のスクリプトを tools フォルダーに追加します。
インストール.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)
- ターゲット ファイルをビルド フォルダーに追加します。(「MyPackage」をパッケージの名前に変更します)。「CopyMyPackage」などのターゲットに一意の名前を使用すると、「AfterBuild」ターゲットを定義しようとする他のパッケージとの競合を回避できます。このターゲット ファイルは、上記のスクリプトで定義された $(PackagesPath) プロパティを利用します。
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>
- 最後に、Content フォルダーに「MyPackageReadMe.txt」を追加します。これにより、パッケージをインストールできるようになります。
参照: http://alski.net/post/2013/05/23/Using-NuGet-25-to-deliver-unmanaged-dlls.aspx