Aerospike Panther for .Net 6 - c#

Binary serialisation became obsolete in .net 6 and above , i wanted to use aerospike client for cheetah and panther with a version which supports both v3.9.16. The problem is in .net 5.0 i was able to set Binary serialisation to true in csproj property and able to create a client but in .net 6 not able to do that , its throwing login failed error 93. Any idea how to solve this?
Tried .net 3.1 framework and .net5.0 with flag enabled it's working, but .net 6 with flag enabled is not working.

Related

Problem with API on framework 4.6.1 and deploy with VS2017

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.

Developing the same .NET Core source code as both .NET Core 1 and .NET Core 3

I've run into a rather interesting problem at work. We have a .NET Core application that we need to develop. Because it's spent so long in development, it's all written in .NET Core version 1.
Now we add support for Microsoft OpenID to it. The thing is, Microsoft OpenID doesn't work with .NET Core version 1, it needs .NET Core version 3.
At the same time, customers are expecting steady deliveries, so we can't risk breaking the old .NET Core version 1 application until we have a fully working version of it written in .NET Core version 3.
So what I did was to make a different project in the same source code folder, using .NET Core version 3, and add the exact same source code files to it. Not duplicates - the exact same files. I just needed to add a bunch of #if - #endif directives to get around differences between versions 1 and 3.
But then there's the thing that the .NET Core version 1 application needs a global.json file containing "version": "1.0.0-preview2-003121" in the "sdk" section, otherwise Visual Studio will try to compile it in .NET Core version 3, which will fail. This, however, will break the new version, which needs to use sdk version "3.1.300".
So in effect I would need to have two different "version" lines in the same "sdk" section in the same global.json file, with some kind of #if - #endif directive for conditional compilation. But I don't think global.json supports that.
How can I resolve this problem? Or is there any better way I haven't thought of?

linq2db 3.0.0-preview.1 not working with .net core 3

linq2db 3.0.0-preview.1 isn't working with .net core 3, showing error:
System.ArgumentException: 'UdtTypeName' is not a member of type System.Data.SqlClient.SqlParameter' (Parameter 'propertyOrFieldName')
While the same thing works great on .net core 2.2
since the exact same code works in .net core 2.2, the question arises whether it currently works with .net core 3 or will have to wait a while. Regarding the possibility of linq2db working with .net core 3, I really did not find any information, which oddly enough, is unusual.
On github there is a closed problem with a similar error, but it seems that the problem is fixed, and in the code I do not use UdtType, and the error crashes with any action with the database context, even with a simple fetch
Is it possible to somehow make this work or will I have to wait for a new version of linq2db?
Could it be that you use System.Data.SqlClient < 4.5.0 as this property was added to SqlParameter in this version?
Update: as quick fix you can update dependency to 4.5.0 or higher, but it looks like you've hit preview1 issue

Is there a way to add and start a .Net Core 2.0 REST server inside a .Net Framework 4.5.2 (or .Net Framework 4.6.1 or .Net Standard 2.0) application?

Issue
Hi,
I am currently working on implementing a RESTful API in C# using ASP.net Core 2.0 in Visual Studio 2017 (running only via Kestrel, therefore no IIS).
Everything works pretty well, no issues there. The thing is that I now need to integrate and start this REST Server in another project (The REST server being only one of many functionalities that need to be executed at the same time, using a "bootstrap"). My issue here is that the latter project targets .Net Framework 4.5.2 whereas the REST server targets .Net Core 2.0. Thus, when I add the REST server to the references of my bootstrap application, I encounter a couple of errors saying that some of the Nuget packages target the wrong framework.
Solutions I tried
I searched over Google but most of the issues I found were people trying to do the other way round, i.e. adding a .Net Framework-targeted project in a .Net Core application.
The way I understood this .Net implementation support table, is that a .Net standard 2.0 project can support a .Net Core 2.0 project (I am probably wrong).
I tried a couple of things to make it work (which, spoiler alert, obviously and unfortunately did not work as I wouldn't be asking your help) :
Made the boostrap application target .Net Standard 2.0
Made the boostrap application target .Net Framework 4.6.1
Made the REST server application target .Net Standard 2.0 (which it of course didn't work, but I was kind of desperate..)
I made these target change by modifying the .csproj files.
I don't have the exact error codes because I reverted my changes a while back but they all were about projects not targeting the same framework.
So, in a tl;dr manner, what I am asking is :
Is there a way to add a .net Core 2.0 REST server inside a .Net Framework 4.5.2 (or 4.6.1 and higher/ or .Net Standard 2.0) project to start the server inside the application ?
Apologies for any english mistake as it is not my native language.
Don't hesitate to ask more info on my problem if I wasn't clear enough and thanks for the help !

Do .NET 2.0 API Calls Work on .NET 4.0 Runtime by Default, or Do They Require Extra Setup Steps?

If the C# frontend team on my project makes a standalone program that only does .NET 2.0 API calls, but install on to a computer with .NET 4.0, will it work by default or must they do something to the setup or to the setup-building process (like check off certain checkboxes) to make it work?
See, I'm assuming that if I make .NET 2.0 API calls only, that it should just "work" on .NET 4.0.
Part 2 on this is -- user has .NET 4.0 and .NET 1.1, but not .NET 2.0. I assume .NET 2.0 should work, then, because it has .NET 4.0. Right?
Background -- I'm a Linux/PHP dev and haven't touched C# since 2001. My skills are stale. The client's C# frontend team on my project need some assistance on understanding compatibilities, I guess, and so I've been asked by my client to ask this question.
.NET 2.0 should work if you have .NET 4.0 installed on your computer. I got this from this link: Version Compatibility in the .NET Framework. Keep in mind though, that some objects have changed from 2.0 and 4.0. They might not have all the same properties and methods. It is always a good thing to refer to the MSDN documentation.
Edit new link: Another good reference about the element in the web.config/app.config file of your project: supportedRuntime

Categories