System.TimeoutException

I'm thinking that the TransactionAbortedException is actually a timeout. If so you should find that the InnerException of the TransactionAbortedException is a timeout.

You should be able to get rid of it by making sure that the timeout of the transactionscope is longer than the command timeout.

Try changing the transaction scope to something like this:

new TransactionScope(TransactionScopeOption.Required, TimeSpan.FromSeconds(60))

And also set an explicit timeout on your context. Should be something like:

myContext.CommandTimeout = 30; //This is seconds

In case it helps anyone we were seeing these timeouts on long running (over 5 minute) operations. Following Suchi's hint about the FabricTransportServiceRemotingProviderAttribute we added the following lines to our SF projects AssemblyInfo.cs to increase the timeout to 1 hour.

[assembly: FabricTransportServiceRemotingProvider(OperationTimeoutInSeconds = 3600)]
[assembly: FabricTransportActorRemotingProvider(OperationTimeoutInSeconds = 3600)]

(Also note if you're using Azure Service Buses the maximum lock time is 5 minutes, so you'll have to implement some lock renewal code to support long running operations)

Assuming this is not a hardware/long cable issue, you might be able do something in your code to handle the error:

You need to create a "right" error handler as much as you create getRightPort:

SerialPort sp = getRightPort();

Assuming there is a Collection of serial port items inside and you return the right one, in the case of this SerialPort has error, make sure you re-create the error SerialPort object with the same settings:

catch (Exception err)
{
   Console.WriteLine("ERROR Modbus Message to serial port ModBus: " + err);
   FM.writeErrorLog(DateTime.Now + " - " + "ERROR Modbus Message to serial port ModBus: " + err);
   reinitRightPort(sp); //add this
}

And the method reinitRightPort(); may look similar to how you first initiate, with small differences like:

1. You do not need to add this in the List<SerialPort> anymore
2. You do not to declare SerialPort in the method, you get it from the input argument.
3. It may be best to introduce some input check validity to avoid later known errors
4. Perhaps you may close the previous connection, just to make sure that the port can be used by the new SerialPort object.

Something like this:

private void reinitRightPort(SerialPort sp){ //get SerialPort from outside of method
    //Add whatever necessary here, to close all the current connections
    //Plus all the error handlings
    if (sp == null) //Read 3.
        return;
    sp.Close(); //Read 4. close the current connections

    //get the right modbus data structure element
    ModBus MB = (ModBus)s[0].sensorData;

    //set up the serial port regarding the data structure's data
    sp = new SerialPort(); //Read 2. sp is from outside the method, but use new keyword still
    sp.PortName = MB.portName;
    sp.BaudRate = Convert.ToInt32(MB.baudRate);
    sp.DataBits = MB.dataBits;
    sp.Parity = MB.parity;
    sp.StopBits = MB.stopBits;
    //Set time outs 20 sec for now
    sp.ReadTimeout = 20000;
    sp.WriteTimeout = 20000;

    //portList.Add(sp); Read 1. no need to add this! It is already there!
    sp.Open();
}

Note: after you do that and make sure that your port is working well, whenever possible, you could also combine the reinitRightPort method above with your real initialization with some little modifications. But the first thing you may want to do is to get the your serial port works under error.

But if the error source comes from hardware/long cable issue (such as cable placing in the RS232 or RS485, or voltage drop due to long cable, or incompatible hardware: that is, in short, nothing to do with coding at all), then, unfortunately the solution cannot come from code as well. You got to find the real hardware issue.

According to the attached Rider and dotnet logs, this problem is not related to Rider IDE.

There appears to be some first-time experience feature of dotnet that requires an access to dotnet/sdk/NuGetFallbackFolder which is not given so you get an error in the logs but that is probably not the real root case.

The issue is somewhere in your network between your computer and NuGet server as per the log message The download of 'https://api.nuget.org/v3-flatcontainer/microsoft.win32.registry/4.4.0/microsoft.win32.registry.4.4.0.nupkg' timed out because no data was received for 60000ms.

You should probably check your network and dotnet/NuGet settings.