In Wikipedia a number of WS-I Basic Profile (BP) compliant frameworks are listed. However, it is not clear to which version of the BP the framework is compliant to. So my question is as follows:
Which frameworks/products (Java, .NET and others) are compliant to WS-I Basic Profile 2.0?
The answer of this question may be of interest in the selection of an enterprise web service standard. It seems as if most frameworks are compliant to BP 1.1, but the question is whether the IT environments are ready to be upgraded to BP 2.0 (including MTOM binary attachments, WS-Addressing, SOAP 1.2 and UDDI 3.
Studying one example framework, the IBM WebSphere Message Broker (WMB), more closely I found the following information:
the platform supports WS-I Basic Profile Version 1.1
the platform supports e.g. WS-Addressing and SOAP 1.2
by using the HTTP proxy servlet pattern you indirectly get the same support as given by the Java EE application server
However, I did not find any explicit statement detailing that the product supports WS-I Basic Profile Version 2.0. The same seems to be the case for many frameworks...
Related
Is it safe to have a .NET6 application which references a .NET Core 3.1 NuGet library?
I tested this case using a simple console application. Everything looks good and there are no errors/warning. However, I haven't found any specific information so prefer to make sure.
This is important, as one of my providers offers only a .NET Core 3.1 NuGet package. Knowing the company it'll take them a year or so to prepare a .NET6 / .NETStandard version.
There is a good chance that your .NET Core 3.1 library will run without any compatibility problems as part of your .NET 6 application.
Quoting the .NET fundamentals article Changes that affect compatibility (emphasis mine):
Throughout its history, .NET has attempted to maintain a high level of
compatibility from version to version and across implementations of
.NET. …
Along with compatibility across .NET implementations, developers
expect a high level of compatibility across versions of a given
implementation of .NET. In particular, code written for an earlier
version of .NET Core should run seamlessly on .NET 5 or a later
version. In fact, many developers expect that the new APIs found in
newly released versions of .NET should also be compatible with the
pre-release versions in which those APIs were introduced.
However, compatibility is not guaranteed. The article goes on to say:
This article outlines changes that affect compatibility and the
way in which the .NET team evaluates each type of change.
Understanding how the .NET team approaches possible breaking
changes is particularly helpful for developers who open pull
requests that modify the behavior of existing .NET APIs.
Furthermore, in an answer to the question Clarification on backwards compatibility of .NET Core, a member of the .NET runtime team says:
We do not guarantee 100% compatibility between major versions. This is true for both ASP.NET Core and the runtime itself. We
intentionally make breaking changes where we believe that they are
necessary to move the platform forward and the cost of the .NET
ecosystem adjusting to them is low enough.
Breaking changes that could potentially affect the compatibility of your .NET Core 3.1 library are those that are documented for .NET 5 and .NET 6.
But, if you are not experiencing any problems with your .NET Core 3.1 library, it would appear that none of the documented compatibility problems apply.
Ultimately, of course, you'll have a higher degree of confidence in the library when your vendor provides one that has been updated for .NET 6.
Finally, with the introduction of .NET 5, there became a lesser need for .NET Standard:
.NET Standard is a formal specification of .NET APIs that are
available on multiple .NET implementations. The motivation behind .NET
Standard was to establish greater uniformity in the .NET ecosystem.
.NET 5 and later versions adopt a different approach to establishing uniformity that eliminates the need for .NET Standard in most
scenarios. However, if you want to share code between .NET Framework
and any other .NET implementation, such as .NET Core, your library
should target .NET Standard 2.0. No new versions of .NET Standard will
be released, but .NET 5, .NET 6, and all future versions will continue
to support .NET Standard 2.1 and earlier.
I will try to keep this general, as I am seeking a general answer.
When I open the properties window of one of the references in my project in Visual Studio I see this runtime version: v4.0.30319
This reference is used in a project where the target framework is .NET Framework 4.7.1. And it works fine.
My project is communicating with a database, and I want to make sure that this communication will be utilizing the TLS version 1.2 protocol. As I understand it, this can be insured by having the project targeted against .NET 4.7 or above.
Here is my question: if I have a project with a reference, which have a target framework that is lower than .NET 4.7, will this ruin my goal of using a TLS protocol of version 1.2?
How can I make sure that my reference is up to snuff? The runtime version written above, is not suggesting that this reference has a .NET Framework of 4.7 or above, or does it?
I'm making an HTTPS call over TLS 1.2 with client certificates to another company using .Net Framework 4.8 and the handshake fails after the client certificate is sent. Their company support claims .Net framework does not support SNI using this page as reference https://www.ssls.com/knowledgebase/what-is-sni-technology/. However my network capture indicates it does, since it includes the "server_name" extension in the client hello..Net framework call with SNI extension The same call can be made successfully using python so there is evidence they are correct, but I can't find any definitive answer online regarding .Net Framework. How can we determine if the issue is their network or lack of support in our framework?
Edit: This website indicates there is support since 4.5 https://developer.awhere.com/api/server-name-indication-sni-support-requirements
.NET Framework don't care about SNI support, because .NET has no knowledge of it. Network operations in .NET Framewrok are built around a network stack and low-level API provided by operating system. If you were able to install .NET 4.8, then you are running your app on a modern client that certainly supports SNI. This means that the issue is elsewhere, but not in .NET Framework.
I can't find any definitive answer online regarding .Net Framework
and you won't find for reasons explained above.
The simple answer is no, it does NOT, not in NetStandard 2.0 either.
But it does with netcore-5+.
Prior to that, while it supported client connections, it did not support customized selecting of the TLS-certificate based on SNI prior to netcore-5.
You could do it prior to that with the StreamsExtended library, though.
However, that's not part of the official .NET Framework, but a 3rd party library.
So no, the full .NET framework does not support that at all.
MYOB has advised that as of 30th September 2018 the MYOB API will no longer accept connections using TLS1.0
I have a Winforms application which connects to MYOB Accountright via the API using the SDK
I am wondering if there are any specific changes that I need to make to an application that I released 2 years ago.
I asked on the developer forum and was told that if my code uses TLS1.0 I need to change it.
From this question about determining the dot net framework I am thinking that I need to check the framework MYOB.AccountRight.SDK.dll uses.
Looking in my project I see that it is v4.0.30319
I opened MYOB.AccountRight.SDK.dll in notepad and saw NETFramework,Version=v4.5
From Stan Tarnovskly's blog I see
.NET 4.5. TLS 1.2 is supported, but it’s not a default protocol. You
need to opt-in to use it. The following code will make TLS 1.2
default, make sure to execute it before making a connection to secured
resource: ServicePointManager.SecurityProtocol =
SecurityProtocolType.Tls12
You don't want to be using TLS 1.0 or 1.1 these days.
This doc has some best practices and also several references to the upgrade path you should be looking at: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
We recommend that you:
Target .NET Framework 4.7 or later versions on your apps.
Target .NET
Framework 4.7.1 or later versions on your WCF apps.
Do not specify
the TLS version. Configure your code to let the OS decide on the TLS
version.
Perform a thorough code audit to verify you're not
specifying a TLS or SSL version.
.NET Standard prescribes an API that all .NET Platforms must implement. What are its versioning rules? Is it breaking.adding, in which 1.4 adds to and remains backward compatible with 1.3 whereas 2.x is not backward compatible with 1.x?
The documentation is not clear on this. Some Microsoft docs indicate pure backward compatibility:
Given a .NET Standard Library version, you can use libraries that target that same or lower version. (emphasis added)
Now that 2.0 is out, the above doesn't seem correct. That being said, the release blog post said:
From a library targeting .NET Standard you’ll be able to reference [libraries targeting] .NET Standard, if their version is lower or equal to the version you’re targeting. (emphasis added)
That same blog post contradicted itself by saying:
In order to allow .NET Framework 4.6.1 to support .NET Standard 2.0, we had to remove all the APIs from .NET Standard that were introduced in .NET Standard 1.5 and 1.6.
Now that 2.0 is out, what are the versioning rules? It appears to be breaking.adding. Where has MSFT documented this?
I've explained this in a bit more detail in our On.NET episode on .NET Standard.
Generally, this is how .NET Standard works:
.NET Standard will version linearly, with the intention of not making breaking changes between versions. In other words, you can think of the API surface of .NET Standard as concentric circles, where higher versions have more APIs.
A specific version of a .NET platform will implement a specific version of .NET Standard.
When choosing a .NET Standard version to target consider this trade-off:
The higher the version number, the more APIs you can use
The lower the version number, the more .NET platforms support it
So why is there this talk about breaking changes? The short answer is because we made a mistake when defining .NET Standard 1.x and didn't take platform reach into consideration. You should ignore .NET Standard 1.5 and 1.6 and avoid taking a dependency on them. If you do that, .NET Standard 2.0 is a strict superset of .NET Standard 1.4.
For more details, read the section .NET Standard 2.0 breaking change: adding .NET Framework 4.6.1 compatibility in my blog post on .NET Standard.
Update. After a lot of community feedback we decided not to perform this breaking change. More details around this decision is listed in the .NET Standard FAQ.