問題タブ [system.io.packaging]

ライブラリ.nupkgNuGet.Coreを使用したり、nuget.exe pack.

私が理解しているように、本質的に.nupkg、単一のファイルを含む を生成するには、Open Package Format ファイルの作成における次の「簡単な手順」の問題である必要があります。

1. nuspec を検証します (プログラムで生成されますが、そのような lib / 処理フェーズからの出力が「クリーン」であることを知っておくとよいでしょう)
2. .nuspecをファイルとしてパッケージに含めます (署名や操作は必要ありません) 。
3. パッケージにリンクされているファイルを、.nuspec

コマンドラインが行うであろう不足している手順について誰かが私に記入してくれるとありがたいnuget packです（署名する必要があるものなど）.

上記の手順で何も見逃していないことを検証することが最も価値がありますが、コードも害はありません。

もう少しコンテキスト: 今のところ、ダウンストリーム コンシューマーは、同じコードベースの一部であるコードのみです (これも を使用しませんNuGet.Core)。今は重要ではありませんが、VS やサードパーティのツールが生成されたパッケージをイントロスペクトできるようにすることが望ましいと考えられます。

追加のコンテキスト。

[@bricelam 経由]:.nupkgファイルは標準のパッケージファイルです。つまり、特定のスキーマに準拠した Zip ファイルで、マニフェストなどがあります。

[ @maartenba経由]: [ソリューションがクロスプラットフォームで動作する必要があるため、これは素晴らしい] のMono impl があります。System.IO.Packaging

PackagePart.GetStreamの呼び出し元は、返された Stream オブジェクトを破棄する必要がありますか? それとも、このメソッドは再利用できるオブジェクトを返しますか? ドキュメントは言いません。

.NET ソース コードを見ると、ほぼすべての場所で呼び出しGetStream()が直接的または間接的に結果を破棄します。私の最良の答えは、GetStream() の結果はいつでも破棄できるということですが、親 PackagePart が破棄されている場合は必ずしも破棄する必要はありません。

System.IO.Packaging.PackageWeb サーバーから受け取った を解凍しようとしています。つまり、私はSystem.IO.Packaging.Package.Open(Stream)メソッドを使用し、それを a の応答ストリームに渡していSystem.Net.HttpWebResponseます。残念ながら、これによりSystem.ArgumentException、

シークをサポートしていない [a] ストリームでは操作できません。

参照ソースを見ると、内部クラスを使用する唯一の実装としてSystem.IO.Packaging.Package使用されていることがわかります。そして案の定、 my からの応答ストリームの場合、メソッドは588 行目でこの例外を発生させます。System.IO.Packaging.ZipPackageZipArchiveValidateModeAccessStreamStreamingCombinations()stream.CanSeekfalseHttpWebResponse

streamingただし、どうやら常にであり、メソッドfalseから までずっと渡される魔法のパラメータがあります。Package.Open()ValidateModeAccessStreamStreamingCombinations()

だからここに私の質問があります:シーク不可能なストリームからオンザフライでPackage.Open(Stream)構築するために使用する方法はありますか? Packageまたは、ストリームのコンテンツをどこかにキャッシュする必要がありMemoryStreamますか? (アンパックしたパッケージストリームには興味がないので、本当にやりたくありません。)

Package クラスを使用して zip ファイルを作成しています。これは非常にうまく機能します。私がそこに置きたくない唯一のもの（存在する）は、フォルダー構造も保存されることです。クラスを調べたにもかかわらず、そこにパラメーターが見つからなかったので、それは不可能だと思いますが、何かを見落としている可能性があります。

したがって、私の質問は次のとおりです。フォルダー構造を .zip ファイルに保存しない方法はありますか?

例: .zip ファイル内ではなく、c:\test\mytest\blahblup.txt として保存する必要があり blahblup.txtc:\test\mytest\blahblup.txt

使用したコード:

System.IO.Packaing.Package クラスを使用してファイルを圧縮しています。アプリケーションの複数のインスタンスを同時に実行し、ファイルを読み取って保存することができます。小さなファイルを操作する場合はすべて問題ないように見えますが、大きなファイルが関係している場合、アプリケーションの 2 つのインスタンスが同時に保存されると、以下に示すスタック トレースを使用して、この操作のためにストアを開かなければならないというメッセージで例外が発生します。

私の理解では、10 MB 未満のファイルのパッケージを操作する場合、データはメモリ ストリームに保存されますが、内部で 10 MB を超えると、IsolatedStorage に切り替わります。それを念頭に置いて、これらは複数のインスタンスが実行されているにもかかわらず、それらはすべて同じ分離されたストレージの場所を解決することがわかり、それが問題が発生したと考えています.各インスタンスを強制的に解決するためのハックを見つけることができました.次のコードを使用して別の場所に移動します。

それで問題は解決しましたが、私はそれが少し好きではありません。この問題をエレガントに修正する方法を理解するのを手伝ってください。さらに調査したところ、IsolatedStorage は複数のスレッドで使用することさえ意図されていないことがわかりました。これにより、パッケージを扱うときになぜそれがオプションだったのか疑問に思います。

アップデート：

さらに、IsolatedStorage にアクセスするには、コードが必要なネイティブ プラットフォーム オペレーティング システムの権限をすべて持っている必要があり、そうでない場合は、IsolatedStorage ストリームの作成に失敗するため、問題が発生する可能性があります。

更新 2

この問題に対処する Windows 8.1 および Windows Server 2012 R2 上の .NET Framework 4.5、4.5.1、および 4.5.2の修正プログラムがリリースされました。Eric White は、Isolated Storage を使用しない System.IO.Packaging の新しい実装も書きました。これは実際に COREFX に追加される予定です。彼の実装はこちらから入手できます。

これに関連して System.IO.Packaging で発生する可能性がある Microsoft によって示されているその他の問題は次のとおりです。

別のスレッドで大きなパッケージを使用すると、デッドロックが発生する場合があります。System.IO.Packaging は、10 メガバイト (MB) を超えるパッケージに IsolatedStorage を使用します。2 つ以上のスレッドが大きなパッケージを使用すると、パッケージが独立していてもデッドロックが発生することがあります。デッドロックには 2 つのスレッドが関係しています。1 つは IsolatedStorageFile.Lock で待機し、もう 1 つは IsolatedStorageFile クラスの別のメソッドで待機しています。この問題は、System.IO.Packaging に同期を追加して、IsolatedStorageFile の問題を回避することで修正されます。パッケージが独立していても、別のスレッドで開かれているパッケージから PackageProperties を取得すると、例外が発生する場合があります。これから発生する最も一般的なコール スタックは次のとおりです。

この問題は、共有内部リソースの競合によって引き起こされ、各パッケージにそのリソースのコピーを与えることで解決されます。