Stripe-dotnet: System.Collections.Immutable Dependancy

@DanWM The dependency was added back in version 22 (#1428). We could technically remove it, but it is good practice to use immutable types where possible, and System.Collections.Immutable should be compatible with all environments where Stripe.net is usable (it is compatible with .NET Framework 4.5 and .NET Standard 1.0, while Stripe.net's own minimum requirements are .NET Framework 4.5 and .NET Standard 1.2).

Could you tell me more about the build errors you're observing?

The problem appears to be with System.Collections.Immutable and System.Runtime.
It appears to require a web.config assembly reference to System.Runtime. I'm not sure why. The rest of the project has not needed it. This has allowed my application to run now.

Also, based on the release notes since version 22.0.0 was released, I adjusted the PaymentIntentCreateoptions. I successfully use the following parameters:
Amount, Currency, Description, PaymentMethodTypes, CaptureMethod, ApplicationFeeAmount, OnBehalfOf, TransferData, PaymentIntentTransferDataOptions { Destination }

However, I'm now suddenly getting an error when I later attempt to update just the Description of the payment intent. I get the error below:
Newtonsoft.Json.JsonSerializationException
HResult=0x80131500
Message=Error converting value {null} to type 'System.Int64'. Path 'transfer_data.amount', line 121, position 24.
Source=Newtonsoft.Json

Does this have to do with our account being on API version 2018-05-21 ?

System.Collections.Immutable does depend on NETStandard.Library if you're using .NET Standard 1.x, and NETStandard.Library itself depends on System.Runtime. I'm not sure why System.Runtime would cause any issues though.

The JSON deserialization error is unrelated. I've found the cause and will release a fix shortly, thanks for reporting!

Note that it's recommended that you keep your account's API version in sync with the API version your Stripe.net library is pinned to, otherwise webhook events might be incorrectly formatted. As of v22, Stripe.net will by default raise an exception when trying to deserialize webhook events if the API version doesn't match, cf. https://github.com/stripe/stripe-dotnet/wiki/Migration-guide-for-v22#event-deserialization-with-eventutilityconstructevent--eventutilityparseevent.

I've just released v24.0.2 which should fix the deserialization issue with transfer_data.amount. The Amount property on Stripe.ChargeTransferData instances is now nullable, so deserialization will no longer fail when the API returns null.

It's a legacy ASP.NET Web Forms application that targets .NET Framework 4.5.1. Found some info here that might be useful for me - https://github.com/dotnet/standard/issues/481

@DanWM This is very much a shot in the dark, but is it possible you're running into this issue?

Closing due to inactivity, but feel free to reply.

We just upgraded from Stripe version 17 to version 25 and can no longer build our 4.6.1 project. The link by DanWM helps shed some light but ultimately just shows that everything is a gigantic mess right now for version >4.6.1. We also receive missing assembly errors of System.Runtime due to the use of System.Collections.Immutable. At this point, we honestly don't know what to do so we're going to fallback to a version prior to 22 and see if we can our large project to compile.

@SunnysGlimpse What .NET version is your app targeting, and what are you using to build your app?

We're targeting 4.6.1 and using Visual Studio 2015 with Update 3. All of the packages.config showed everything targeting 461, and our web application compiled without error, but nearly every web page in our application was purely blank with the same error people have shared around the web:

The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

I went and read the referenced URL above and many other on the issue, but we weren't able to figure out how to get around it. It looks like the issue isn't specific to just 4.6.1 but can happen up to 4.7.1. I believe it is the references to System.Collections.Immutable that are causing the reference issues and not the Stripe package.

We have a very large marketplace with packages from many different sources and need to balance them all. Ultimately, we uninstalled the latest Stripe version and installed version 21.9.0 and everything works perfectly.

@SunnysGlimpse Thanks for the information, and sorry for the trouble. I've also spent a bit of time trying to get to the bottom of this issue, but without much luck -- it doesn't look like anyone has a clear understanding of this problem or a better fix than manually adding a reference to System.Runtime.dll, which definitely isn't great.

We might simply remove the dependency on System.Collections.Immutable in a future version -- as much as I like the safety provided by immutability, it's simply not worth it if it prevents Stripe users from upgrading!

I'll reopen the issue, and post here with an update soon.

@ob-stripe That's absolutely great to hear! Thank you for keeping an open ear! Without that reference, we will definitely try and upgrade to the new .NET SDK, when released. As it stood, I don't know when we would have been able to upgrade as we spent a couple days doing nothing but reading, attempting potential fixes, and banging our head against the wall trying to figure out Microsoft's mishap. As you said, it doesn't seem like even Microsoft has a firm grip on why it is happening. We had considered manually adding the reference to System.Runtime.dll, but shunned it as it just seemed so "hackish" and when you get too many of those, new issues pop up and you begin to forget why you had in the first place.

@SunnysGlimpse Adding System.Runtime.dll doesn't work for me. We have to add following in web.config:

<dependentAssembly>
   <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
   <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.2.0.0" />
</dependentAssembly>

It worked.

In our case, this seemed to be an issue when using Stripe NuGet 25.19.1 which depends on NuGet System.Collections.Immutable 1.5.0.
The .dll contained in System.Collections.Immutable in seems to be 'System.Collections.Immutable, Version=1.1.36.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a', but the one referenced by Stripe NuGet 25.19.1 is System.Collections.Immutable, Version=1.2.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
Forcing the use of the older version of the older assembly by adding:

<dependentAssembly>
<assemblyIdentity name="System.Collections.Immutable"   publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0"   newVersion="1.1.36.0" />
</dependentAssembly>

to Web.config seems to resolve the issue. I'm not sure however if Stripe needs any of the new functionality in 1.2.3.0, or if this will cause stability problems, so it would of course be nice if the reference was removed, or there is a good match between the packages :)

As of version 27.0.0, the library no longer depends on System.Collections.Immutable.