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"
Related
I cannot for the life of me get F# to run in Visual Studio Code. I've had it up and running previously, but not with the most recent versions of the software.
I installed the most recent versions of .NET and VS code a month ago and again now, did full deletes and re-installs both times (including deleting user/.vscode and roaming/Code manually), but the error persists.
I am on a Windows 10 and have installed x64 versions of .NET Core 3.1 and VS Code 1.48 with the only extensions C# 1.23 and Ionide-fsharp 4.16. I have enabled Use Sdk Scripts for ionide, but otherwise run on default configuration. dotnet fsi is executed without problems in the command line.
Looking at the VSC extension host log:
[2020-08-15 11:24:35.431] [exthost] [error] Error: Language client is not ready yet
at LanguageClient.sendRequest (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:7887:19)
at __exports.compilerLocation (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4290:19)
at fsacConfig (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4730:12)
at c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4797:20
at Object.__exports.msbuild (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:4802:10)
at activate (c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:19152:91)
at c:\Users\Bruger\.vscode\extensions\ionide.ionide-fsharp-4.16.0\fsharp.js:25116:90
which I believe is caused by this problem seen in the VSC F# log:
[Error - 11.24.35] Starting client failed
Launching server using command Invalid macro definition. failed.
I'm stuck here as I don't know what macro definition this refers to or how to get more information about the failure.
I just found the cause and solution for the problem. It had nothing to do with Ionide or Visual Studio Code. Instead my cmd was acting up due to misconfiguration.
For a while the message "Invalid macro definition" has been output as the first thing when I open cmd, but I didn't see the connection to the problem above. Turns out that VS code did not like this output and that it was the AutoRun configuration for cmd that triggered this error.
Using regedit, I found that I had several AutoRun files that were no good, so I removed them from respectively Computer\HKEY_CURRENT_USER\Software\Microsoft\Command Processor and Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor and the problem was solved.
[INS-20802] Oracle Database Configuration Assistant failed.
Cause - The plug-in failed in its perform method Action - Refer to the logs or contact Oracle Support Services. Log File Location
C:\Program Files\Oracle\Inventory\logs\installActions2016-12-19_11-03-33AM.log
I faced the same issue recently and I tried several of the following methods for resolving the issue :-
Disabling Windows UAC
Disabling firewall
Disabling antivirus - mine was a fresh VM, so disabled Windows Defender
Adding localhost IP i.e., 127.0.0.1 to the hosts file etc.
but none of them helped.
At last I found this, which suggested installing Microsoft Visual C++ 2010 Redistributable Package (x86) and this solved the problem in a matter of seconds! I just had to click 'Retry' on the installation dialog.
For me everything was working fine...I checked for listener, services, path.
Then I tried below and it works...
During installation when Database configuration got failed.
Go to sqlnet.ora file and replace NTS with NONE.
Example :
SQLNET.AUTHENTICATION_SERVICES= (NONE)
After that try again installing the database configuration. Click on Retry.
Note: If you have installed oracle and skip database configuration failed step then you can go to search bar of window and open Database configuration and try downloading it & it will get installed and will ask for password.
After that you will be able to connect to database.
DONT USE # IN ORACLE PASSWORD Because when you try to login sql plus it will give error. In case you did that then write your password in inverted commas. ex: "password"
There is a bug in some installers, as described in this other answer, which prevents Oracle from installing the required Microsoft Visual C++ 2010 Redistributable.
The 32bit installer uses the file install\oraparam.ini, which contains these lines:
#Flags for installing MSVCR80
#MSVCREDIST_LOC flag will provide the name of the exe that is being shipped in stage/ext/bin
MSVCREDIST_LOC=vcredist_x64.exe
But the file available under stage/ext/bin/ is vcredist_x86.exe.
So before installing, edit the install\oraparam.ini file, and replace _x64 with _x86 in that line to get:
MSVCREDIST_LOC=vcredist_x86.exe
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!!!
I am running VS2010 Ultimate, I used to have VS Web Dev 2010 Express with Nuget before: I uninstalled it before installing Ultimate.
In admin mode I uninstalled Nuget 1.5 from vs, restarted vs in admin mode, installed 1.6, and then restarted vs. Nuget worked for several days.
The next day, the package manager wont come up - it doesnt give me an error, it just wont load. If I try to uninstall it, the uninstall button is greyed out (which I assume means that the addin is in use). If I restart vs, then I can uninstall.
I have tried uninstalling Nuget and reinstalling it several times (no error messages generated)
Trying to load Package Manager Console and the Package Manager Settings, dont launch anything.
Is there a way to install version 1.5? I've looked for a link but cannot find one.
Is there a log file I can check to see what is wrong?
This has been an extremely frustrating issue for me.
Update:
I used devenv /log, tried to open the package console.
Here's part of the log file:
225 Leaving function LoadDTETypeLib VisualStudio 2011/12/30 21:54:45.181
226 ERROR SetSite failed for package [NuGet.Tools.NuGetPackage, NuGet.Tools, Version=1.6.21215.9133, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] {5FCC8577-4FEB-4D04-AD72-D6C629B083CC} 80131509 VisualStudio 2011/12/30 21:54:45.196
227 ERROR End package load [NuGet.Tools.NuGetPackage, NuGet.Tools, Version=1.6.21215.9133, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] {5FCC8577-4FEB-4D04-AD72-D6C629B083CC} 80131509 VisualStudio 2011/12/30 21:54:45.227
228 Warning Package failed to load; error message suppressed by skip flag {5FCC8577-4FEB-4D04-AD72-D6C629B083CC} VisualStudio 2011/12/30 21:54:49.486
229 Entering function CVsPackageInfo::HrInstantiatePackage
Thanks!
Finally got it working: had to delete c:\User Data\\AppData\Roaming\NuGet\NuGet.Config (which was empty) and now it can load.
I had the same problem, nuget worked yesterday but not today with "SetSite failed for package [NuGet.Tools.NuGetPackage" in the VS log.
After a lot of trying and failing I found this page, and then the discussion at http://nuget.codeplex.com/discussions/284604
I followed the advice from bsparkinson there :
Unistalled Nuget.
Searched for nuget in %appdata% and deleted everything
Reinstalled Nuget.
And now it works.
You mentioned:
If I try to uninstall it, the uninstall button is greyed out (which I
assume means that the addin is in use).
Is it greyed out even when you run VS as an admin? The button should only be greyed out if you're not running as admin.
The other thing you should do is try running the following command. You'll need to use the devenv command prompt.
vsixinstaller.exe /uninstall:NuPackToolsVsix.Microsoft.67e54e40-0ae3-42c5-a949-fddf5739e7a5
That should uninstall the NuGet VSIX. After doing that, the following directory should be gone or empty: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\\