I'm maintaining a legacy product that is deployed to SharePoint 2010, and targets .Net framework 3.5. It uses the Azure SDK 1.7 for blob operations and with the SDK getting deprecated soon, we need to upgrade it. According to this blog post the minimum SDK version should be 2.1, but the issue is that the it does not support .net 3.5.
I looked at the SDK code on GitHub and it's highly dependent on .Net 4 features so I cannot recompile it in .net 3.5. I looked for 3rd party SDKs but couldn't find any.
Is there a straightforward way to keep the functionality after Azure Storage service version removal?
(Please note that upgrading the .Net framework is not an option for me.)
No, unfortunately our client library support is only for .NET 4.0 (2010) and later.
If you need to maintain support for the legacy project, you'll need to decide between writing your own REST calls to Azure Storage or upgrading your .NET framework to 4.0 to use a newer version of the library. Sorry!
For anyone who might have the same problem:
The deprecation of Storage client library 1.7 is postponed beyond August 2016.
Microsoft Azure Storage Service Version Removal Update: Extension to 2016
Related
I have a website that was developed a few years ago with the 4.5.2 framework and VS2015. Following two changes of technos integrated on the project (PDF generation and mail sending) I had to change the version of the framework to 4.6.1. This change is mainly due to the mail sending system, we use SenInBlue which has just migrated its APIs to a V3 version and to be able to use the latest version we must use VS2017. When I work locally I have no problem, however when I deploy my site via VS2017 then some APIs become inaccessible and return an error 500. If I redo a delivery with VS2015 I don't have any problem with the APIs but I can't use the APIs for sending emails which are not supported by VS2015.
Below is the content of my WebApiConfig.cs file and one of the APIs that is inaccessible after deployment via VS2017
WebApiConfig.cs
Api
Thanks
There's no information in the question itself, not even the logged exception, so one can only make some wild guesses, based on versions, dates and a common problem 6 years ago
The Visual Studio version doesn't matter, it's only the editor. The code runs on the .NET Framework runtime. .NET Framework 4.5.2 went out of support a long time ago. .NET Framework 4.6.1 also went out of support this year, simply because no supported Windows version required it. All supported Windows versions, including Windows Server versions, come with 4.6.2 at least. In fact, I think the minimum is now 4.8.
Since this is a networking problem with a new service version, I'd suspect the SendInBlue service discontinued the use of insecure SSLv3 and TLS 1.x, years after other services did.
To fix this, change the project's target to 4.6.2 (although 4.8 would be better) and make sure the relevant .NET Framework Runtime version is installed. Preferably 4.8. This version is 3 years old already and contains fixes for the bugs found in previous versions. By now it's pretty stable.
In June 2015 SSL v3 was deprecated because it was too easy to crack. By 2016 major services required TLS 1.2, with Google, Azure, Amazon etc requiring it soon after. PCI-DSS made this a requirement later than others, but right now, there shouldn't be any site or service requiring anything less than TLS 1.2.
For this reason, .NET Framework 4.6 and later disabled SSL v3. They didn't start using TLS 1.2 automatically until 4.6.2 though. Since 4.6.2, the best available protocol supported by the OS will be used. If the OS supports TLS 1.3 (Windows 11 does), then TLS 1.3 will be used.
.NET Framework 4.x versions are binary replacements, which means installing a newer version replaces older ones. Since .NET Framework Runtime is updated through Windows Update, it's likely servers already run the latest runtime.
My team has written maintains a library that wraps functionality around a full framework .net .dll, specifically the IBM FileNet.Api.dll. We have been transitioning our library to use .net Standard and so far, all is well. After creating a .net core app and attempting to connect to FileNet, we run into a web service runtime problem.
Here is the error that is thrown:
The operation cannot be completed because a supported web service
runtime is not present. Either Microsoft Web Services Extensions (WSE)
3.0 or the Windows Communication Foundation (WCF) is required.
Does anyone know of a NuGet package that provides this runtime for .net Core or a workaround for this issue?
Updade:
I have now had several conversations with the engineer team at IBM and they do not support .NET Core, nor do they plan on supporting it at this time. What I am doing is to create a .NET Framework 4.x API to basically convert to and from FileNet. It's a bit janky but when the customer wants their API in .NET Core I'm having to build something to make it work.
I'm running into the same issue. From what I've discovered System.Web.Services which is used by the FileNet.Api.dll and IBM's CEWSI for creating SOAP connections has been deprecated after .NET Framework 4.x in favor of WCF and is not available in .NET Core, .NET Standard, nor .NET 5.
It also appears that Microsoft is pushing developers to use REST instead of SOAP. I have not found anything from IBM to replace the DLL or CEWSI.
Sorry this isn't more useful, I'm still trying to figure out how to use .NET Core with it as well and short of basically recreating the functionality myself I haven't found a viable solution.
I need to install on a Windows Server 2012 the .NET Core Runtime for a webapp written with version 1.1. Can I install the .NET Core Runtime 2.0?
I didn't find a clear answer at my question.
Here someone raised a similar question
https://github.com/dotnet/docs/issues/4241
and here the official .NET Core guidance about runtime versioning
https://learn.microsoft.com/en-us/dotnet/core/versions/
According to the documentation, .NET Core versions can be installed side by side:
While there is a single host, most of the other components are in versioned directories (2,3,5,6). These means multiple versions can be present on the system since they are installed side-by-side.
Does anyone know if .NET Standard 2.0.0 is supported on Mono? I currently have a build that is working fine on windows 10. When I attempt to use in Mono in a Ubuntu Linux environment I get the following error:
Could not locate the assembly 'netstandard'. Check to make sure the assembly exists on disk.
Dotnet core 2 is added with no problems via the SDK, but I seem to not have any references to .NET Standard 2. I had a similar problem on windows 10 originally, which was resolved after I updated my version of visual studio.
Consult the release notes for details, but Mono 5.4.0 includes NuGet 4.3.0 and MSBuild 15.4.
Mono 4.8.0 Preliminary support
API additions for .NET Standard 2.0
We added APIs to comply with .NET Standard 2.0, which is still a work in progress at the time of this writing. Note that in some cases an implementation is still missing and will throw at runtime.
Mono 5.2.0 Runtime support (compiling is in "Preview Status")
.NET Standard 2.0 groundwork
We’ve done all the groundwork to support libraries that conform to .NET Standard 2.0. Loading and running a library compiled against the 2.0 standard should work fine, tooling support (i.e. creating a .NET Standard 2.0 library) is still in preview though.
.NET Core 2.0 SDK Installation needed
You’ll need to install the .NET Core 2.0 SDK for tooling support as we use the MSBuild tasks which are installed as part of the .NET Core 2.0 SDK, similar to how Visual Studio/MSBuild on Windows does it.
Is .NET 4.5 mandatory for using Windows API Code Pack (Microsoft.WindowsAPICodePack and Microsoft.WindowsAPICodePack.Sensors.dll)
Will it work for .NET 4.0?
The latest version of Windows API Code Pack is 1.1 but there doesn't seems to be a dedicated page for it.
The library was published when Windows 7 was released (replacing the "Vista Bridge" library), and targets the .NET Framework version that is pre-installed on Win7, version 3.5. You cannot go lower than 3.5, it has a dependency on System.Core.dll. Targeting .NET 4.x is not a known problem.
Do keep the target operating system requirement in mind for the Sensor api, the underlying COM interface (ISensor et al) requires Windows 7 or higher and is not available on the Server edition.
The actual code of the Windows API Code Pack is compatible with .NET 3.5 and above. .NET 4 or 4.5 certainly won't be a problem.
I just downloaded the NuGet package using Install-Package WindowsAPICodePack-Core and it works for .NET 3.5.