We don't expect users to use CloudEventFormatter directly anyway, so
convenience methods aren't really important. If we later decide we
want them, we can put them in the base class instead.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This allows us to remove the Newtonsoft.Json dependency from the
SDK, and implement another event formatter based on System.Text.Json
later on. That should probably wait until we've iterated on the
design of event formatters though.
This commit moves us closer towards (but doesn't fix) #42.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This still leaves a hole where the user created a Uri instance
manually on Linux and it claims to be absolute, but it would
potentially be confusing to spot this in Validate as well...
Signed-off-by: Jon Skeet <jonskeet@google.com>
Each of these classes has 100% coverage just by running their own tests.
There are still some areas of concern:
- .NET's URI parsing and formatting seems hard to predict, so we're not validating as much as I'd like
- There are some interesting questions about CloudEvent behavior which are tested in a "QuestionableBehavior" nested class in CloudEventTest
There's a fair amount of production code changing in here as well, primarily around validation.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This touches almost file in the repository, because it's hard not to
with such a fundamental change.
There are *lots* of TODOs now, all of which we should chase down
before release. In most cases this isn't a new problem - it's just
one that wasn't noted before,
The two main changes are:
- Spec versions, attributes, and attributes types are now first-class
types. Rather than being able to set attributes to any value you
want, values have to be of the right type and have a valid value
(e.g. for datacontenttype). This centralizes value conversion
for the most part (although transport/format-specific conversions
may still be required) and makes everything more predictable.
- Extensions are now *not* first-class types; instead, the extension
attributes can be registered with the CloudEvent in order to perform
appropriate validation etc, and a pattern around extensions
providing extension methods on CloudEvent allows them to be used
easily.
This work has revealed a lot of smaller problems, such as the HTTP
transports propagating a content of "null" (rather than no content)
when no data was set in the CloudEvent. More testing is certainly
required.
It's worth noting that this is a really big breaking change. The 2.0
release was already going to be breaking, but this is much larger
than the previous changes. I assert that the benefits outweight the
costs though, and even though the package already has many users,
we hope there will be many times more users in the future.
Proposed process for this PR:
- This initial commit does not include nearly as many unit tests for
CloudEvent, CloudEventAttribute or CloudEventAttributeType as I'd
like. Those will come in a follow-up commit (which should be
reviewed before merging) but don't affect the review of the overall
ideas.
- If the general thrust of this PR is acceptable, then I propose we
merge it, only making changes to the most egregious problems, and
leaving further clean-up work (of which there's likely to be a lot)
to later PRs. It's easier to create a clean-up PR in Visual Studio
than to suggest fixes via GitHub.
Style changes:
- Use explicit access modifiers
- Move using directives before the namespace declaration
- Unit tests are generally more separated out to correspond to
production classes, and are in separate directories/namespaces
by project instead of all at the top level.
Currently StyleCop is not installed, but we should probably either
do that or use regular Roslyn analyzers in the long term - along
with turning on XML documentation generation.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This commit includes two WithSpecVersion methods, one in CloudEvent
and the other in CloudEventAttributes, which convert from one
version to another. These are currently internal, but we can expose
them later if we wish.
Fixes#65Fixes#66
Creating this commit has raised more issues to discuss:
- CloudEventSpecVersion.Default is a public enum value; changing that
later would be a breaking change in difficult-to-document ways.
- In general, CloudEventSpecVersion feels like it deserves to be a
class with well-known specific instances, rather than an enum. That
would make various things much simpler.
- Given that attributes other than data have a limited set of types,
I suspect it's worth having a CloudEventAttribute type encapsulating
that.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Also, format those timestamps using the Timestamps class introduced previously.
Fixes#61Fixes#57Fixes#48
Signed-off-by: Jon Skeet <jonskeet@google.com>
We can potentially turn the AppVeyor integration down entirely later
on, but at least for now let's make sure packages are pushed manually.
Signed-off-by: Jon Skeet <jonskeet@google.com>
CloudEventContent now *does* map attributes to HTTP headers in
structured mode, including datacontenttype.
This commit also fixes the format of date/time values to be RFC-3339
compliant.
Signed-off-by: Jon Skeet <jonskeet@google.com>
- For structured mode, we shouldn't map attributes to HTTP headers
- For binary mode, we should default the media content type to application/json
- UrlEncode and UrlDecode headers in binary mode
- Adds more testing of headers
Fixes#67 and #69.
Signed-off-by: Jon Skeet <jonskeet@google.com>
It's simpler and more reliable to do this with Directory.Build.props files than in individual project files.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Note that it refers to version history documents - but doesn't
specify where those are. That's up for discussion - I've filed #76
for that.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This commit won't actually push anything - but it will allow
us to test things before we *do* manually create a release.
Once testing is completed, we'll want to use a (suitably encrypted)
NuGet API key to push to NuGet.
Note that this initially assumes we want to release all packages at
the same time. We'll want to change it when we reach GA for 2.0.0.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Although PDB files are discouraged in some cases, there's a trade-off between package size and having to use a separate symbol package.
In our case, the packages are very small, and the PDBs only contribute a small amount of that size anyway.
Fixes#53 (verified)
Signed-off-by: Jon Skeet <jonskeet@google.com>
The snk file was generated using this command:
sn -k CloudEventsSdk.snk
Note that this is a breaking change. (Other changes have already
been breaking, but this is *very* breaking.)
Fixes#24.
Signed-off-by: Jon Skeet <jonskeet@google.com>
InternalsVisibleTo can be very difficult to use correctly between production packages - it's easy to forget that an "internal" member can't take any breaking changes due to other packages that depend on it.
It's reasonable to use InternalsVisibleTo for test packages though.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This makes it easier to stay consistent across projects
New properties/targets added:
- Treat warnings as errors
- Use SourceLink for all production projects, via the Microsoft.SourceLink.GitHub package
- Explicitly state that the build should be deterministic
Signed-off-by: Jon Skeet <jonskeet@google.com>
Jon Skeet
JoshLove-msft
Clemens Vasters
Doug Davis
clemensv