Changes since 2.5.1:
- Dependencies: system-level dependencies updated
- The NuGet package now uses PackageLicenseExpression (but still
includes the licence file as well).
Fixes ([#252](https://github.com/cloudevents/sdk-csharp/issues/252)).
- Regenerated protobuf schema using the original filename of
cloudevents.proto instead of ProtoSchema.proto. An additional
ProtoSchemaReflection class has been added purely for compatibility.
Fixes ([#256](https://github.com/cloudevents/sdk-csharp/issues/256)).
Signed-off-by: Jon Skeet <jonskeet@google.com>
For some reason we were renaming cloudevents.proto as ProtoSchema.proto, which breaks compatibility with anyone using the original file.
Renaming the reflection class is a breaking change, so I've added an obsolete compatibility class to keep compatibility.
Also updated to Google.Protobuf 3.22.0 (of the general protobuf 22.0 release; protobuf versioning is complex).
Fixes#256
Signed-off-by: Jon Skeet <jonskeet@google.com>
Note that the license file is still embedded in the package (at the root) to conform with the requirement that it's delivered with the software.
Fixes#252
Signed-off-by: Jon Skeet <jonskeet@google.com>
Changes since 2.5.0:
- Dependencies: update dependencies in CloudNative.CloudEvents.Avro
- Add explicit dependency on Newtonsoft.Json 13.0.1 to avoid
transitive dependency on a version containing vulnerabilities
- Update Apache.Avro to 1.11.1
No APIs have changed. This is a patch release as the dependency
changes are very minor (but necessary to avoid vulnerabilities).
Signed-off-by: Jon Skeet <jonskeet@google.com>
- Updated to Apache.Avro 1.11.1 on general principle
- Added explicit dependency on Newtonsoft.Json 13.0.1 to avoid
taking a transitive dependency on a vulnerable version
Addresses short-term concerns of #245.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Changes since 2.4.0:
- Dependencies: update dependencies in CloudNative.CloudEvents.AspNetCore:
- Remove dependency on Microsoft.AspNetCore.Mvc.Core (as we don't use it)
- Update dependency on Microsoft.AspNetCore.Http to 2.1.34
- Explicitly add dependency on System.Text.Encodings.Web 6.0.0 to avoid security issue in older version
No APIs have changed, but this is a minor release due to the significant dependency changes.
Signed-off-by: Jon Skeet <jonskeet@google.com>
The [binding
specification](https://github.com/cloudevents/spec/blob/main/cloudevents/bindings/amqp-protocol-binding.md)
has changed to prefer `cloudEvents_` over `cloudEvents:`. Previously
`cloudEvents_` wouldn't even have been valid.
With this change, users can either:
- Stick with the default prefix, which doesn't change immediately,
but which will change in the first release on or after March 1st 2023
- Explicitly use one or other prefix using the explicitly-named
methods
Other options considered:
- Changing the default now: that's too much of a breaking change. (I
don't want to take a major version bump for this, and with enough
time for the change, I think that's okay.)
- Adding a char or string parameter: that would invite using non-standard prefixes
- Adding a Boolean parameter: that would become problematic if we
ever end up with a third prefix. (Let's hope we don't, but still...)
- Adding an enum and then a parameter for it: feels like overkill
Signed-off-by: Jon Skeet <jonskeet@google.com>
The method names are consistent with the ones in
ProtobufEventFormatter and the Json.NET event formatter.
Currently batch conversion is not supported, but we can add that later if requested.
The ConvertToJsonElement method is horribly inefficient at the
moment (serialize then parse); we can consider how to make it more
efficient later if necessary.
Signed-off-by: Jon Skeet <jonskeet@google.com>
The method names are consistent with the ones in ProtobufEventFormatter.
Currently batch conversion is not supported, but we can add that later if requested.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This is the Json.NET equivalent of #225.
Note that not every option in JsonTextWriter is supported; in the future we could potentially introduce some alternative approach to provide more flexibility.
Signed-off-by: Jon Skeet <jonskeet@google.com>
We still need it in CloudNative.CloudEvents for backward
compatibility, but we can do that via derivation - which is
pleasantly simple given that the only constructor is parameterless.
Users should update to use the CloudNative.CloudEvents.Avro
namespace at their earliest convenience.
Fixes#219.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Changes since 2.3.0:
- Bug fix: ignore the charset when determining the content type for decoding JSON (#216)
- Bug fix: make the NuGet package deterministic (#175)
Signed-off-by: Jon Skeet <jonskeet@google.com>
In particular, this now generates a random event ID - v1.x used to
do this automatically, but in 2.x it needs to be explicit.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Changes since 2.2.0:
- Bug fix: BinaryDataUtilities.AsArray misbehavior with array segments ([#209](https://github.com/cloudevents/sdk-csharp/issues/209))
- Bug fix: Links within XML documentation corrected after spec repo change
- Feature: Reject "data" as a context attribute name (spec has been clarified for this)
- Feature: Support Data content type inference in event formatters
- The JsonEventFormatter classes infer "application/json" for all data
- Feature: CloudNative.CloudEvents.Protobuf is now GA (same version as other packages)
Signed-off-by: Jon Skeet <jonskeet@google.com>
- New methods in CloudEventFormatter to support inference
- JsonEventFormatter infers a content type of application/json for non-binary data
- All transports use the inferred content type when formatting in binary mode
- Documentation for both formatters and bindings has been updated
Signed-off-by: Jon Skeet <jonskeet@google.com>
This isn't currently in the CloudEvents spec, but was agreed at
the meeting of 2022-02-03, on the grounds that the most prominent
event formt - JSON - already *implicitly* prohibits it.
We should wait until the spec is updated before merging this.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Changes in this release:
- Bug fix: the "source" attribute is now validated to be non-empty
- Bug fix: the JSON event formatters comply with the clarified JSON event format spec
- Dependency: Apache.Avro dependency updated to 1.11.0
- Feature: New package CloudNative.CloudEvents.Protobuf, released as 2.0.0-beta.1
Signed-off-by: Jon Skeet <jonskeet@google.com>
URI references can be empty - we have a test proving that. But the source attribute is required to be non-empty, so we should validate that.
This bug fix is a breaking change for anyone who was previously creating (and then validating) CloudEvent instances with a present-but-empty source.
However, their events were already broken, and we'd expect them to cause issues with other consumers (at least any performing comprehensive validation).
Signed-off-by: Jon Skeet <jonskeet@google.com>
- Make "JSON media type detection" configurable, and default to */json and */*+json
- Default to JSON content type (including making it present in the serialized event)
- Make a "binary vs non-binary" distinction as the first part of serialization (instead of as a fallback)
- Deserialize string data values regardless of content type
- Prohibit non-string data values for non-JSON content types
Signed-off-by: Jon Skeet <jonskeet@google.com>
- Make "JSON media type detection" configurable, and default to */json and */*+json
- Default to JSON content type (including making it present in the serialized event)
- Make a "binary vs non-binary" distinction as the first part of serialization (instead of as a fallback)
- Deserialize string data values regardless of content type
- Prohibit non-string data values for non-JSON content types
Signed-off-by: Jon Skeet <jonskeet@google.com>
This requires a few nullable-reference-type overrides in tests where
we're absolutely confident they won't be null (and if we're wrong,
an NRE is fine to break the test).
Signed-off-by: Jon Skeet <jonskeet@google.com>
Bug fix ([#77](https://github.com/cloudevents/sdk-csharp/pull/177)): dependency on the
`Nullable` package was not declared with `PrivateAssets=all`,
leading to that showing up as a dependency. This would break users
who explicitly have a dependency on an older version of `Nullable`.
This fix shouldn't break anyone, as far as we're aware.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Jon Skeet
dependabot[bot]
Tim Bussmann
Magne Helleborg
Simon Eßlinger
Alexander Batishchev
Ofir Shapira
iron9light