please help anyone what am i missing to remove from my system.
I was using the uninstall functionality from the "Programs and Features" but got the same error. I was planning to reinstall it. After manually deleted the 18c related records from the regedit:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
and running the following commands from the command line
sc delete OracleOraDB18Home1MTSRecoveryService
sc delete OracleOraDB18Home1TNSListener
sc delete OracleJobSchedulerXE
sc delete OracleRemExecServiceV2
sc delete OracleServiceXE
sc delete OracleVssWriterXE
sc delete OracleXEMTSRecoveryService
OracleRemExecServiceV2 (got
error but still okay)
The installer was working correctly for me.
You aren't missing anything. There's no Uninstaller for 11gXE so you'll have to do it manually. According to Documentation (https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW135):
go to Windows Control Panel
run "Add or Remove Programs" or "Programs and Features" (depending on your Windows version)
select "Oracle Database 11g Express Edition"
click "Change/Remove" or "Uninstall" (again, depending on Windows version)
That would be all.
Their uninstaller is broken. After removing from programs and features.. it still leaves the services running. So you have to manually remove them.. before trying a fresh install.
Done manually deleted oracle services and program files but the Oracle installer still detected oracle 18c installed in the system.
In the end found out that, the installer is checking the registry below
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{C220B7FD-3095-47FC-A0C0-AE49DE6E320A}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\DF7B022C5903CF740A0CEA94EDE623A0\InstallProperties]
Before deleting the registry from above, search and remove all the registry keys which having C220B7FD and DF7B022.
No problem reinstall 18c after cleaning up the registry.
NOTE: Follow this only if you are having too much trouble reinstalling oracle_xe and want to install fresh, since it deletes almost all of the data.
First, Stop the Current Running Services:
Open an elevated prompt
sc stop OracleServiceXE
same for other services( LISTENER, JOB_SCHEDULER etc.)
Run Uninstaller from Control-Panel -> Add or Remove Programs.
Or do it from terminal by running msiexec /x {C220B7FD-3095-47FC-A0C0-AE49DE6E320A}
Second, See if there are any remaining services related to oracle, if these exist:
Remove them all by running following commands:
sc delete OracleServiceXE
sc delete OracleOraDB21Home1TNSListener
sc delete OracleOraDB21Home1MTSRecoveryService
sc delete OracleJobSchedulerXE
Third, Remove your install directories and environment variables:
DEFAULT_INSTALLDIR = C:\app\[USERNAME]\product\21.0.0\
Save <INSTALL_DIR>\oradata\XE, If you dont want your local database files to be deleted.
Fourth, type regedit.msc in RUN_BOX -> 'WIN + R'
Delete the keys at following locations:
Delete keys with prefix Ora, Oracle, Orcl, or EnumOra at HKEY_CLASSES_ROOT.
Delete the ORACLE key at HKEY_CURRENT_USER
Delete oracle related keys at HKEY_CURRENT_USER\Software
Delete Oracle group key at HKEY_LOCAL_MACHINE\SOFTWARE
Expand all the subkeys under ODBC and remove any Oracle-related ODBC driver keys at HKEY_LOCAL_MACHINE\SOFTWARE\ODBC except for Microsoft ODBC for Oracle key.
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services, delete keys that begin with Oracle or OraWeb
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Eventlog\Application, delete all keys that begin with Oracle.
These guides are from : Removing_Oracle_Database_Software
Finally, remove local oracle groups if needed:
Run -> net localgroup in cmd.
You will see the list of groups information on your device.
Remove all oracle related groups by:
Running -> net localgroup <group_name> /delete
Group name mostly have prefix ORA_.
This is my first time posting, because I had alot of issues during reinstallation of oracle_xe, and I am not that good with databases.
Do suggest some fixes, if some of the details are not correct.
Here is what helped me:
The reason is simple, the uninstaller only does half a job.
If you run the services.msc utility (Windows +R, type services.msc), scroll down to the Oracle named services and you will see a few that are still there. You need to get rid of those as follows:
start
Search for cmd
Right-click, run as adminsitrator
When it runs:
sc delete service_name
For each and every OracleXE service you see.
Then try the installer again.
Source: https://community.oracle.com/tech/developers/discussion/4209872/cannot-reinstall-xe-18c-after-doing-an-uninstall
when i execute dtsx package through command line i am triggered with the following error saying
1.The connection is not found , the error is thrown by connections collection when the specific connection element is not found
2.Cannot resolve package path to an object in the package "xxxxxxx".Verify that the package path is valid
3.The package path referenced an object that cannot be found , this occurs when an attempt is made to resolve a package path to an object that cannot be found
But this works fine when i run the package through Business Intelligence development studio.
Taking a guess here while I wait on an answer to the comment, generally when a package runs fine in BIDS but doesn't work from the commandline, I find it's related to 64/32 bit incompatibility.
Are you using Excel, Access or anything else that under the sheets uses the JET driver? That only works in 32 bit mode.
On a 64 bit OS, by default when you create a new ODBC connection, you'll be creating it in the 64 bit namespace which the 32bit version won't be able to access?
Are you using Informix or UDB/DB2 drivers? I only ever found 32 versions of those.
Running a package from the command line
dtexec is the command line mechanism for running an SSIS package. It comes in 2 flavors for 64 bit OS, both are named dtexec and generally the 32 bit is referenced in the Windows Path environment variable
On a 64 bit OS, the default path to the 64 bit would be "c:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe"
Still on 64 bit OS, the path to the 32 version would be "c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe"
To run a package named FooBar.dtsx that lives in C:\Src\MyProject\MyProject, invocation would be
"c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe" /file C:\Src\MyProject\MyProject\FooBar.dtsx
If that package lives on SQL Server (DEVSQL01) in the folder MyProject, this would be the call to run the same package.
"c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe" /SQL \MyProject\FooBar /SERVER DEVSQL01
Edit
To apply a configuration, you need to specify the /CONF option
"c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe" /file C:\Src\MyProject\MyProject\FooBar.dtsx /CONF C:\FooBar.dtsConfig
Looking at your comments, the only difference between our usage is you have wrapped everything in double quotes. Try it without the preceding and trailing quote.
type below text to call SSIS package
dtexec /f
/set \package.variables[Variable]; value
Example:- dtexec /f E:\test_package\test_package\Package.dtsx
/set \package.variables[id];1
Reference Ways to execute SSIS package
The /SQL option is for packages deployed to the MSDB -> servername\StoredPackages\MSDB\
I've used the Web PI to install IIS Express. In the tray, there is not the IIS Express icon. How do I start IIS Express without using the command line? I want that IIS runs permanently, so without command line.
See Running IIS Express from the Command Line
Open a command prompt.
cd \Program Files\IIS Express, or
cd \Program Files (x86)\IIS Express on 64-bit OS
iisexpress /? to show usage
For example, you can start your IIS Express named site by issuing the command
iisexpress /site:WebSite1 where WebSite1 is a site from the user profile configuration file (C:\Program Files (x86)\IIS Express\AppServer\applicationhost.config)
Another common way to start IIS Express is to issue the command iisexpress /path:c:\myapp\ /port:80
This command runs the site from the c:\myapp folder over port 80.
You could use a *.bat that you include in your startup folder that starts IIS Express for you (using C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup or the All Users startup folder C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup).
In Windows 7 you can use the Windows PowerShell to hide the command window, for example i use:
start-process "c:\program files\iis express\iisexpress.exe" -workingdirectory "c:\program files\iis express" -windowstyle Hidden
PowerShell script execution is set to Restricted on most new systems by default so you might need to change that to RemoteSigned or something first.
You can also install Web Matrix, which has an administration interface to IIS Express.
IIS Express isn't really meant to be run without some kind of interaction with it - Visual Studio, WebMatrix, or other. IIS Express isn't a service.
If you wanted to automate its startup in Windows, you can do so via Startup directory, or add a new item to the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
C:\Program Files (x86)\IIS Express\iisexpress.exe
You could run this executable ad-hoc if you like, perhaps create a shortcut on your quicklaunch or desktop or other.
I don't think running IIS Express without the command line is achievable unless you're successful in writing a separate program to do it, as some have attempted to do in this related question.
Quoting the online documentation:
IIS Express is a lightweight,
self-contained version of IIS
optimized for developers. IIS Express
makes it easy to use the most current
version of IIS to develop and test
websites. It has all the core
capabilities of IIS 7 as well as
additional features designed to ease
website development including:
It doesn't run as a service or require administrator user rights to
perform most tasks.
IIS Express works well with ASP.NET and PHP applications.
Multiple users of IIS Express can work independently on the same
computer.
You could use srvany to run IISExpress as a service.
Here is a blog post about this (though I haven't tested it yet, it looks promissing).
http://arvinboggs.wordpress.com/2011/04/08/installing-iisexpress-as-a-service-on-windows-2003/
The interesting part is where you pass a /config ... parameter to iisexpress, otherwise IIS Express loads the config from the users documents folder.
If you want your IISExpress to be able to be reachable from remote machines you can either
Start is with admin privileges and edit your applicationhost.config file: http://blogs.iis.net/vaidyg/archive/2010/07/29/serving-external-traffic-with-webmatrix-beta.aspx
Start is a a user and set up an ACL: http://blogs.iis.net/vaidyg/archive/2010/07/29/serving-external-traffic-with-webmatrix-beta.aspx
Use Vb.net 2010
and put this on a button
this will execute the IIS Express console less
shell("C:\Program files\IIS Express\iisexpress", vbhide)
To kill the process
*this will kill the IIS Express *
shell("taskkill /f /im iisexpress.exe", vbhide)
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).