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.
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".
(NOTE: the following problem after appeared after the production server in question underwent system hardening):
I have a PowerShell module that contains the following line:
[OutputType([Microsoft.SharePoint.Publishing.PublishingPage])]
When I open a PowerShell console running as Administrator (as well as being logged in to the server as a sys admin), I get the following:
Unable to find type [Microsoft.SharePoint.Publishing.PublishingPage]: make sure that the assembly containing this type is loaded.
I am able to "force" the Microsoft.SharePoint.Publishing DLL to load with both LoadWithPartialName as well as Add-Type, but then I get the same error with regard to Microsoft.SharePoint when I try to execute my module.
Both DLLs are definitely in the GAC (version 14.0.0.0 as this is SharePoint 2010) and when I view permissions on the GAC, the permissions are sufficient.
As stated previously, the module executed fine previously, and the "Unable to find" error only started occurring after the server in question underwent some system hardening by a third-party. I have tried to investigate the issue from a permissions and group policy standpoint, but so far I do not have any leads.
I am able to somewhat reproduce the error in my dev environment if I completely trash the permissions on my GAC, but this does not truly reflect the situation in production, as the permissions in production appear to be more than sufficient for being able to "see" a DLL in the GAC.
Any help would be greatly appreciated.
You might have better luck with [Microsoft.SharePoint.Publishing.PublishingPage] ;-)
That said, for types that are not part of the BCL, you should use a string instead of a type literal. This allows the module to be loaded - at least - on a machine without sharepoint. That would look like:
[outputtype("Microsoft.SharePoint.Publishing.PublishingPage")]
As far as powershell is concerned, the constraint is the same.
In the end, right-clicking on the PowerShell icon and selecting "Import System Modules" was the solution.
When I changed my OutputType to use quotes instead of brackets, I then received an error that Get-SPSite was not recognized as a cmdlet (selecting "Import System Modules" resolved this error.) I then went back to using brackets for the OutputType and confirmed that "Import System Modules" was all that I needed.
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 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!!!
When using a local NuGet server, whenever I try to install an individual package from that server, all I get is this error: "The remote server returned an error: (404) Not Found."
The packages are all there in the filesystem and the feed itself sees all the packages appropriately. I can even browse the package directly!
What am I missing?
I did just upgrade from NuGet server 1.4 to 1.5, but I've seen this happen before. Touching the package files used to help, but that does not appear to be the case now.
EDIT: Actually, I hadn't seen that exact error before...I've seen this one, intermittently, that touching the package tended to fix.
On Windows Server 2008, I was having the same issue. I switched the Application Pool from "ASP.NET v4.0 Classic" to "ASP.NET v4.0". The install-package command worked fine after the change.
sigh...
http://blogs.thesitedoctor.co.uk/tim/2011/09/02/Nuget+Server+On+IIS6+Returns+404+When+Downloading+Package+After+Upgrade.aspx
EDIT: In case the link ever dies...I am hosting my NuGet server in IIS6, which wasn't set up to properly handle extensionless URLs. And since the semantics of downloading individual packages changed from a direct file link to an extensionless route, I started getting 404s. Adding the wildcard mapping described in the article fixed it instantly.
I've been trying to figure this for a couple of hours...
Checked the IIS logs and discovered that URLScan was blocking the route:
GET /Rejected-By-UrlScan ~/api/v2/package/
URLScan doesn't accept any route not starting with '/'. The best I could do was to remove the URLScan from the list of ISAPI filters for the website in the IIS Manager.
I was having the same issue on Windows Server 2008.
Problem was in my own package MyPackage.nupkg that I saved without version.
MyPackage was visible in PackageManager but it was getting 404 error on install.
Fix:
I saved it with name MyPackage.1.0.0.nupkg (1.0.0 is current version) and problem was fixed.
I had the same problem, srv 2008 R2. Changed the application pool to Integrated from Classic and all works fine now.
My problem was same as image above. I could go to the site on url
http://localhost:3407/nuget/Packages
but not
http://localhost:3407/api/v2/package/{package name}/1.0.0.0
I encountered this error while trying to download Signal-R after update Nuget, however it was just that I had not checked the "Allow Nuget to download missing packages during build" option in package manager settings. Once that was that set it all worked fine again.
It could be this as well -
You are trying to refer to a url like : http://yourdomain/application/nuget/packages
Then you should change it to :
http://yourdomain/application/nuget
This is a common mistake.