This is my NuGet.config :
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
<disabledPackageSources>
<add key="Microsoft and .NET" value="true" />
</disabledPackageSources>
</configuration>
Now, in Visual Studio, when I try to install 'geckofx45' package, I get the following error:
install-package geckofx45
install-package : Unable to load the service index for source https://api.nuget.org/v3/index.json.
At line:1 char:1
+ install-package geckofx45
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Install-Package], Exception
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
Do you have any solutions?
Visual Studio - Nuget - Unable to load the service index for source
This is a common error, we could not get much useful info from this error message. We could only provide the troubleshootings for this issue.
The reason for this issue in most cases is because the network issue or the incorrect configuration in the nuget.config.
In order to make sure that whether this issue is related to the VS IDE, the network or others, first, please open the path of the nuget server https://api.nuget.org/v3/index.json in the browser. If you can open it in the browser, this issue probably more related to the VS IDE/nuget.config. You can delete nuget.config in the %appdata%\Nuget, then restart the Visual Studio to generate the new nuget.config.
Second, if you also could not open it in the browser, this issue probably related to the network issue, you should check if you have proxy variable http_proxy in our system variables or in the IE browser, we could test it on another PC with same network. if you have the proxy settings in your PC, you can remove it to test it or you can add proxy settings into Nuget.Config file. Refer to this link for details: Nuget Config Section & Nuget Proxy Settings. After we confirm we do not have any proxy in our PC, then we should to check if our network is limited. We could test it with a different net work.
See the same issue for some more details.
dotnet restore --interactive solved issue for me.
Tested on Windows 7
Step1: Open Command window (run cmd) Step 2: Run the following commands to enable TLS 1.2 support if it is disabled (adding REGISTRY Entries):
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f /reg:32 reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f /reg:64 reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f /reg:32 reg add
"HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f /reg:64
For me the issue was solved moving to another VS version. It did not work on VS 2022 but it did in VS 2019
nuget restore
and
msbuild /t:restore
both didn't work for me. But
dotnet restore
worked perfect. Try that
I've been trying to get the Tomcat8 system tray icon to appear on a Windows Server 2012 box, but I'm running into an issue. I followed the instructions here to put the Tomcat 8 icon in the system try. So, I ran the following command
C:\..\bin>tomcat8w //MS//Tomcat8
The icon shows up in the system tray, as expected, but when I reboot my machine the icon is no longer there, and I must run the same command in order for it to appear again. Is there anything I can do to ensure that the icon remains persistently?
There are several solutions for this.
What worked for me is the following:
Create a .bat to run at windows log on that opens the tomcat icon tray.
To do so, just use what you posted before:
Open a notepad and type the following:
start "" "C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\bin\Tomcat7w.exe" //MS//Tomcat7
Go to file --> Save as...
Select the location C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
in "Filename:" type, TomcatMonitor.bat
in "Save as type" select, All Files (.)
That's it. Next time your computer log on it will run the script to open the Tomcat monitor.
Tomcat 8: If you installed in the default location, type +R, then enter
"C:\Program Files\Apache Software Foundation\Tomcat 8.0\bin\Tomcat8w.exe" //MS//
and click OK. This will install the feather icon into the system tray (regardless of whether you had it before or not).
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
Improve this question
How to uninstall / completely remove Oracle 11g (client)?
deinstall.bat doesn't work.
Edit: Further discussion related to why this question was closed and deleted: https://meta.stackexchange.com/questions/190441/why-was-this-question-related-to-uninstalling-the-oracle-database-client-deleted
Assuming a Windows installation, do please refer to this:
http://www.oracle-base.com/articles/misc/ManualOracleUninstall.php
Uninstall all Oracle components using the Oracle Universal Installer (OUI).
Run regedit.exe and delete the HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE key. This contains registry entires for all Oracle products.
Delete any references to Oracle services left behind in the following part of the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ora* It should
be pretty obvious which ones relate to Oracle.
Reboot your machine.
Delete the "C:\Oracle" directory, or whatever directory is your ORACLE_BASE.
Delete the "C:\Program Files\Oracle" directory.
Empty the contents of your "C:\temp" directory.
Empty your recycle bin.
Calling additional attention to some great comments that were left here:
Be careful when following anything listed here (above or below), as doing so may remove or damage any other Oracle-installed products.
For 64-bit Windows (x64), you need also to delete the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE key from the registry.
Clean-up by removing any related shortcuts that were installed to the Start Menu.
Clean-up environment variables:
Consider removing %ORACLE_HOME%.
Remove any paths no longer needed from %PATH%.
This set of instructions happens to match an almost identical process that I had reverse-engineered myself over the years after a few messed-up Oracle installs, and has almost always met the need.
Note that even if the OUI is no longer available or doesn't work, simply following the remaining steps should still be sufficient.
(Revision #7 reverted as to not misquote the original source, and to not remove credit to the other comments that contributed to the answer. Further edits are appreciated (and then please remove this comment), if a way can be found to maintain these considerations.)
There are some more actions you should consider:
Remove Registry Entries for MS Distributed Transaction Coordinator (MSDTC)
Note: on the Internet I found this step only at a single (private) page. I don't know if it is required/working or if it breaks anything on your PC.
Open Regedit
Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\MSDTC\MTxOCI
Add an x before each string for OracleOciLib, OracleSqlLib, and OracleXaLib
Navigate to HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\MSDTC\MTxOCI
Add an x before each string for OracleOciLib, OracleSqlLib, and OracleXaLib
Otherwise these files, if they exist, will still be in use next time you reboot, and unable to be deleted.
Remove environment variable ORACLE_HOME, ORACLE_BASE, TNS_ADMIN, NLS_LANG if exist
Check also Oracle doc to find all Oracle related environment variables, however apart from variables listed above they are very rarely used on Windows Client: Oracle Environment Variables
Unregister oci.dll
Open a command line window (Start Menu -> Run... -> cmd)
Enter regsvr32 /u oci.dll, resp. %windir%\SysWOW64\regsvr32 /u oci.dll
In some cases the file %ORACLE_HOME%\bin\oci.dll is locked and you cannot delete it. In such case rename the file (e.g. to oci.dll.x) and reboot the PC, afterwards you can delete it.
Remove Oracle .NET assemblies from Global Assembly Cache (GAC). You do this typically with the gacutil utility, if available on your system. Would be like this:
gacutil /u Policy.10.1.Oracle.DataAccess
gacutil /u Policy.10.2.Oracle.DataAccess
gacutil /u Policy.1.102.Oracle.DataAccess
gacutil /u Policy.1.111.Oracle.DataAccess
gacutil /u Policy.2.102.Oracle.DataAccess
gacutil /u Policy.2.111.Oracle.DataAccess
gacutil /u Policy.2.112.Oracle.DataAccess
gacutil /u Policy.2.121.Oracle.DataAccess
gacutil /u Policy.2.122.Oracle.DataAccess
gacutil /u Policy.4.112.Oracle.DataAccess
gacutil /u Policy.4.121.Oracle.DataAccess
gacutil /u Policy.4.122.Oracle.DataAccess
gacutil /u Oracle.DataAccess
gacutil /u Oracle.DataAccess.resources
gacutil /u Policy.4.121.Oracle.ManagedDataAccess
gacutil /u Policy.4.122.Oracle.ManagedDataAccess
gacutil /u Oracle.ManagedDataAccess
gacutil /u Oracle.ManagedDataAccess.resources
gacutil /u Oracle.ManagedDataAccessDTC
gacutil /u Oracle.ManagedDataAccessIOP
gacutil /u Oracle.ManagedDataAccess.EntityFramework
Entry System.Data.OracleClient should not be removed, this one is installed by Microsoft - not an Oracle component!
Instead of gacutil /u ... you can also use OraProvCfg /action:ungac /providerpath:... if OraProvCfg is still available on your system. You may find it at %ORACLE_HOME%\odp.net\managed\x64\OraProvCfg.exe.
With a text editor, open XML Config file %SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config and delete branch <oracle.manageddataaccess.client>, if existing.
Do the same with:
%SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
%SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config\web.config
Instead of editing the XML Config file manually you can also run (if OraProvCfg.exe is still available on your system):
%ORACLE_HOME%\odp.net\managed\x64\OraProvCfg.exe /action:unconfig /product:odpm /frameworkversion:v4.0.30319
%ORACLE_HOME%\odp.net\managed\x86\OraProvCfg.exe /action:unconfig /product:odpm /frameworkversion:v4.0.30319
%ORACLE_HOME%\odp.net\managed\x64\OraProvCfg.exe /action:unconfig /product:odp /frameworkversion:v4.0.30319
%ORACLE_HOME%\odp.net\managed\x86\OraProvCfg.exe /action:unconfig /product:odp /frameworkversion:v4.0.30319
Check following Registry Keys and delete them if existing
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\ODP.Net
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\ODP.Net
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\Oracle.ManagedDataAccess
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\Oracle.ManagedDataAccess.EntityFramework6
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\odp.net.managed
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\Oracle.DataAccess.EntityFramework6\
HKLM\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\ODP.Net
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\ODP.Net
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\Oracle.ManagedDataAccess
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\Oracle.ManagedDataAccess.EntityFramework6
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\odp.net.managed
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\Oracle.DataAccess.EntityFramework6\
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application\Oracle Data Provider for .NET, Managed Driver
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application\Oracle Data Provider for .NET, Unmanaged Driver
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application\Oracle Provider for OLE DB
Delete the Inventory folder, typically C:\Program Files\Oracle\Inventory and C:\Program Files (x86)\Oracle\Inventory
Delete temp folders %TEMP%\deinstall\, %TEMP%\OraInstall\ and %TEMP%\CVU* (e.g %TEMP%\CVU_11.1.0.2.0_domscheit) if existing.
Do everything suggested by ziesemer.
You may also want to remove from the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\<any Ora* drivers> keys
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\ODBC Drivers<any Ora* driver> values
So they no longer appear in the "ODBC Drivers that are installed on your system" in ODBC Data Source Administrator
Do everything suggested by ziesemer.
You may also want to :
Stop the Oracle-related services (before deleting them from the
registry).
In the registry, look not only for entries named "Oracle"
but also e.g. for "ODP".
I am attempting to install PostgreSQL 9 (postgresql-9.0.3-1-windows.exe) on my WinXP machine and get the following error at the start:
Some googling around yielded some advice that suggested Windows Scripting Host might be disabled. I've checked and WSH is definitely enabled, so it must be something else. Question is, what?
I can see a file called prerun_checks.vbs is created in %TEMP% and when I try to run this manually, I get the following:
Which looks like a permissions error. However, I am an Admin, and I've given myself full control of the temp folder and it's still not working.
Any help appreciated.
In my case the solution was related to NotePad++ being the default application for opening .vbs files. If you have the same situation, here's an elaborate solution:
http://igordcard.blogspot.co.il/2012/03/unable-to-write-inside-temp-environment.html
In a nutshell, in the registry, you need to go to HKEY_CLASSES_ROOT\.vbs, and set the (Default) entry back to the string VBSFile.
This is a an old thread, but I just had the same problem on windows 10:
Unable to write inside TEMP environment path
Solve by the following steps
Check that the problem is related to Windows Script Host.
From cmd run wscript.exe
If you get an error Windows Script Host is not enabled then you can solved it by running the following from cmd
Fix for Current User
REG DELETE "HKCU\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Fix for Local Machine
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Now you can install psql
As I was finishing off my question above, our IT chap turned up and knew what the problem was immediately: it's McAfee. It prevents anything from running in a TEMP folder, including Windows Scripting Host scripts. Disabling McAfee for the duration of the installation fixed the problem for me.
So if you see this problem, try disabling your anti-virus.
The answer in the following page helpped me.
http://forums.enterprisedb.com/posts/list/3040.page
run-> regedit and take backup of registry using export
HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8} -> InprocServer32
Modify registry entry with new value as C:\Windows\System32\vbscript.dll
In fact, I found there are 3 entries of HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8}, and set the first one as above, it works.
If anyone else is searching for information on this and doesn't have any luck here, you might want to look at:
http://wiki.postgresql.org/wiki/Troubleshooting_Installation
For follow-ups to the mailing list please read:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Well, in my case nothing worked, and disabling McAffee needed a special ticket with my company's security team to actually do... so I installed using the binaries, by following this guide Helpful Guide.
In summary, download the binary from here, unzip it, go inside the pgsql folder, create log and data directories in there, and then open a command prompt, navigate to where the pgsql\bin folder is, and run initdb -U postgres -A password -E utf8 -W -D POSTGRESQL_ROOT\data
You can start and stop the server by running
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" start
and
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" stop
where POSTGRESQL_ROOT is the full path to the pgsql folder.
All the above did not work for me. I was getting an error like:
Script output:
CScript Error: Windows Script Host access is disabled on this machine. Contact your administrator for details.
so after a couple of googling i found the solution:
Navigate to the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings
In the right panel, you will see Enabled. If you see the entry 0, it means that the Windows Script Host access is disabled on your Windows machine.
Double Click on it and give it Value Data 1 to enable it.
A value of 1 will enable Windows Script Host
A value of 0 will disable Windows Script Host.
for windows 10 navigate to
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings
To prevent further problems you should also exclude the data directory (where Postgres puts its data) from being scanned by your virus-scanner
In my case it was another application that caused the problem. Not Notepad++. To others who encounter this problem, you can diagnose it by first deleting all files in C:\Documents and Settings\UserName\Local Settings\Temp so that you'll be able to find the bitrock_installer.log easily when you try installing postgresql again and view the instructions in it. Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it.
I had this issue when trying to install the 32 bit version on Windows 7 64 bit.
Trying the install kit for 64 bit presented no errors, but the solutions presented by others are also valid.
In my case I've downloded McAfee removal tool
MCPR (McAfee Consumer Product Removal)
which cleaned up some tailings after McAfee uninstallation.
Some registry entries which previously had InprocServer32 values like 'c:\program files\common files\mcafee\systemcore\...' changed back to its original values:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = C:\Windows\SysWow64\vbscript.dll
After that I successfully installed PostgreSQL 9.3
it happens when Notepad++ associates .vbs file types.
you can open notepad++ -> Preferences -> fileAssociation
Remove the .vbs from the registered exts.
Close the notepad++. Try installing Postgres again.
In my case Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it. BlueFish is grab .vbs file association.
In the temp directory, my bitrock_installer.log file had the following:
Executing cscript //NoLogo "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs"
Script exit code: 1
Script output:
Input Error: Can not find script file "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs".
Turns out that Windows has a symlink between the following directories:
C:\Users\cpetrie\Local Settings\Temp
C:\Users\cpetrie\AppData\Local\Temp
For some reason my "TMP" and "TEMP" user variables were referencing the "Local Settings" path instead of the "AppData" path. Changing this fixed my install issue.
My problem was Smad-Av which disables Windows Scripts from running,
Only after going through this thread i remembered.
I just right clicked the Smad-Av icon and selected Allow Windows-Script & Office-Macro (Permanent).
I had the same problem with installing PostgreSQL (Unable to write in TEMP environment variable path), the problem was in Windows Script Host which was disabled (check the log file to see if this is your problem). enable it with register editor (run-->regedit) at this location Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings by setting its value at 1
For more details check this web link: http://1stopit.blogspot.com/2011/01/postgresql-83-and-84-fails-to-install.html
I had the same problem in Windows 10 and the culprit was the OS's permission, or rather the lack thereof, on allowing the executable to write on the User dedicated Temp folder.
Solved it by following my gut and changing the User Temp folder to the same with the system's : Win + Pause/Break to have the Computer Properties window appear (you can do that manually by right-click on Computer icon on Desktop -> Properties) -> click on Advanced System Settings on the panel on the left -> click on Environment Variables and
under "System variables" - Variables, find the TEMP and TMP ones and copy their paths. Then, under "User variables for Administrator" - Variables, find the TEMP and TMP ones and paste the paths. It's most always "C:\Windows\TEMP" anyways ;)
There's this site I read : https://www.askvg.com/where-does-windows-store-temporary-files-and-how-to-change-temp-folder-location/
search for "Registery Editor" and run it.
choose HKEY_CURRENT_USER => SOFTWARE => Microsoft => Windows script host => Setting (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings)
open "Enabled" and change value data to "1".(you will find it with a vlaue of 0).
Happy coding!
Check the log in the system's TEMP directory (provided the installer is able to write into it).
There's lot of information about the errors.
My issue was that VBS files were associated with a text editor (probably the anti virus software is the culprit) .
Here you can find some reg edit scripts to revert to the default behaviour:
http://www.nilpo.com/2009/07/windows-xp/restoring-vbs-vbscript-script-file-file-associations/#more-107
Cheers
My solution is similiar to #5, with an Explantion of how and why McAfee ruins your vbscript registration.
Apparently, when I had McAfee antivirus software on my computer, it bashed the vbscript.dll registration that Windows Scripting Host needs to run .VBS files.
In the exported .REG file:
[HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
#="C:\Program Files\Common Files\McAfee\SystemCore\ScriptSn.20120327211246.dll"
That SHOULD be changed back to "C:\Windows\System32\vbscript.dll" now.
McAfee apparently installs a DLL that hijacks the vbscript.dll in order to try to protect bad scripts from running. When I uninstalled McAfee in favor of Microsoft
Security Essentials, McAfee did not restore the registry paths ("not
my problem"), and the McAfee DLL, of course, was removed from the location during uninstall, so the vbscript.dll registration in fact pointed to NOWHERE and NOTHING.
There has to be a better way to write Antivirus software so that it doesn't disable the user's operating system when it is uninstalled, or when features
are turned off, or replace registration. See the following:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
I have a 64-bit OS. The registry path was changed in a number of locations.
The regular class ID should point to the "C:\Windows\System32\vbscript.dll" 64-bit file.
The "Wow6432Node" registry paths should point to the "C:\Windows\SysWOW64\vbscript.dll" 32-bit file.
Yes, the 64-bits are in the "32" folder and the 32-bits are in the "SysWOW64" folder. Microsoft didn't want to change the name of the main "System32" execution folder when it migrated to 64-bits.
HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
Before you start messing with the registry, check if WSH is actually disabled or not. To do that run wscript.exe in the DOS box.
If you see a dialog box called "Windows Script Host Settings", WSH is enabled, and your problem with PostgreSQL installation must be related to something else.
If you get an error box that says "Windows Script Host access is disabled on this machine. Contact your administrator for details", WSH is disabled, and your problem with PostgreSQL installation may be related to it (or may be not).
For me, my problem was related to Windows script. I resolved this by right-clicking on smadav icon in the hidden icons in the task bar and checked "Allow Windows-script and Office-Macro (Permanent)". Then double click on the PostgreSQL setup again.
First go to registry Editor then choose HKEY_CURRENT_USER > software > Microsoft > Windows script host > setting > default > add value data to 1 and click Ok. done!
After disabling Smad Av, it still did not work. So, I right clicked on the Smad Av tray icon and I selected 'Allow Windows-Script & Office-Macro (Permanent)' and it worked.
Here are the error details:
In the Error List:
Error 1 Cannot register assembly "C:\Users\cboardman\Documents\Visual Studio 2008\Projects\ExcelAddIn1\ExcelAddIn1\bin\Debug\ExcelAddIn1.dll" - access denied. Please make sure you're running the application as administrator. Access to the registry key 'HKEY_CLASSES_ROOT\ExcelAddIn1...' is denied. C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets 3019 9 ExcelAddIn1
In the Build Output:
Target UnmanagedRegistration:
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(3019,9): error MSB3216: Cannot register assembly "C:\Users\cboardman\Documents\Visual Studio 2008\Projects\ExcelAddIn1\ExcelAddIn1\bin\Debug\ExcelAddIn1.dll" - access denied. Please make sure you're running the application as administrator. Access to the registry key 'HKEY_CLASSES_ROOT\ExcelAddIn1...' is denied.
Done building target "UnmanagedRegistration" in project "ExcelAddIn1.csproj" -- FAILED.
From what I have found online, I need to be running Visual Studio as administrator. This seems like a big hammer for a small nail. Is there a way around this (like a way to run just the registration as administrator)?
Unfortunately there is not an easy way to do this. By default registering the components adds entries to protected keys in the registry (under HKLM in particular). This cannot be done without administrative rights.
It is technically possible to register COM components as a non-admin by using the equivalent keys under HKCU. However it is not a trivial change and I do not believe the .Net tools which register the assemblies can be configured to do this.
I think your best option is to disable registration during build. Then have a separate Admin window open where you can hand register the DLL From for debugging purposes. The re-registration is only really necessary if you change the COM related interfaces or location of the DLL so it doesn't have to be done for every F5.
Closing Visual Studio and re-opening right-clicking on it -> Run as Administrator solved the problem for me.
I had this same problem with Visual Studio 2017.
JaredPar's answer led me to this implementation:
Goto the project's properties
Select Build
Untick Register for COM interop screenshot
Select Build Events
add a Post-build event command line:
for /f %%a in ('dir %windir%\Microsoft.Net\Framework\regasm.exe /s /b') do set current_regasm="%%a"
set command=%current_regasm% $(TargetPath) /tlb:$(TargetDir)\$(TargetName).tlb /codebase ^; sleep 2
set elevated_command="Start-Process PowerShell.exe -Wait -ArgumentList \"-ExecutionPolicy Bypass -Command %command%\"
powershell -noprofile -ExecutionPolicy Bypass -Command %elevated_command% -Verb RunAs"
In the drop-down run the post-build event: select: On successful build screenshot
Run a build
At the end of the build you will see a powershell window run as administrator (depending on your settings you may have a User Account Control (UAC) popup asking you to confirm before it will run).
Note:
This will find the latest .NET framework version and use regasm from there (credit: Scott C).
Increase the ; sleep 2 if you want longer to look at the output to confirm the registration (or use ; pause instead).