Out of date dependencies blocking package updates

[qstarin]

The latest version of Imageflow.Server - 0.8.3 - has a transitive dependency on Microsoft.IO.RecyclableMemoryStream >= 1.2.2 && < 3.0.0 (through Imageflow.AllPlatforms & Imageflow.Net 0.10.2).

However, the latest versions of Imageflow.Net have an incompatible dependency on Microsoft.IO.RecyclableMemoryStream >= 3.0.0 && < 4.0.0.

We use both Imageflow.Net and Imageflow.Server in a large solution for a production system. We also utilize Microsoft.IO.RecyclableMemoryStream in our core/shared code library project that is referenced by every other application in our solution.

The incompatible dependencies between Imageflow.Net and Imageflow.Server are preventing us from updating either Imageflow.Net or Microsoft.IO.RecyclableMemoryStream to their latest versions.

Would you please consider releasing an updated Imageflow.Server package that references the latest version of Imageflow.Net?

Side question, if you don't mind: Is it possible to utilize a specific Imageflow.NativeRuntime library in projects using Imageflow.Server?

[lilith]

Yes, I see the problem. I'll issue a point release soon to fix that (I'm currently working on a major rewrite of the server to support cloud native and serverless deployments more easily). While you can use a specific version of the imageflow runtime, you should typically try to keep it up to date, as it contains image codecs and other key surface areas. Is there a reason you would want to pin an older runtime version?

…

On Sun, Jun 16, 2024, 12:13 AM Quentin ***@***.***> wrote: The latest version of Imageflow.Server - 0.8.3 - has a transitive dependency on Microsoft.IO.RecyclableMemoryStream >= 1.2.2 && < 3.0.0 (through Imageflow.AllPlatforms & Imageflow.Net 0.10.2). However, the latest versions of Imageflow.Net have an incompatible dependency on Microsoft.IO.RecyclableMemoryStream >= 3.0.0 && < 4.0.0. We use both Imageflow.Net and Imageflow.Server in a large solution for a production system. We also utilize Microsoft.IO.RecyclableMemoryStream in our core/shared code library project that is referenced by every other application in our solution. The incompatible dependencies between Imageflow.Net and Imageflow.Server are preventing us from updating either Imageflow.Net or Microsoft.IO.RecyclableMemoryStream to their latest versions. Would you please consider releasing an updated Imageflow.Server package that references the latest version of Imageflow.Net? Side question, if you don't mind: Is it possible to utilize a specific Imageflow.NativeRuntime library in projects using Imageflow.Server? — Reply to this email directly, view it on GitHub <#96>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2LH6L2TXD2X4NRAU7Q23ZHUUIPAVCNFSM6AAAAABJMKGPYCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2TKNBVHE2DOMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[qstarin]

Is there a reason you would want to pin an older runtime version?

I notice that Imageflow.Server references Imageflow.AllPlatforms but I am wondering if we can utilize Imageflow.NativeRuntime.win-x86_64-haswell or Imageflow.NativeRuntime.ubuntu-x86_64 (the latest versions).. Is it as simple as installing the NativeRuntime package alongside the Server package? I am not sure how to verify if the native libraries are being utilized by Imageflow.Server in that scenario.

[lilith]

You can install them, although you might have issues trying to install -haswell variants. The AllPlatforms package pulls in all the os/bitness variants at once.

…

On Sun, Jun 16, 2024, 1:32 AM Quentin ***@***.***> wrote: Is there a reason you would want to pin an older runtime version? I notice that Imageflow.Server references Imageflow.AllPlatforms but I am wondering if we can utilize Imageflow.NativeRuntime.win-x86_64-haswell or Imageflow.NativeRuntime.ubuntu-x86_64 (the latest versions).. Is it as simple as installing the NativeRuntime package alongside the Server package? I am not sure how to verify if the native libraries are being utilized in that scenario. — Reply to this email directly, view it on GitHub <#96 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2LH7RARBISMFDH6OJBVTZHU5RJAVCNFSM6AAAAABJMKGPYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZRGEZTONZVGA> . You are receiving this because you commented.Message ID: ***@***.***>