Asking here to see whether .NET Framework 4.8 really needed for TLS 1.3 as the documentation is creating confusion. My existing app using .NET 4.7.1.
I had the same question and the community provided some answers:
https://github.com/dotnet/docs/issues/4675#issuecomment-1233647865
One such answer:
There is more than just the enum. to get TLS 1.3 callers of schannel need to call different API. If the "normal"/"legacy" API is used schannel will negotiate only up to 1.2.
The only one way you can succeed while targeting 4.7 is to use actual 4.8 runtime on the new machines. 4.7 does not have the enum, but the None should still work. - wfurt Tomas Weinfurt
Note: I will update this answer if I have any further findings.
Related
I am using NServiceBus as middelware for an asp.net core 3.0 API. I already configured the service in my API using NServiceBus version 7.2 because the documentation for that on the website of particular is amazing. Saddly I have a probleem because i got a licence for an older version of NServiceBus versions until version 7.1.x are valid.
my question is: is there a recomendition for configuring NServiceBus in asp.net core using Versions 7.1.x?
One option is to use an external container and configure the endpoint to use it. Take a look at the sample available in the README of the MSDependencyInjection container.
The same thing can be achieved, with very similar code using one of the supported IoC container: https://docs.particular.net/nservicebus/dependency-injection/#internally-managed-mode-using-a-third-party-container
I need to connect a WinCE6.0 device to a web based server using HTTPS.
The problem: WinCE6.0 uses WinInet v6 which supports SSL2, SSL3 and TSL1.0 None of which are supported in the current (2018) best practices due to their security flaws.
I doubt I can drop in a newer version of WinInet and expect it to run.
I had thoughts of porting CURL to WinCE.
I'm thinking this issue has already been addressed by the CE community, but I'm not seeing an available solution.
How can I get an old embedded device to securely connect to the WWW?
From GuruCE:
If you want to use TLS 1.1 and 1.2 on CE a suitable solution is to use mbedTLS library from ARM. It has a BSD-like license, so not too restrictive. Only one change to the makefiles is needed to get it to work on CE.
I read some article about NServiceBus and i want use it, but i dont know it fully supported the .NetCore or not, i googled about it (and found some information like This), but it could not help me much, any one can help me?
UPDATE: Starting from NServiceBus 7.0.1 they introduce support on .NET Standard 2.0 and thus can run on .NET Core 2.1+.
Building endpoints with .NET Core 3.1 explains how to configure it on .NET Core 3.1 and generic host.
Original answer:
NServiceBus package has no dependency on any NetStandard so it means it cannot run on Core CLR. You can use it in .NET Core projects only if you target Full .NET Framework, not .NET Core.
As of 24 April 2017 NServiceBus does not support .net core. The most current public status is this https://particular.net/blog/nservicebus-on-net-core-why-not
However I can say that internally to Particular significant effort is being put into getting .net standard support shipped.
I will add this question to the list of follow ups for after we ship
Update: Particular Software announced upcoming support for .NET Core 2.0 on their company blog here: https://particular.net/blog/nservicebus-on-net-core-its-time
I inherited a Cast Iron appliance which reports that it is version 5.0.1.5 - several years old and off support.
This is mostly used to talk to Salesforce, who just sent us an email saying they are turning off SSL 3.0 in a few weeks. POODLE.
Can anybody tell me if this version of Cast Iron supports TLS and will continue to work when SFDC disables SSL 3.0? Or point me to something that tells me how to check this myself? I'm drawing a blank with Google..
Better upgrade fast.. this broke a client instance..
http://www-01.ibm.com/support/docview.wss?uid=swg21687945
To answer my own question: yes, old Cast Iron version 5.0.1 does support TLS 1.0.
Salesforce shut SSL 3.0 off this past weekend on all their sandbox instances and our CI integrations are still happy.
Castiron version below 6.1.0.12 do not support TLS. Once salesforce switched off ssl in sandboxes our orchs (all 150) of them would not connect to salesforce.
We are upgrading to version 7.
I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!
Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.
So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).
What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?
Thanks a lot!
The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:
Create a .NET 4.0 class library.
Add a Service Reference to your WCF service.
Create classes and interfaces which can be used to call the WCF service.
Expose them as COM classes and interfaces
Have your .NET 1.1 code consume the COM object and make calls through it
Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".
Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.
Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.
Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.
Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.