I get this error when trying to open SQL Server Management Studio 2008 R2:
Unable to cast COM object of type 'System.__ComObject' to interface
type 'Microsoft.VisualStudio.OLE.Interop.IServiceProvider'. This
operation failed because the QueryInterface call on the COM component
for the interface with IID '{6D5140C1-7436-11CE-8034-00AA006009FA}'
failed due to the following error: No such interface supported
(Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
(Microsoft.VisualStudio.OLE.Interop)
Details:
Windows 7 Professional
SQL Server 2008 R2
Visual Studio 2010
I had exactly the same problem, after a lot of search on Google and tried a lot of different solution that didn't worked in my case, I finally find a working solution on another thread of stackoverflow (here) based on a social.msdn thread. It seems that other solutions could work, depending on undefined situations as far as the problem cause isn't well defined...
The solution that worked for me:
regsvr32 "C:\Program Files\Internet Explorer\ieproxy.dll"
if you are running 64 bit windows, try this:
regsvr32 "C:\Program Files (x86)\Internet Explorer\ieproxy.dll"
The solution that worked for others:
First deregister the dll:
C:\windows\system32\regsvr32.exe" /u actxprxy.dll
Then register it again: "C:\windows\system32\regsvr32.exe" actxprxy.dll
Note: use a command shell in both case with administration rights (Win+R then type cmd)
Some information on Connect, though Microsoft is saying they can't reproduce the problem.
Have you installed SQL Server 2008 R2 Service Pack 1 to your client machine? I would try that. It is possibly something messed up due to order of installation of SQL Server / Visual Studio. Applying the service pack should help straighten it out.
Thanks for the hint, user1267600!
I've got the same issue, but in my case the problem was I've moved accidentally the "C:\Program Files (x86)\Internet Explorer" folder to another one and SSMS started showing this error. Then I've found it and moved it back and everything got back to working. No "ieproxy.dll" registration was needed.
*Hint - Don't move around the "Internet Explorer" folder or any other Windows related soft folder, you'll never know what depends on it! :)
I had the same issue. After installing IE11, I registered ieproxy.dll and SQL Server Management Studio is running again. Thanks!!!
Related
I am trying to debug a program using Entity Framework code first on my personal (work) computer.
We have recently had a domain migration, meaning that the user I log in as now is not the same that I used before. This caused me to loose access to the databases I had on the computer. To get around this, I have uninstalled everything to do with Microsoft SQL Server on the computer, and installed the latest version of Microsoft SQL Server, 2014 - 12.0.4213.0 . I then restored the database I need.
When I first tried to run the program, Visual Studio complained that the project is set up to use SQL Server Express, which was not installed. The recommended solution is to change the project to use SQL Server instead. To do this, I must click on "the database file" and follow the instructions. I have looked through the entire solution. There is a great many files, but I found no good candidate for "the database file."
It seems that my Google fu is not strong enough to find anything about this. So my question is: how do I change the project to use SQL Server?
I also have a second, related question. I tried to solve the problem by installing SQL Server Express. However, when I try to restore the database to this, no base appears in the drop down list. When I try to run the program now, I get another error:
Unable to create the file 'c:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\Timelønsblanket.mdf' because it already exists.
I guess that this is also why I cannot restore the database. What I have found in websearches warns that I should not manually delete .mdf files.
Any advice on what to do?
I have solved the problem. All that was needed was a correct connection string. No need to find a "database file".
The problem I need to be solved is that the Nuget Package Manager Console in Visual Studio 2013 cannot start because the Windows Powershell raises the error:
The shell cannot be started. A failure occurred during initialization: The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception.
I tried reinstalling nuget, repairing VS2013, changing the execution policy in powershell x86 (the common solution given here in stackoverflow) but the error persists.
Until I realize that the problem is in the x64 powershell(C:\Windows\SysWOW64\WindowsPowerShell\v1.0) because the x86 version is fine.
I'm using Visual Studio Ultimate 2013 Update 4 32-Bits in Windows 8.1 x64
I found out the answer, it has to do with the legacy security policy in .Net
I open the file C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config and set the attribute "enabled" to False in the tag NetFx40_LegacySecurityPolicy and voilá, the powershell of SysWoW64 is working.
In my case I was receiving this same error for an unknown reason and thanks to this hint I looked for the NetFx40_LegacySecurityPolicy in
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
and
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
but could not find that tag...
I did see LegacyCasPolicy enabled="true" in
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
and set it to false...viola, worked like a charm...Had no idea of how this got set but could not find a solution to this problem anywhere, and no, I did not have any corrupted system files.
Same issue different key.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
Change to false
NetFx40_LegacySecurityPolicy enabled="true"
I've followed the instructions over at http://msdn.microsoft.com/en-us/library/dd193258(v=vs.100).aspx
I've copied the deploy folder and the other dll's over to the remote machine and installed SQL Server 2008 Management Objects. However, when I attempt to run my command (real credentials stripped)
vsdbcmd /a:Import /cs:"Data Source=mydb;Integrated Security=false;Pooling=False;Initial Catalog=dbname;User ID=sa;Password=password;" /model:today.dbschema
I always get the error
The extension type Microsoft.Data.Schema.Sql.Sql100DatabaseSchemaProvider could not be instantiated.
I've searched around, but don't see anything that points to this. Any help please?
I found the issue - the server had .NET 4.0 Client Profile installed. Once I installed the full runtime, this issue went away.
I have these error messages when I start MS-Access application (has VBA code).
When I click OK in the first error message and debug in the second, the debugger opens up and points to the line that says: "Set oServer = New SQLDMO.SQLServer"
I realise that it's a problem with SQL-DMO, but can't seem to register the DLL.
My environment: Win7 Pro 64-bit, Office 2010 64-bit, MS SQL Server 2008 R2 SP2 64-bit.
I downloaded the backwards compatibility package from Microsoft, ran the MSI, and nothing.
Tried to manually install, and get error messages:
R6034 for C:\Windows\System32\regsvr32.exe and when I click Ok --> The module "SQLDMO.DLL" failed to load. Make sure the binary is stored at the specified path or debug it... blah blah
When I try to register it from C:\Windows\SysWOW64, I get "The module "SQLDMO.DLL" may not (be) compatible with the version of Windows that you're running. Check if the module is compatible with....
I've checked the version of SQLDMO.DLL and it is definitely 64-bit. I have located all the other DLLs that SQL-DMO needs and stored them in SysWOW64 and System32.
I have run Office repair, Windows Update, SQL Server repair (the log file indicates pass for everything for Client Tools Backwards Compatibility).
Any help is much appreciated.
Thanks, Miki.
Not sure how I've managed to, but have (somehow) managed to register the 64-bit SQLDMO.DLL (before it didn't really register it) and then in my VBA code--> Tools --> References... I tried to load the SQLDMO.DLL from the 64-bit folder.
At first, it didn't work, and then I placed a copy of the DLL in SysWOW64 (which is a 32-bit folder) and registered it from there (once it was registered, apparently, the system doesn't need it there anymore - I removed it, and it still works).
I then tried to figure how come it works. I checked in the Reference Table in the VBA Code, and the Microsoft SQLDMO Object Library is still pointing to C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn, but when I removed SQLDMO.DLL from there it still worked... I then looked in C:\Program Files\Microsoft SQL Server\80\Tools\Binn and removed SQLDMO.DLL from there and then it stopped working!
I have no idea what happened, or why the reference table is saying it's pointing to one folder but actually pointing to a different one, or how after the same tries before, only now it works.
I'd like to be able to replicate this (in case I need to go through this process again), so any ideas/suggestions would be greatly appreciated.
Thanks, Miki.
I've been writing up a script that runs some server functions using a web-browser interface. I coded up the script on Windows 7 with Internet explorer 8 and it works fine.
As soon as I move it to the production server running Windows 2008 with Internet Explorer 9, it breaks. Finally traced it the point of failure, but I'm a bit stumped how to fix it.
Here's the code that will cause an issue:
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate("http://www.google.com")
$ie.visible = $True
$doc = $ie.document
$Object1 = $doc.getElementByID("pocs")
This pops up an IE windows, and it should be able to search elements by ID. Trouble is, now I get the error
"Cannot find an overload for "getElementById" and the argument count:
"1"."
I can find very very little on this error. The actual issue is actually the variable $doc. If I do a "$doc | get-member" on IE 9 I get:
TypeName: System.__ComObject#{c59c6b12-f6c1-11cf-8835-00a0c911e8b2}
But under IE 8 I get:
TypeName: mshtml.HTMLDocumentClass
So, basically, IE 9 / Windows 2008 is failing to load the web document contents when I call $ie.document. I've tried setting IE9 to compatibility mode, but no luck there.
The $ie.document | get-member does actually show the method of : "getElementById Method Variant getElementById () " so it's in there, but there's no document for it to parse.
Any ideas would be greatly appreciated.
I am equally astonished this has not been fixed yet given the longevity of the issue on various technical forums. However I think I have found the solution, though it would be up to the Microsoft IE team to address at some point.
Like all the threads referenced that have looked into this I have suffered the same issue with the getElementById method, which with no other changes to a couple of test machines (one Windows 2008R2 Enterprise 64bit and one Windows 7 32bit), I can get the same script to work.
Workarounds that worked as temp solution that I didn't like:
Using the dev console in IE11, switch the Document Mode to 8 (9,10,11,Edge (default) don't work) - my automation script works instantly. No changes to IE trusted sites, zone security, protected mode, PowerShell session priveleges). So clearly just a component issue of the IE11 installation of some sort
Installing Office 2013, without ever running or licensing it, the same script works instantly without changing the Document Mode of IE11. Clearly Office does install/register something that fixes the problem (as Rhys Edwards says)
So I set about narrowing down what Office does to enable the COM object required for IE automation by:
Preparing a new Virtual Windows 2008R2 Server , no updates. Ran test script under IE8 - no issues.
Upgraded to IE11. Ran test script - failed as usual.
Took a VM snapshot
Used Regshot to do record the registry and file system
Ran the Office 2013 Pro_SP1 installation, no changes to default options
When Office install completes, did not run office once (at all ever)
Ran test script again - everything works, the IE automation with getElementById calls all back in operation
Took a 2nd VM snapshot
Ran 2nd scan with regshot and analysed the differences
Dumped the properties of my $ie object and also noticed there is far more there than before running Office install. References mshtml.dll and HTMLDocument classes throughout - looks as it should
I can see from the RegShot difference file that MSHTML.dll is ADDED and registered in the GAC (version 7.0.3300.0) by the office installation
What I did next may not be completely approved but:
I located the microsoft.mshtml.dll in the "c:\program files(x86)\Microsoft.net\primary interop assemblies" folder and saved it out of the VM to my local machine desktop
reverted to the pre-office 2013 snapshot
copied the microsoft.mshtml.dll into the VM and installed to the GAC (remember this is a 2008R2 server still on .net 2, I didn't update .net prior to or after IE11 install, only office). I installed to the GAC simply by dragging the file into the c:\windows\assembly view in explorer. In later versions of .Net you need to use gacutil /l
Tested the same script and BOOM, it all works fine. No need to change any IE settings or elevate script privileges or install Office
So to sum up. If you install IE11, to get PowerShell to automate the Document Model, I had to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesn't ensure this happens is beyond me but I think that the IE team need to look into this.
I also think for those where it 'just works' in IE10/11, you must have a product on the machine that has already registered the mshtml.dll in the GAC (perhaps Office, perhaps Visual Studio or some other MS app). Hence why you are not seeing the same problem that definitely exists.
Hope this helps someone - it was driving me crazy!
Andrew
As detailed in the comments on the question, there seems to be three solutions to this problem.
Upgrade to PowerShell 3.0: Version 2.0 is only compatible with up to IE8 when it comes to web-scraping and using IE as an object. However, version 3.0 will work with IE9. You can get it here.
Turn off protected mode in IE: Turning of protected mode for the Internet zone under the Security tab in settings seemed to do the trick for me. There are security implications to this that should be carefully considered.
Run the script in admin mode: Simply run the script in an elevated PowerShell prompt.
The last two solutions come from a different SO answer.
I had similar kind of issue and it got resolved by following below steps:
Check for the Microsoft.mshtml.dll on your machine. It should be available at location C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies. If you don't find it at this location, It might be the case that you don't have this dll and this is the reason you are getting this issue.
Find the dll, and try to load the assembly at run time. You can place the dll at any location on you machine and do it.
Below is the link to a method to load assembly at run time.
https://onedrive.live.com/?cid=21ad54fd70600673&id=21AD54FD70600673%211922