>>IIRC ADO.NET maintains a connection pool and your new SqlConnection() will just grab (or release) an existing connection from the pool. I think there's a ClearPool method - check this:
>> https://msdn.microsoft.com/en-us/library/8xx3tyca(v=vs.110).aspx
>
>This seems to work for others but it does not work for me.
>
>Basically, I have added the clear pool line before my restore procedure:
>
>

>' In order to restore, we need to clear the connection pool
>System.Data.SqlClient.SqlConnection.ClearAllPools()
>
>oStatus.Text = lcRestoringDatabase + "..."
>
>loRestore.Devices.AddDevice(cPath + "\" + cDatabase + ".bak", Microsoft.SqlServer.Management.Smo.DeviceType.File)
>loRestore.Database = cDatabase
>loRestore.Action = Microsoft.SqlServer.Management.Smo.RestoreActionType.Database
>loRestore.ReplaceDatabase = True
>loRestore.PercentCompleteNotification = 1
>AddHandler loRestore.PercentComplete, AddressOf ProgressEventHandler2
>loRestore.SqlRestore(loServer)
>

>
>And, I still cannot get exclusive use of the database.

From the ClearAllPools() reference https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.clearallpools(v=vs.110).aspx : "ClearAllPools resets (or empties) the connection pool. If there are connections in use at the time of the call, they are marked appropriately and will be discarded (instead of being returned to the pool) when Close is called on them."

IOW if other processes have connections open, that call does not force them closed - and rightfully so IMHO.

Also, I'd think if that call is supposed to be global (and I'm not sure it is, it might be limited to the calling process's security context) then you might have to run with elevated privileges.

If you haven't already, you might want to run the connection enumeration code in the link I posted earlier to make 1,000% sure there aren't other unexpected processes with open connections.