PSU 3.3.0 Nightly: Invoke-DbaQuery not working anymore

PowerShell Universal
1

Dear All

I’m playing around with the new DataGrid.
Coming from 3.2.8 and using the example in the docs to get started.
Everything worked fine initialy by just doing some standard “select * from…”

Since I’ve seen that a lot of related changes and enhancements are coming to version 3.3.0 I decided to upgrade to the latest nightly.

Unfortunately I’m not able to connect to the DB anymore.

The error that comes is:

[09:24:52][Invoke-DbaQuery] Failure | Method not found: 'Void Microsoft.Data.SqlClient.SqlConnectionStringBuilder.set_Encrypt(Boolean)'.

So it seems that the 3.3.0 has changed the way a SQL connection is performed using dbatools.
But I wasn’t able to find the issue… :frowning:

Anyone that has encountered the same issue and may can help?

Thanks a lot to all of you!

Best regards,
Don

EDIT:
This is the example I’m using:

2

I am seeing the same issue on 3.3.3.

3

I updated to 3.3.3 on my dev instance and have the same error.

4

I opened an issue for this. It seems like an assembly conflict. What version of dbatools are y’all using?

5

I tried it with 1.1.128 and 1.1.133

6

Hi everybody!

“Good” to see that other are experiencing the same issue. This means that there is definitely something in 3.3.x that changed I think…
I’ve tried with 1.1.129…

Thanks Adam!

KR
Don

7

I am using dbatools 1.1.32.

I have found a couple of articles that look related. I can’t figure out how to build a connection string and pass that to invoke-dbaquery to test out what the links are suggesting. I use the MS SqlServer module in most of my tooling outside of Universal, I do not remember having an issue with it when connecting to the SQL server in my case. I will have to see if it has an issue if I use it within the dashboard.

8

I can reproduce this when using the integrated environment. The issue is that PowerShell Universal uses version 5.0 of the Microsoft.Data.SqlClient.dll. dbatools is using an older version of this DLL which is what is causing this issue.

When I run this outside of the integrated environment, I’m not seeing this issue. Can anyone else verify?

Assembly binding issues like this are one of the reasons we suggest favoring non-integrated environments: https://docs.powershelluniversal.com/config/best-practices#favor-non-integrated-environments

9

Can confirm, switching to pwsh 7.2.6 and it worked again.
I didn’t know about favoring non-integrated environments, i hope it is not much slower. First tests looked like there is no big difference

10

Switching to PWSH did resolve for me as well.

My environment was set to ‘Default’. Is there a setting I have set somewhere that is associating Default to Integrated?

11

You’ll find that on the Settings \ General \ Environments page.

image
image1876×688 29.4 KB

12

Typically, the slowest part of the system is the actual PowerShell execution so we typically don’t see issues with serialization slowing things down at all. We use protobuf and gRPC so it has really good throughput.