Unable to load adalsql.dll error when calling `Invoke-sqlcmd` - sql-server

I have VS2015 with SSDT installed, along with SSMS and the SqlServer PowerShell module (which includes the invoke-sqlcmd comand), and yet If I try to execute a query against an Azure SQL Data Warehouse like so:
invoke-sqlcmd -Query "Select top 5 * from customer" -ConnectionString "Server=tcp:my.database.windows.net,1433;Database=Customer; Authentication=Active Directory Integrated; Encrypt=True; "
I get the following error:
invoke-sqlcmd : Unable to load adalsql.dll (Authentication=ActiveDirectoryIntegrated). Error code: 0x2. For more information, see
http://go.microsoft.com/fwlink/?LinkID=513072
At line:1 char:1
+ invoke-sqlcmd -Query "Select top 5 * from vwOffer" -ConnectionStrin ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Invoke-Sqlcmd], SqlException
+ FullyQualifiedErrorId : SqlExectionError,Microsoft.SqlServer.Management.PowerShell.GetScriptCommand
invoke-sqlcmd :
At line:1 char:1
+ invoke-sqlcmd -Query "Select top 5 * from vwOffer" -ConnectionStrin ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ParserError: (:) [Invoke-Sqlcmd], ParserException
+ FullyQualifiedErrorId : ExecutionFailureException,Microsoft.SqlServer.Management.PowerShell.GetScriptComman
If I try and install adalsql.dll directly, I get a message stating that A higher version already exists and I can see the both versions of the dll can be found here:
C:\Windows\SysWOW64\adalsql.dll
C:\Windows\System32\adalsql.dll
and yet, invoke-sqlcmd cant find it. Any idea how to either (A) register the existing dll so invoke-sqlcmd can find it or (B) uninstall it so that it can be re-installed?
Incidentally, I am able to use Active Directory Authenticatoin with the 32-bit SQLCMD.exe, so I know the 32 bit dll is working fine. It's just the 64 bit dll that isn't loading properly...

So, this problem vexed me as well. I'm unclear as to how it happened, but maybe it's just coincidence that it happened when I installed the latest version of SSMS. My fix was to:
Navigate to Add or Remove Programs
In the little search window type sql, or just go find: "Active Directory Authentication Library for SQL Server".
Note: This will not be in Windows' installed programs list if you have installed Visual Studio 2019. You can run the same installer by invoking MsiExec.exe /I{6BF11ECE-3CE8-4FBA-991A-1F55AA6BE5BF} from a command prompt.
Uninstall that little guy
Navigate here and download the latest ADAL library (pick x64):
https://www.microsoft.com/en-us/download/confirmation.aspx?id=48742
Just for kicks, reboot
Your stuff should now properly load adalsql.dll!
Update #3, 2020-07-13: Installing the older version works, but is vulnerable to being clobbered by the SSMS and VS2019 installers. The reason the new version of ADAL doesn't work is because its installer fails to add a registry entry pointing to the 64-bit version of adal.dll. I added an answer below which includes the missing registry value, which you can add yourself. Once that's done, you should never need to do this dance again. - #Tullo_x86

The bewilderingly simple solution to this annoying problem
Ensure you actually have ADAL installed (the existence of C:\Windows\system32\adal.dll is plenty)
Paste this into a .reg file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSADALSQL]
"TargetDir"="C:\\Windows\\System32\\adal.dll"
Double-click the .reg file to install that value
You're done. Go celebrate!
Explain WTF is going on. Why this is necessary?
This error happens because the .NET adapter for SQL Server can't find adal.dll. But why is this? It's installed, right?
Well, the installer for the latest version of ADAL (packaged with VS 2019 and the latest version of SQL Server Management Studio) adds a registry entry for the 32-bit version of the DLL (at C:\Windows\SysWOW64\adal.dll), but does not add the entry for the 64-bit version (which gets installed to C:\Windows\system32\adal.dll). If you build and run your application in 32-bit mode, you'll never see this bug manifest.
This is simply a bug in the ADAL installer. Presumably it wasn't detected by Microsoft because both Visual Studio and SSMS are 32-bit applications and thus don't go looking for the 64-bit version.

In my case culprit was VS 2019.
It has newer version of ADALSQL package. For me it was at path "C:\ProgramData\Microsoft\VisualStudio\Packages\sql_adalsql,version=16.0.61903.25110,chip=x64,language=en-US", which I uninstalled and installed desired version to resolve the issue.
Hope this helps!

In my case, add/remove programs didn't show any installed instances of "Active Directory Authentication Library". Yet, trying to install the library would fail saying a newer version was installed.
I un-wedged myself by opening the registry editor (regedt32) and using the Find feature from
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer
looking for adalsql.
That got a hit with containing keys
DisplayName: Active Directory Authentication Library for SQL Server
DisplayVersion: 15.0.1300.359
along with, importantly, a path to the associated installer. For me it was something like c:\windows\installer\4c334521.msi. I ran that msi and was finally able to "uninstall". After that, running the installer from the 'library' link above finally worked.

Or you if planned to upgrade SSMS in the time being, simply uninstall "Active Directory Authentication Library for SQL Server", and repair SSMS.
Next time you upgrade SSMS it won't broke anything. SSMS bring his own adalsql.dll, and know how to upgrade it when you upgrade SSMS. But if you had installed adalsql with something else (or using https://www.microsoft.com/en-us/download/confirmation.aspx?id=48742 ), SSMS is somehow broken.

Related

SQLLocalDB.exe info - returns error code 15100, etc

I'm trying to work on a version problem with LocalDB. The command "sqllocaldb i" seems to work.
C:\WINDOWS\system32>sqllocaldb i
MSSQLLocalDB
ProjectsV12
But, when I ask for something specific, I get only errors. (I'm on Windows 10)
C:\WINDOWS\system32>sqllocaldb i MSSQLLocalDB
FormatMessageW failed. Error code returned: 15100
FormatMessageW failed. Error code returned: 15105
FormatMessageW failed. Error code returned: 15105
FormatMessageW failed. Error code returned: 15105
FormatMessageW failed. Error code returned: 15105
Thanks for the reply Paul. I have also removed all older SQL installs, but to get information on a particular LocalDB server instance using the SqlLocalDB.exe utility, I had to install the 2017 version. For instance I can now get information on an instance of SQLLocalDB (2016 version) that I created and called 'TAS_LocalDB_V13' using the command -
SqlLocalDB i TAS_LocalDB_V13
But, since there are now two versions of SQLLocalDB installed, there are two executables named SqlLocalDB.exe. The one that will run depends on the system environment path variable. I had to edit the path variable so that the path to SqlLocalDB.exe appearing first in the list was the 2017 version (which works).
Note - even though the i command in 2016 version does not work, other important commands like 'c' to create a server instance do work.
I fixed this by removing all traces of SQL from my machine and re-installing only what I needed (2016 in my case). Basically, search for "SQL" in Control Panel and remove whatever shows up.
I think this has to do with having multiple versions installed, and/or corruption happening when you update them, because:
I had SQL components ranging from 2008-2017 installed (both standard and express), and,
the problem started happening right after I applied the latest cumulative updates, which were mainly for SQL 2016.
UPDATE: it looks like the fix for this is closer to: re-install 2016 and install the 2017 sqllocaldb - no need to clean up other versions as I did. See Victor's subsequent post as well as my comment there.

SSIS C# 2012 Script Task referring WinSCPnet.dll fails when run from SQL Server Agent with "Exception has been thrown by the target of an invocation"

I have an SSIS package (created in VS 2013) that contains a C# 2012 Script Task.
The job of the script task is to download a file from an SFTP server using WinSCP .NET assembly and place it on my server (Windows Server 2012 R2 with SQL Server 2014)
My package runs fine when I run it on my Dev machine, but when I deploy to the server my package fails at this task with the error message
Exception has been thrown by the target of an invocation
I've done some digging and it looks like it has something to do with the reference to WinSCPnet.dll.
Quoting WinSCP article on Exception has been thrown by the target of an invocation:
This is just a high-level exception. The root cause is usually stored in the InnerException.
If you are getting this exception in SSIS, you can use try … catch block to capture the error, as show in the example for using WinSCP .NET Assembly from SSIS.
If you cannot access the inner exception easily, inspect WinSCP session log and debug log file (Session.SessionLogPath, Session.DebugLogPath). If those file are not even created, the root cause can be loading of WinSCPnet.dll assembly. See Could not load file or assembly ‘file:///…\WinSCPnet.dll’ or one of its dependencies. The system cannot find the file specified..
Installing the assembly to allow its loading is covered in Installing section of Using WinSCP .NET Assembly from SQL Server Integration Services (SSIS):
Installing
First, you need to install the WinSCP .NET assembly. Do not use the NuGet package.1
You also need to install the assembly to the GAC or subscribe AppDomain.AssemblyResolve event to allow loading the assembly.
The installation to GAC is covered by Installing to GAC section of Installation instructions for WinSCP .NET assembly:
Installing to GAC
In special cases, you may need to install the assembly into Global Assembly Cache (GAC), particularly to use it from SSIS.
When you install the assembly to GAC, you need to configure a path to WinSCP executable.
On Development Machine
To install the assembly into GAC on development machine, i.e. the one that has Windows SDK installed, use following command:
gacutil.exe /i WinSCPnet.dll
Windows SDK comes with Microsoft Visual Studio. You can also install it separately.
Use correct gacutil.exe for your version of .NET framework:
For .NET framework 4.0 or newer, use gacutil from Windows SDK 7.1 (or newer):
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\bin\gacutil.exe;
For .NET framework 3.5, use gacutil from Windows SDK 6.0:
C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe
On Production or User's Machine
To install the assembly into GAC on production or user’s machine, you may install the assembly into GAC using:
Windows Installer, by creating .msi package;
Any other installer system that supports installing to GAC, e.g. Inno Setup;
System.EnterpriseServices.Internal.Publish.GacInstall method. PowerShell example:
Add-Type -AssemblyName "System.EnterpriseServices"
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("WinSCPnet.dll")
An absolute path to the DLL needs to be specified and Administrator privileges are required. Otherwise the above method will fail (and the only indication of the failure is sent to Windows Event log).
See How to fix NuGet WinSCP.NET in SSIS Script Task?
You need to install WinSCPnet.dll in the Global Assembly Cache for SSIS to pick up this dependency, see this blog for further details. You can install a DLL in the GAC using the following steps, see the documentation for further details:
Copy the WinSCPnet assembly to your local computer into a folder.
Start Visual Studio Command Prompt.
Type the following command: gacutil.exe /if ""
This installs the assembly to the GAC, overwriting any existing assembly that has the same assembly name.
If you have already registered the appropriate Dll's are are still getting this error, and you are passing in variables that are package-scoped, be sure to add them to the "ReadOnlyVariables" in the script task.
Right click on the task and click "Edit...", then click the "..." on the "ReadOnlyVariables" property, and add the variables that are referenced in your script.

Installing MDS Excel Add-In Issue with Prerequisites

I am attempting to install the Master Data Services Plugin for Excel, but can't get the install to actually process due to it saying the prerequisites are not installed:
I have made sure I have the right version (32 bit) to match my version of excel (2010), and have the full version of .net 4.5 installed. If I try to install the full version of .net 4.0, I am told that the newer (4.5) version already is installed.
Here are some links with similar issues, but no response:
Microsoft Answers; Microsoft Connect;
Has anyone else faced this issue and got around it?
So, this looks to be a simple fix. The installer needs to be run as administrator, but in order to do that you have to run it through the command prompt as administrator. After doing this, it installed ok.
I'm not sure why the installer didn't request elevated privileges, but I'm guessing it couldn't properly query the system to verify the necessary prerequisites were installed.
Hopefully this helps someone else in the future!

Is pre-release versioning possible in nuget

According to the documentation, pre-release versioning is supported, with an example given of:
Within the NuSpec file, specify the version in the element
<version>1.0.1-alpha</version>
I am building from a .nuspec file; if I include this line verbatim, then run (at the package manager console):
PM> nuget pack "Nuget\protobuf-net.nuspec"
then I get a bit fat error:
Attempting to build package from 'protobuf-net.nuspec'.
NuGet.exe : Input string was not in a correct format.
At line:1 char:6
+ nuget <<<< pack "Nuget\protobuf-net.nuspec"
+ CategoryInfo : NotSpecified: (Input string wa...correct format.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
If, however, I just use <version>1.0.1</version> and run exactly the same command, then I get:
Attempting to build package from 'protobuf-net.nuspec'.
Successfully created package 'C:\Dev\protobuf-net\protobuf-net.1.0.1.nupkg'.
And indeed, it has built correctly. My NuGet Package Manager reports version 2.0.30625.9003.
So: am I doing something wrong? or did they break something?
NuGet Version: 1.5.21005.9019
Semantic versioning was introduced in nuget 1.6. Time for an upgrade. You can use nuget update -self to update right from the command line.

DotNetNuke Upgrade 4.9.2 - PermanentRedirect Failure

When installing DNN 04.09.02 upgrade (from DNN 4.8.4) I receive System.IndexOutOfRangeException: PermanentRedirect error and cannot install the upgrade. How do I get around this so I can install the upgrade?
This thread might help you:
It looks like you have to update it manually... steps are described there.
Also check this thread, might be due to AD if AD is used.
I've re-posted the following from the thread provided by kitsune. Source
First try the following in your browser. Replace "www.yourdomain.com" with your domain:
http://www.yourdomain.com/install/install.aspx?mode=install
If that doesn't work (which it didn't for me) then try the following steps (copied from Chris on that thread).
To manually run the SQL portion of the upgrade you'll need to run each upgrade script between your version and 4.9.2. I upgraded from 4.9.0 to 4.9.2 so I performed the following:
On the web server open the directory: \Providers\DataProviders\SqlDataProvider
Determine which files need to be run. Basically, all of the versions after your old version. In my case I needed to run the files 04.09.00.SqlDataProvider, 04.09.01.SqlDataProvider and 04.09.02.SqlDataProvider.
Open the SQL files in a text editor and replace "{databaseOwner}" (usually with "dbo.") and "{objectQualifier}" (usually with "", but sometimes "DNN4" or some other object prefix)
Run those SQL files in version order using SQL Management Studio.
Assuming those scripts ran without an error then the site should be ready to use.

Resources