Repository navigation
Releases: nforgeio/neonSDK
Release list
v3.1.0
This release consolidates many changes and additional nuget packages that have accumulated privately over the past few months.
v3.0.0
v3.0.0 includes many breaking changes from the v2.x releases. There are a few other breaking changes pending for upcoming releases, but most libraries will remain pretty stable.
Port to OpenTelemetry
Neon.Common has included a homegrown logging infrastructure implemented by LogManager and INeonLogger and other types. These originated maybe 10+ years ago when I ran into trouble with Log4Net and decided to throw together a quick replacement. This looks really non-standard now and doesn't really map that well to modern dependency injection techniques.
More recently, our NeonService class added support for Prometheus metrics.
Now that OpenTelemetry has mostly matured, we've decided that now's the time to embrace the OpenTelemetry APIs and components across neonSDK, neonKUBE, and our internal projects. This will be a significant breaking change.
Here's what you'll need to do to adapt:
-
Neon.Web: The
NeonControllerandNeonControllerBaseused to have logging methods. Now it has a read-onlyLoggerproperty you'll call for logging. This property makes these classes easier to maintain. You'll need to modify class likeNeonController.Error(...)toNeonController.Logger.LogError(...). -
Telemetry Changes:
-
Neon.Common:
- We've decided to converge with OpenTelemetry and the standard Microsoft logging conventions. This means that
NullLogger,TestLogger, andTextLogger,ILogManager,LogManager,NeonDiagnostics.LogLeveltypes have been removed (or made internal) and also that we no longer support these extended log levels: Transient, SInfo, and SError. - Logging configuration is no longer done via
LogManager.NeonServiceconfigures console logging by default and enables tracing when the app is running in a Kubernetes cluster. These behaviors can be disabled so that applications can do custom log configuration. - Most code that emits logs will need to add these usings:
using Microsoft.Extensions.Logging; // Loads the base logging symbols, including basic `ILogger` logging extensions. using Neon.Diagnostics; // Loads extended logging extensions including nicer ways to add tags
- We've decided to converge with OpenTelemetry and the standard Microsoft logging conventions. This means that
-
Logging and tracing from NeonSDK libraries is now disabled by default, unless you're using
NeonService. To enable this for other scenarios, you'll need to modify your telemetry initialization code to callNeon.Diagnostics.TelemetryHub.Initialize(), passing theILoggerFactoryandActivitySource. -
We've implemented several new
ILoggerextension methods inNeon.Diagnostics.LoggerExtensions. These include methods that make it easier to add tags to logged events as well as for creating a newILoggerthat wraps an existing logger and includes tags to be appended to all events emitted via the logger:ILogger.CreateLoggerWithTags().These new method names end with "Ex" as in:
LogCriticalEx(), LogErrorEx(), LogWarningEx(), LogInformationEx(), LogDebugEx() and LogTraceEx().We recommend that you
use Neon.Diagnostics;and then change all of your logging calls to these new methods. -
Be sure that you pass a
Funcmessage function when logging a interpolated string message:// Instead of this: var name = "Sally"; logger.LogTraceEx($"Hello: {name}"); // Do this: logger.LogTraceEx(() => $"Hello: {name}"); // Doing this more performant when the current log level will disables logging. // The reason is that string interpolation will create a new string in the heap // (incurring GC overhead) and also will consume CPU for do the string processing. // This effort will be completely wasted and if you're doing a lot of debug or trace // logging could result in bloated memory usage and a lot of wasted cycles. -
For projects using our older
ILoggerextensions, you'll need to rename those by adding "Ex to the method name to fix compiler errors. We've also reordered the parameters of some of the new extended methods, so you may need to tweak some of your logging calls. -
Note that our new "ILogger.LogInformationEx()
andILogger.LogWarningEx()extensions replace the oldINeonLogger.LogInfo()andINeonLogger.LogWarn()` methods (with fully spelled out levels). -
The optional
activityIdparameter has been removed fromJsonClientmethods and are also no longer present in theILoggermethods. -
Our logging extensions that accept an
Exceptionparameter have relocated the exception to be the first parameter. This is a change from the oldINeonLoggermethods there the exception parameter was after the message parameter. We've also renamed theeparameter in these cases toexceptionto be more consistent with MSFT'sILoggerextensions.
-
-
ModelGen no longer generates
LogActivityparameters for generated HTTP client methods since the tracing context is implied now. -
NeonService:
- We've removed the
NeonService.LogManagerproperty. Use the staticTelemetryHubclass instead, if necessary. NeonServiceFixturehas been relocated from theNeon.Xunitpackage to the newNeon.Xunit.Servicepackage.
- We've removed the
-
Neon.Cryptography: We've removed the
TlsCertificateclass. This was a (horrible) hack from several years ago before addedX509Certificate2. I doubt that many if any people are using this except for us. The fix is to switch toX509Certificate2. -
Extension method namespace changes: Up until now, we've defined extension methods for various system types in the
Systemor other namespaces owned by other nuget publishers. This isn't great because we might end up conflicting with extension methods that others have written and it's also not super polite to add these definitions by default rather than allowing users to opt-in.We moved all of these into the
Neon.Diagnosticsnamespace and you'll need to use this to opt-into these extensions.When logging dynamically generated message, be sure to use the logging methods that accept a lambda function that returns your message rather than passing the message directly. This improves performance when the event won't be logged due to the current log level. See the
Neon.Diagnostics.LoggerExtensionsclass for more information.
Other Breaking Changes
- .NET Core 3.1 is no longer supported (MSFT has not been supporting this since Oct 2022)
- .NET Core 5.0 is no longer supported (MSFT has not been supporting this since May 2022)
Neon.Common:
-
EnvironmentParserchanges:- We've renamed these parameters:
redacted --> redact - The parser now honors the
NEON_REDACT_OVERRIDE=1environment variable when present by ignoring anyredact: truearguments and including the value being parsed in any logged events. This is useful when debugging but should never be set for production.
- We've renamed these parameters:
-
We've changed the default variable formats for
PreprocessReaderto make them look more like Powershell variable references as opposed to their current somewhat wonky format: #4.We've changed the format for referencing variables like
$(NAME), environment variables like$((NAME)) and secret or profile values like $(((TYPE:NAME))) to something inspired by Powershell and more readable:$(NAME)for variables,$(env:NAME)for environment variables,$(secret:NAME)for secrets and $(profile:NAME)for profile values.This change probably won't impact non-neonFORGE related projects. We wanted to clean this up now before this sees more widespread use, especially for neonKUBE users who can use this to reference variables in cluster definitions, etc.
-
NeonHelper.DockerClihas been changed to returnnullwhen Docker is not installed as opposed to throwing aFileNotFoundException. -
We've removed the
ExceptionResult,ExceptionResult, andCatchAllExceptionclasses. These were intended as a way to serialize an exception for transmission from a remote call back to the client such that it can be re-thrown as the original exception type on the client if possible. We never ended up using this. The other problem is that this required reflection which means that it wouldn't be compatible with trimming and now that net7.0 publication support is so much better, we're beginning the process of trying to rely on things like reflection much less. -
We've modified
NetHelper.ModifyLocalHosts()to make it more generally useful for other than unit testing. The section parameter is no longer optional and has been moved to be the first method parameter. We've also relaxed the section requirements to allow up to 63 non-control ASCII characters. -
NetHelper.ListLocalHostsSections()has been modified to return anIEnumerablenewLocalHostSectioninstances that include the name of the section in addition to the dictionary of address definitions within the section. This method used to return anIEnumerableof just section names. -
NeonHelper.GetBaseDirectory()has been renamed toGetApplicationFolder()
Neon,Cadence and Neon.Temporal:
We no longer in the .NET Cadence and Temporal client business now that temporal.io is in the process of writing an official client for .NET.
Neon.Couchbase:
The Neon.Couchbase library has been removed for v3.0.0. We haven't used Couchbase in years and our client extensions support only the Couchbase v2+ clients which have been deprecated for some time now and the v3+ clients are very different. It doesn't make sense to maintain this any more.
Neon.Service:
- We've removed several of the optional parameters to the
NeonServiceconstructor and replaced these ...
v2.19.0
This is the first public release for several months and includes changes we've accumulated over that time and is the first release since we've relocated these libraries from the neonKUBE repo to the new neonSDK repo in preparation for the first neonKUBE releases. It was confusing to be releasing two different projects with differing version numbers from the same repo.
There may be a few breaking changes, but frankly we haven't been tracking these. I don't believe that most folks will be impacted.
This may be the last 2.x release of the SDK since we're preparing SDK v3.0.0 to be released in the immediate future. v3.0.0 will be a breaking release with significant changes to logging and NeonService; we've ditched our semi-proprietary implementation in favor of OpenTelemetry and standard pipeline configuration. We're also tweaking our ILogger extension methods.