Bot releases are visible (Hide)
CoreWCF.ConfigurationManager 1.5.2
CoreWCF.Http 1.5.2
CoreWCF.Kafka 1.5.2
CoreWCF.Kafka.Client 1.5.2
CoreWCF.NetFramingBase 1.5.2
CoreWCF.NetTcp 1.5.2
CoreWCF.Primitives 1.5.2
CoreWCF.Queue 1.5.2
CoreWCF.RabbitMQ 1.5.2
CoreWCF.RabbitMQ.Client 1.5.2
CoreWCF.Templates 1.5.2
CoreWCF.UnixDomainSocket 1.5.2
CoreWCF.WebHttp 1.5.2
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, .NET 7, and .NET8. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 8.0. The CoreWCF.RabbitMQ.Client, CoreWCF.Kafka.Client, and CoreWCF.UnixDomainSocket packages only support .NET 6 or later.
https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-32jq-mv89-5rx7 - CoreWCF NetFraming based services can leave connections open when they should be closed.
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/1288 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.5.1...v1.5.2
Published by mconnew 7 months ago
CoreWCF.ConfigurationManager 1.4.2
CoreWCF.Http 1.4.2
CoreWCF.Kafka 1.4.2
CoreWCF.Kafka.Client 1.4.2
CoreWCF.NetFramingBase 1.4.2
CoreWCF.NetTcp 1.4.2
CoreWCF.Primitives 1.4.2
CoreWCF.Queue 1.4.2
CoreWCF.RabbitMQ 1.4.2
CoreWCF.RabbitMQ.Client 1.4.2
CoreWCF.Templates 1.4.2
CoreWCF.WebHttp 1.4.2
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0. The client packages CoreWCF.RabbitMQ.Client and CoreWCF.Kafka.Client are supported on .NET 6 or later.
https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-32jq-mv89-5rx7 - CoreWCF NetFraming based services can leave connections open when they should be closed.
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/1209 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.4.1...v1.4.2
Published by mconnew 11 months ago
CoreWCF.ConfigurationManager 1.5.1
CoreWCF.Http 1.5.1
CoreWCF.Kafka 1.5.1
CoreWCF.Kafka.Client 1.5.1
CoreWCF.NetFramingBase 1.5.1
CoreWCF.NetTcp 1.5.1
CoreWCF.Primitives 1.5.1
CoreWCF.Queue 1.5.1
CoreWCF.RabbitMQ 1.5.1
CoreWCF.RabbitMQ.Client 1.5.1
CoreWCF.Templates 1.5.1
CoreWCF.UnixDomainSocket 1.5.1
CoreWCF.WebHttp 1.5.1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, .NET 7, and .NET8. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 8.0. The CoreWCF.RabbitMQ.Client, CoreWCF.Kafka.Client, and CoreWCF.UnixDomainSocket packages only support .NET 6 or later.
With this release, the CoreWCF.UnixDomainSocket package has come out of preview. This package enables you to use unix domain sockets for same host communication with CoreWCF. This provides an alternative to NetNamedPipe and works on all supported platforms. This was contributed by @birojnayak from AWS. The WCF Client project is simultaneously releasing the package System.ServiceModel.UnixDomainSocket to provide the client for this transport.
In previous versions, the IOperationInvoker called MethodInfo.Invoke to call the service method. This is a relatively expensive way to call a method. In this release, we have a new implementation using LINQ Expressions which compiles a strongly typed lambda function to call the service method. This will provide a small performance improvement when dispatching a service call. If you experience any compatibility issues, you can set the AppContext switch CoreWCF.Dispatcher.UseLegacyInvokeDelegate
to true to fallback to the previous implementation. If you need to do this, please open an issue explaining the problem you had. This feature was implemented by @g7ed6e
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/1288 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.5.0-preview1...v1.5.1
Published by mconnew about 1 year ago
CoreWCF.ConfigurationManager 1.5.0-preview1
CoreWCF.Http 1.5.0-preview1
CoreWCF.Kafka 1.5.0-preview1
CoreWCF.Kafka.Client 1.5.0-preview1
CoreWCF.MSMQ 1.5.0-preview1
CoreWCF.NetFramingBase 1.5.0-preview1
CoreWCF.NetNamedPipe 1.5.0-preview1
CoreWCF.NetTcp 1.5.0-preview1
CoreWCF.Primitives 1.5.0-preview1
CoreWCF.Queue 1.5.0-preview1
CoreWCF.RabbitMQ 1.5.0-preview1
CoreWCF.RabbitMQ.Client 1.5.0-preview1
CoreWCF.Templates 1.5.0-preview1
CoreWCF.UnixDomainSocket 1.5.0-preview1
CoreWCF.WebHttp 1.5.0-preview1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0. The CoreWCF.RabbitMQ.Client, CoreWCF.Kafka.Client, and CoreWCF.UnixDomainSocket packages only support .NET 6 or later.
We've added the CoreWCF.UnixDomainSocketpackage to provide support for using unix domain sockets with CoreWCF. This provides an alternative to NetNamedPipe and works on all supported platforms. This was contributed by @birojnayak from AWS.
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/1220 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.4.1...v1.5.0-preview1
Published by mconnew about 1 year ago
CoreWCF.Primitives 1.4.1
CoreWCF.Http 1.4.1
CoreWCF.WebHttp 1.4.1
CoreWCF.NetFramingBase 1.4.1
CoreWCF.NetTcp 1.4.1
CoreWCF.Queue 1.4.1
CoreWCF.RabbitMQ 1.4.1
CoreWCF.RabbitMQ.Client 1.4.1
CoreWCF.Kafka 1.4.1
CoreWCF.Kafka.Client 1.4.1
CoreWCF.ConfigurationManager 1.4.1
CoreWCF.Templates 1.4.1
The MSMQ and NetNamedPipe packages are still in preview and will be in the next preview release.
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0. The client packages CoreWCF.RabbitMQ.Client and CoreWCF.Kafka.Client are supported on .NET 6 or later.
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/1209 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.4.0...v1.4.1
Published by mconnew about 1 year ago
CoreWCF.Primitives 1.4.0
CoreWCF.Http 1.4.0
CoreWCF.WebHttp 1.4.0
CoreWCF.NetFramingBase 1.4.0
CoreWCF.NetTcp 1.4.0
CoreWCF.Queue 1.4.0
CoreWCF.RabbitMQ 1.4.0
CoreWCF.RabbitMQ.Client 1.4.0
CoreWCF.Kafka 1.4.0
CoreWCF.Kafka.Client 1.4.0
CoreWCF.ConfigurationManager 1.4.0
CoreWCF.Templates 1.4.0
The MSMQ and NetNamedPipe packages are still in preview and will be in the next preview release.
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0. The client packages CoreWCF.RabbitMQ.Client and CoreWCF.Kafka.Client are supported on .NET 6 or later.
The CoreWCF.Queue package has come out of preview and provides a base set of classes for Queue based transports. New to this release are the packages CoreWCF.Kafka and CoreWCF.Kafka.Client, contributed by @g7ed6e. This enables using CoreWCF with the Apache Kafka distributed event streaming platform. The RabbitMQ packages CoreWCF.RabbitMQ and CoreWCF.RabbitMQ.Client are now out of preview. The MSMQ package is not out of preview yet.
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/1209 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.4.0-preview1...v1.4.0
Published by mconnew over 1 year ago
CoreWCF.Primitives 1.4.0-preview1
CoreWCF.Http 1.4.0-preview1
CoreWCF.WebHttp 1.4.0-preview1
CoreWCF.NetFramingBase 1.4.0-preview1
CoreWCF.NetTcp 1.4.0-preview1
CoreWCF.NetNamedPipe 1.4.0-preview1
CoreWCF.Queue 1.4.0-preview1
CoreWCF.MSMQ 1.4.0-preview1
CoreWCF.RabbitMQ 1.4.0-preview1
CoreWCF.RabbitMQ.Client 1.4.0-preview1
CoreWCF.ConfigurationManager 1.4.0-preview1
CoreWCF.Templates 1.4.0-preview1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0. The CoreWCF.RabbitMQ.Client package only supports .NET 6 or later.
We've added the CoreWCF.NetNamedPipe package to provide support for using named pipes. The code common to NetNamedPipe and NetTcp has been refactored into the CoreWCF.NetFramingBase. This makes it easier to add new transports based on top of streaming connections. Named Pipe support is only for Windows, but we'll be adding Unix Domain Socket support at a later date to provide an equivalent feature for using on Linux. This was contributed by @mconnew from Microsoft.
We've added the CoreWCF.Queue package which provides a base set of classes to make adding Queue based transports easier. We are releasing the new packages CoreWCF.MSMQ and CoreWCF.RabbitMQ (implements the AMQP protocol) to provide transports for using Windows MSMQ and RabbitMQ. We also currently have in development a queue based transport for Apache Kafka which will be released in the near future. The goal is to provide support for MSMQ as a step to migrating to other queue technologies. We're also releasing our first client package CoreWCF.RabbitMQ.Client which is only supported on .NET 6.0 or later. This is built on top of the WCF Client 6.0 pre-release package. This work was coordinated by @birojnayak from Amazon AWS, who wrote the design document for the generic Queue implementation. The majority of the code was contributed by @Ximik87 and @jonlouie. We also had code contributions from @birojnayak and @g7ed6e.
@bjornhellander exposed ServiceBehaviorAttribute.UseSynchronizationContext
and added validating tests to confirm the property is working as expected. #983
When using HttpClientCredentialType.InheritedFromHost
, we now issue an auth challenge if request is not authenticated if earlier middleware didn't do so, by @g7ed6e in #967
Fixed DI injection generated code when parameter name in implementation doesn't match parameter name in contract, by @g7ed6e in #1030
Fixed channel state transitions for HTTP which was breaking returning a fault when user extensibility throws an exception, by @mconnew in #1011
Fixed MTOM headers being incorrectly added to response body with HTTP, by @mconnew in #1049
Fixed compat behavior of [WebGet|WebInvoke]Attribute.Is[Request|Response]FormatSetExplicitly
when using the attributes from System.ServiceModel.dll
when using WebHttp on .NET Framework, by @arontsang in #1035
The version of dependent packages has changed in this release. We've had feedback that depending on the latest versions of packages causes problems for some users as it forces an upgrade. Starting from this release, we'll depend on the latest LTS versions of packages. This means we've downgraded requirements for a couple of dependencies from the 7.x version to the 6.x version. Upgrading and using the 7.x versions of packages in your own projects is still supported and intended to work.
As part of the work necessary to refactor common code between NetTcp and NetNamedPipe, CoreWCF now supports hosting NetTcp services when using an HTTP IServer other than Kestrel. This means you can use NetTcp with HttpSys or even hosted in IIS. Please note, NetTcp still doesn't support IIS hosted activation or port sharing, it still listens on its own socket and needs a unique port number.
None
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/1069 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.3.2...v1.4.0-preview1
Published by mconnew over 1 year ago
CoreWCF.Primitives 1.3.2
CoreWCF.Http 1.3.2
CoreWCF.NetTcp 1.3.2
CoreWCF.WebHttp 1.3.2
CoreWCF.ConfigurationManager 1.3.2
CoreWCF.Templates 1.3.2
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0.
This release contains the follow bug fixes:
OpenApiResponse
and FromServices
together in the same contract by @g7ed6e in https://github.com/CoreWCF/CoreWCF/pull/970
AuthorizationHandler<T>
is added to DI with scoped lifetime by @g7ed6e in https://github.com/CoreWCF/CoreWCF/pull/948
Your feedback is important and appreciated. Please use the existing v1.3.0 discussion https://github.com/CoreWCF/CoreWCF/discussions/946 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.3.1...v1.3.2
Published by mconnew almost 2 years ago
CoreWCF.Primitives 1.3.1
CoreWCF.Http 1.3.1
CoreWCF.NetTcp 1.3.1
CoreWCF.WebHttp 1.3.1
CoreWCF.ConfigurationManager 1.3.1
CoreWCF.Templates 1.3.1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. We have dropped support for .NET Core 3.1 as support has ended for that version. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0.
This release is to address a bug in the newly released ASP.NET Core authorization integration. When specifying InheritedByHost as the authentication mechanism, we are failing to reject unauthenticated requests. This bug only affects the new authentication and authorization feature introduced in v1.3.0.
Your feedback is important and appreciated. Please use the existing v1.3.0 discussion https://github.com/CoreWCF/CoreWCF/discussions/946 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.3.0...v1.3.1
Published by mconnew almost 2 years ago
CoreWCF.Primitives 1.3.0
CoreWCF.Http 1.3.0
CoreWCF.NetTcp 1.3.0
CoreWCF.WebHttp 1.3.0
CoreWCF.ConfigurationManager 1.3.0
CoreWCF.Templates 1.3.0
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 6, and .NET 7. We have dropped support for .NET Core 3.1 as support has ended for that version. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0.
We now support attributing your service implementation with the ASP.NET Core [Authorize]
attribute. We support specifying the Policy, but not Roles or AuthenticationSchemes. This support is currently only for HTTP although we're investigating ways to enable it for other transports. This work was done by @g7ed6e.
If you are using the CoreWCF.ConfigurationManager package for config file support, we now have support for configuring WebHttpBinding. Thanks to @jvnvenu for adding this support.
When using the CoreWCF template to create a new project, you will now have the option to add docker support. Thanks to @g7ed6e for adding this option.
ServiceAuthenticationManager
and ServiceAuthorizationManager
API modernizationThese two classes now have async versions of the virtual methods which you can override. The existing synchronous method have been deprecated using the Obsolete
attribute and will cause a build warning. If you are overriding one of the existing synchronous virtual methods, your code will continue to function the same as it always has and will continue to do so for all future 1.x releases. The synchronous variations of the methods will likely be removed in a future 2.x release. You can safely suppress the build warning until you have migrated your implementation to the async methods. Thanks to @g7ed6e for making these async as this has long been a source of problems for developers using WCF on .NET Framework.
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/946 for your questions and comments.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.2.0...v1.3.0
Published by mconnew almost 2 years ago
CoreWCF.Primitives 1.1.1
CoreWCF.Http 1.1.1
CoreWCF.NetTcp 1.1.1
CoreWCF.WebHttp 1.1.1
CoreWCF.ConfigurationManager 1.1.1
CoreWCF.Templates 1.1.1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET Core 3.1, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.1.0...v1.1.1
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/735 for your questions and comments.
Published by mconnew almost 2 years ago
CoreWCF.Primitives 1.2.1
CoreWCF.Http 1.2.1
CoreWCF.NetTcp 1.2.1
CoreWCF.WebHttp 1.2.1
CoreWCF.ConfigurationManager 1.2.1
CoreWCF.Templates 1.2.1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET Core 3.1, .NET 6, and .NET 7. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 7.0.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.2.0...v1.2.1
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/842 for your questions and comments.
Published by mconnew about 2 years ago
CoreWCF.Primitives 1.2.0
CoreWCF.Http 1.2.0
CoreWCF.NetTcp 1.2.0
CoreWCF.WebHttp 1.2.0
CoreWCF.ConfigurationManager 1.2.0
CoreWCF.Templates 1.2.0
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET Core 3.1, and .NET 6. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 6.0.
When running on .NET Framework, if you have a contract using WebHttp attributes from the System.ServiceModel namespace such as WebInvokeAttribute
, CoreWCF now recognizes them. You don't need to modify your code to use the CoreWCF equivalent attributes. When the WCF Core Client implements WebHttp at some future time, you will also be able to use the client packages to reference these attributes in a similar way. This was implemented by @arontsang in #752
If you have multiple services and modify the underlying ServiceHostBase
using the ConfigureServiceHostBase<TService>
extension method, it is now possible to provide a single delegate to configure each ServiceHostBase
using the new extension method ConfigureAllServiceHostBase
. The provided delegate will get called once for each service type. This was implemented by @g7ed6e in #815.
Previously you could add the service behavior UseRequestHeadersForMetadataAddressBehavior
to tell CoreWCF to use the hostname and port from the incoming GET request for the WSDL to populate the server address in the returned WSDL document. This has some limitations as it doesn't modify the path or the scheme. Scenarios where this can be important are when using SSL offloading behind a reverse proxy/load balancer, or when using some url rewriting where the requested path is different than the locally hosted path. We have a new service behavior and interface which enables further customization of the URL. You can provide an implementation of CoreWCF.Description.IMetadataEndpointAddressProvider
to the service behavior CoreWCF.Description.MetadataEndpointAddressServiceBehavior
which will be called when a request for a WSDL is made. The method Uri GetEndpointAddress(HttpRequest httpRequest)
is called, passing the HttpRequest for the WSDL request which can be examined as part of the calculation for the Uri which is returned. This enables scenarios such as returning a different address for internal clients and external clients or returning an HTTPS Uri when behind an SSL offloading load balancer. This was implemented by @g7ed6e in #822
TransferMode.Streamed
by @mconnew in #806KeyValuePair<TKey, TValue>
outside of a dictionary, and types returning their own schema definitions by @mconnew in #812 and #819MessageContract
attributes being applied to a base class by @lukak-msft in #825Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.1.0...v1.2.0
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/842 for your questions and comments.
Published by mconnew over 2 years ago
CoreWCF.Primitives 1.1.0
CoreWCF.Http 1.1.0
CoreWCF.NetTcp 1.1.0
CoreWCF.WebHttp 1.1.0
CoreWCF.ConfigurationManager 1.1.0
CoreWCF.Templates 1.1.0
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET Core 3.1, and .NET 6. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 6.0.
This was implemented by @g7ed6e in #590. You can install the templates by running dotnet new --install CoreWCF.Templates
.
This was implemented by @jonlouie in #647. CoreWCF now requires the incoming HttpContext to have completed authentication using the scheme configured on the binding, and if it hasn't, send an authentication challenge to the client. The relevant authentication handler will need to be registered with ASP.NET Core in application code, but you will no longer need to enforce the authentication via middleware which executes before CoreWCF. When running on Windows and using Windows authentication, this will now enable impersonation. The ServiceSecurityContext will now be populated with the relevant infromation from the authentication.
This was implemented by @JonathanHopeDMRC in #665. There are three new properties on the OpenApiPropertyAttribute
attribute. These are MinLength
, MaxLength
, and Format
and directly map to the corresponding fields in the generated Swagger file. The class OpenApiOptions
has the new property TagsSorter
which enables providing an IComparer<OpenApiTag>
to sort the tags as they will appear in the generated Swagger file.
This was done by @petarpetrovt in #718 and enables more easily examining the claim set for a client provided certificate via the ServiceSecurityContext.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.0.2..v1.1.0
Your feedback is important and appreciated. Please use the discussion https://github.com/CoreWCF/CoreWCF/discussions/735 for your questions and comments.
Published by mconnew over 2 years ago
CoreWCF.Primitives 1.0.2
CoreWCF.Http 1.0.2
CoreWCF.NetTcp 1.0.2
CoreWCF.WebHttp 1.0.2
CoreWCF.ConfigurationManager 1.0.2
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET Core 3.1, and .NET 6. Support for .NET 5 ended as of May 10 2022. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 6.0.
None
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.0.1...v1.0.2
Your feedback is important and appreciated. Please use the discussion item for the v1.0 release at https://github.com/CoreWCF/CoreWCF/discussions/631 for your questions and comments.
Published by mconnew over 2 years ago
CoreWCF.Primitives 1.0.1
CoreWCF.Http 1.0.1
CoreWCF.NetTcp 1.0.1
CoreWCF.WebHttp 1.0.1
CoreWCF.ConfigurationManager 1.0.1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET Core 3.1, .NET 5, and .NET 6. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 6.0.
None
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.0.0...v1.0.1
Your feedback is important and appreciated. Please use the discussion item for the v1.0 release at https://github.com/CoreWCF/CoreWCF/discussions/631 for your questions and comments.
Published by mconnew over 2 years ago
CoreWCF.Primitives 1.0.0
CoreWCF.Http 1.0.0
CoreWCF.NetTcp 1.0.0
CoreWCF.WebHttp 1.0.0
CoreWCF.ConfigurationManager 1.0.0
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET Core 3.1, .NET 5, and .NET 6. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 6.0.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.0.0-preview2...v1.0.0
Your feedback is important and appreciated. We've created a discussion item at https://github.com/CoreWCF/CoreWCF/discussions/631 for your questions and comments.
Published by mconnew over 2 years ago
CoreWCF.Primitives 1.0.0-preview2
CoreWCF.Http 1.0.0-preview2
CoreWCF.NetTcp 1.0.0-preview2
CoreWCF.WebHttp 1.0.0-preview2
CoreWCF.ConfigurationManager 1.0.0-preview2
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. The GA release will occur after the support end date for .NET Framework 4.6.1 (April 26 2022) so this release will support .NET Framework 4.6.2 and above and .NET Core 3.1 and above. It is built on top of ASP.NET Core, and has been tested and runs on all currently supported versions of ASP.NET Core up to 6.0.
No new features in this release
Enum data types aren't correctly populated in the OpenAPI schema. The fix for this will be in the final release build.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v1.0.0-preview1...v1.0.0-preview2
Your feedback is important and appreciated. We've created a discussion item at https://github.com/CoreWCF/CoreWCF/discussions/613 for your questions and comments.
Published by mconnew over 2 years ago
CoreWCF.Primitives 1.0.0-preview1
CoreWCF.Http 1.0.0-preview1
CoreWCF.NetTcp 1.0.0-preview1
CoreWCF.WebHttp 1.0.0-preview1
CoreWCF.ConfigurationManager 1.0.0-preview1
This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. The GA release will occur after the support end date for .NET Framework 4.6.1 (April 26 2022) so this release will support .NET Framework 4.6.2 and above and .NET Core 3.1 and above. It is built on top of ASP.NET Core, and has been tested and runs on all currently supported versions of ASP.NET Core up to 6.0.
WebSocketTransportSettings
not being applied when using HTTPS (#568) - @mconnewWhen enabling WSDL support, if you have two types in your contract which are semantically the same, creation of the WSDL document will fail. For example, if you use List<string>
in one DataContract, and IEnumerable<string>
in another, they should be represented identically in the WSDL data schema. There is a bug in .NET where these are seen as different incompatible data types which are using the same schema definition and WSDL generation will fail. This will be fixed in the next preview release.
Full Changelog: https://github.com/CoreWCF/CoreWCF/compare/v0.4.0...v1.0.0-preview1
Your feedback is important and appreciated. We've created a discussion item at https://github.com/CoreWCF/CoreWCF/discussions/587 for your questions and comments.
Published by mconnew almost 3 years ago
CoreWCF.Primitives 0.4.0
CoreWCF.Http 0.4.0
CoreWCF.NetTcp 0.4.0
CoreWCF.ConfigurationManager 0.4.0
Starting with 0.5.0, we have enabled tests to run for .NET 6. This means CoreWCF now supports .NET Core 3.1, .NET 5.0, .NET 6.0 and .NET Framework. We have dropped testing for .NET Core 2.1 as it is out of support. We still run tests against ASP.NET Core 2.1 as that is what runs on .NET Framework.
Your feedback is important and appreciated. We've created a discussion item at #520 for your questions and comments.