Missing [AllowPartiallyTrustedCallers] in 3.1.10

[alexRambo]

A few questions/concerns/a bug?

Does version 3.1.x drop support for .Net 4.5?
Looks like the source project only has "debug" and "release" builds; as opposed to previous versions that supported net40, net45, etc.

In 3.0.x support for .net 4.0 was dropped according to the online documentation (I haven't looked at the source - see image below).

However, 3.1.x doc does not mention anything about .Net 4.5 being dropped to my understanding.
Furthermore, there is a lot of 4.6 syntax in the source project when you download it and solution fails to compile against 4.5.1.

Question: How, then, when I installed via nuget "Nuget-Install Npgsql -Version 3.1.10" does it work in a project that targets 4.5 framework??? Is there a way I can compile the source in .Net 4.5? How was the Nuget package pushed out as .Net 4.5?

Please confirm potential bug:
I have a .Net 4.5 assembly with AllowPartiallyTrustedCallersAttribute (System.Security) making a call to 3.1.10 and it is failing since apparently Npgsql assembly contains "[assembly: SecurityRules(SecurityRuleSet.Level1)]" and calling a method from my project to npgsql results in the following error: (see below)

Steps to reproduce

Create .Net 4.5 project and add nuget reference to 3.1.10.
In your project set the AssemblyInfo.cs class to "[assembly: AllowPartiallyTrustedCallers]"
Now, make a call to the Npgsql constructor 'Npgsql.NpgsqlConnection..ctor(System.String)'.

The issue

"System.MethodAccessException: Attempt by security transparent method '[myProjectMethod]' to access security critical method 'Npgsql.NpgsqlConnection..ctor(System.String)' failed.

Assembly '[myAssemblyInfo]' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception."

Further technical details

Update 1: Visual Studio version 2013.
Npgsql version: 3.1.10
PostgreSQL version: 9.4
Operating system: Windows Server 2012 R2 Standard

Thank you for any and all the help.

Partial Solution:
Looked at closed ticket and I will be trying compiling with VS2017 Community Edition as suggested (#671) in order to try and disable "SecurityRuleSet.Level1" in Npgsql.

[roji]

Npgsql hasn't dropped support for .NET 4.5, you can see this by looking at the nuget page, or by the fact that the npgsql csproj contains net45 in its <TargetFrameworks> element. There's some confusion in your issue, I'll try to explain.

First, debug and release are build configurations, not target frameworks. They simply control flags to the compiler which enable optimization, some compile-time constants, etc.

Second, there's no such thing as ".NET 4.6 syntax"; the .NET Framework is not a programming language - C# is. It's true that Npgsql makes use of C# 6 (and now even C# 7) features, but this has nothing to do with the supported target frameworks. You can use the newest C# language features but still old versions of the .NET Framework.

Regarding your specific issue, it does seem that [AllowPartiallyTrustedCallers] is missing in the published version of 3.1.10, I'm not sure how that happened... I've just checked and 3.2.1 does have it, can you use that instead?

(Leaving this issue as a reminder to check APTCA when publishing 3.1.11)

[alexRambo]

roji,

First off, thanks a lot for the great work, quick feedback, and deep understanding of the .Net Framework.
I've had the pleasure of reading a lot about ur work since 2.2.3.

Long story short=> I was able to add the AllowPartiallyTrustedCallers attribute to Npgsql assembly, compile with VS2017 targeting .Net 4.5 compile, and run the code; now I'm getting the infamous "An operation is already in progress" exception......
Note: this is with 3.1.10.

Curious side note: This is all in an attempt to upgrade from 2.2.3 (I tried to upgrade to 2.2.7 but problem persisted) in order to fix an issue (you have a closed ticket for it....) which manifested itself under 2.2.3 and 2.2.7 as a "connection failed to open because because server terminated (paraphrasing)". The code I borrowed from one of ur posts looks something like "Code 1" below. While that issue WAS solved by upgrading to 3.1.10; now I'm seeing exception "An operation is already in progress". I will enable logging as suggested on other posts and investigate.... 6 days trying to track this down :/

"Code 1"
for (int i = 0; i < 10; ++i)
{
connections[i] = new NpgsqlConnection(connectionString)
{
//UseSslStream = useSslStream
};
//connections[i] = new NpgsqlConnection(connectionString)
//{
// UseSslStream = useSslStream
//};

        connections[i].ProvideClientCertificatesCallback += ProvideClientCertificates;
        try
        {
           connections[i].Open();
           Console.WriteLine("Opened connection {0}", i);
        }
        catch (Exception ex)
        {
           if (logexceptions)
           {
              Console.WriteLine("Failed to open connection {0}... error: {1}", i, ex.ToString());
           }
           else
           {
              Console.WriteLine("Failed to open connection {0}... error: ...skipped", i);
           }
        }
     }

     foreach (NpgsqlConnection connection in connections)
     {
        connection.Close();
     }
  }

Update: The original problem originated when client wanted to update from username/password auth to using client certificate for authentication. 2.2.x has a Microsoft SChannel/SSLStream channel and problem with renegotiation and Mono support was phased out of Npgsql..... I see the route taken was creating custom SSL/TLS implementation via TlsClientStream; and this seems to fix the original SSL renegotiation exception seen with the code above.....

Critical Note: Client is using npgsql with FluentMigrator.

Regards,
alexRambo

[roji]

@alexRambo, could you please open a new issue with your problem? Try to include a complete code sample which triggers your error, it's a bit difficult to understand from your post above what trouble you're running into exactly...

Yeah, SSL/TLS was pretty messy a while ago, but nowadays using SslStream should be fine in almost all cases - I'd be interested in hearing any experience to the contrary.

[roji]

Closing for qge