Are there any tools for completely removing an Interbase 2009 SMP installation? I found an article describing how to remove IB6 (http://edn.embarcadero.com/article/28131), but I'm reluctant to delete anything in the registry according to a document which applies to another version of IB. Are there any equivalent descriptions for IB2009?
I guess you've run the uninstall and just want to clean up the registry.
You could try CCleaner. select registry and scan for Issues.
If its the first time you've run it there will probably be many unused entries.
If you're worried about changes then unselect all and just choose the ones related to IB.
Make sure you choose "Back up changes to registry"
Try RevoInstaller. A very good program to cleanup register and files after an uninstall. Note that you should run this program directly when uninstalling. It calls the applications uninstall routines and the cleanup afterwards.
Related
I am trying to uninstall Crystal Report for Visual Studio 2011, and install Crystal Report for Visual Studio 2019. I got the error message of "Error applying transforms. Verify that the specified transform path are valid." when uninstalling the program. Therefore, the newer version of Crystal Report for VS 2019 can't be installed.
I searched around and some posts says about windows registry entries caused the problem. I can't find out a solution on what to do.
Highly appreciate your response.
Crystal Reports: I am wondering if you have installed from a network share that is no longer available, or one where the UNC path specified to your transform is blocked or in other ways incorrect. What you need is a proper log file. Please see below. And have a quick peek here: https://apps.support.sap.com/sap/support/knowledge/en/1220433
There are also some issues with secure transforms and complications arising from this and newer Windows settings and security features. Maybe have a quick look here. Just a few links on the topic.
How many machines do you see this on? Just your own?
Preparation: A couple of things first:
Reboot: Do a reboot before attempting the next uninstall. Just to have a clean slate. Allow system to settle after reboot (give it a couple of minutes to settle down).
Corrupt installation files: Re-download your new setup to make sure its installation file is not corrupted. Try to malware scan it too. And finally set it unblocked as shown here.
Admin Rights: Second, make sure you run with proper admin rights? Run the msiexec.exe command from an elevated command prompt. Please launch an elevated cmd.exe (right click => run as administrator).
Anti-Virus: Disable your anti-virus first to prevent any locks from failing your uninstall.
Debugging "Ideas Lists": Common causes of setup runtime issues
Logging: Now the most important. You must also ensure proper logging for the uninstall effort. You can either use logging by policy
or define it at the command line level. It would be best to enable the
logging policy so the log file is automatically created in the tmp
folder. Please see this answer for more on logging.
When you have done the "Preparation" above, please run the
uninstall and create a proper log file. Here is the command line
(prefer the policy):
msiexec.exe /x "mysetup.msi" /L*V "C:\Temp\msilog.log"
Please open the log you created (or get the log from the temp folder
if you have logging policy enabled). Then inspect the log and match
against this sample log here:
https://www.itninja.com/question/transform-issues
What do you see? Just read line by line and don't be intimidated by
all the "line noise".
Common Technical Issues: If you have problems with all other MSI packages and their operation, you could have a bigger problem. Then you should rule out some runtime issues. Note that some issues are commonly caused by malware (or just technicalities that occur randomly sometimes):
Visual C++ Runtime - reinstall it. There are many versions. See what your package needs. The latest supported Visual C++ downloads.
Unregister / re-register msiexec.exe (can be necessary because of malware or normal technical glitches).
Run chkdsk.exe and sfc.exe to check for file corruptions and corrupt OS files.
Microsoft FixIt: You can use the Microsoft FixIt method as a last resort to clean out your existing installation. This generally works (unless you have hacked too much already), but is not ideal: http://support.microsoft.com/mats/Program_Install_and_Uninstall/ - this approach does not clean up or uninstall, it just unregisters the installed package and leaves all its files and registry settings in place. You can try to install the new version, but some interference issues are likely with the garbage left behind. Yes, you can try to clean up manually, but I would just try to overwrite first.
Links:
What is the root cause of "Error Applying Transforms. Verify that the specified transform paths valid"?
All About the Four Types of MSI Transforms
"Error applying transforms. Verify that the specified transform paths are valid."
I see that there are way to Get Get-AppxPackage or Remove Remove-AppxPackage UWP app from windows 10 using PowerShell.
I am wondering if there is a way to reset a UWP app? I require it for automated testing, I would rather reset the UWP app than uninstall and install again, as that would slow down the testing.
If you're looking to clear your package's ApplicationData then you want
appdata = Windows.Management.Core.ApplicationDataManager.CreateForPackageFamily(pkgfamilyname)
appdata.ClearAsync()
See MSDN for ApplicationDataManager.CreateForPackageFamily() and .ClearAsync()
Powershell has no 'await' affordance last time I looked (though it's been a while) so not so viable. If you're looking to muck with applicationdata you may find APPDATA.EXE handy. You can probably guess why I wrote it... :P For instance
APPDATA.EXE Clear foo.bar_1234567890abc
If you're looking to reset a package to its initially installed state, then no, there is no API other than uninstall + install
Remove-AppxPackage foo.bar_1.2.3.4_x86__1234567890abc
Add-AppxPackage foobar.msix
Settings' Reset option for an installed package essentially does that just slightly more efficiently. You're still going thru the full deregister and uninstall the package and then install and register it for the user so it may not be instantaneous. But that's the only way to truly reset a package to its initial state. Windows has various forms of user data associated with a package (ApplicationData, IndexDB, more) as well as system state cribbed and wired up when a package is installed for a user (what is the package, where's it live, that the user has it, that it's status is not tampered or otherwise unhealthy, more). The only way to truly 'reset' that to the initial state is a full remove then add.
If you just need to wipe appdata then .ClearAsync is the ticket.
I am not aware of any command that would do that for you (except for the UI available in Settings app). However, you may write a PowerShell script that would clear up the application data files in the app's folder (this is not an official solution, but seems to work based on my trials).
Go to
C:\Users\{your_username}\AppData\Local\Packages\
And find your app's folder there. There are several folders containing the application state.
The nuclear option is to just delete all the folders. Then the app will crash once on startup, then the system will automatically reset it and restore the folders.
The less invasive option I have now tried seems to be to keep the folders and just delete their content, except for the AC folder, which seems to be system protected. When I tried this with my app, it launched successfully without crashing and system recreated the state files anew on its own.
The rest of application files lives in C:\Program Files\WindowsApps, but those are just application DLLs and content files and are read-only, so they should not affect the app state at all.
You may want to perform additional deletion if you use a shared publisher folder.
For windows 10 build 2004+ there seems to be a powershell command Reset-AppxPackage now.
UPDATE
My mistake, it is available from version 20175 onward. So, should be available in 20H2.
We are in process of upgrading Sitecore 6.6 to 7.2. Part of upgrade is to migrate all the media items from 6.6 to 7.2.
I tried creating a package but the package size is too large and times out on package installation.
I found link below using Powershell Console where it shows copy-item command:
http://blog.najmanowicz.com/2011/11/18/sample-scripts-for-sitecore-powershell-console
I attached the 6.6 to 7.2 version where I can access the 6.6 DB. However copy-item doesn't seem to support different databases.
Could someone please help how I can use SiteCore Powershell or similar to migrate media items from 6.6 to 7.2?
I had a similar issue with a (very large) media library with a similar migration. Packages seems to bomb out around the 2GB mark, instead serialize the items:
Delete everything from /Data/Serialization
Open the media library. Makes sure you have the Developer tab
showing (right click somewhere on the toolbar and enable it
otherwise)
Select your root media item then Serialize Tree
Wait...
Copy the serialized files from /Data/Serialization to your new
server
From the toolbar select Update or Revert Tree depending on your requirements
Profit.
You can find more info in the Sitecore Serialization Guide and this post by Brian Pedersen
You should be able to do this in Powershell too (from my understanding). You need to:
Add the database to your connectionString.config
Add that database to your web.config to <sitecore><databases><database>. You can copy the existing master node and rename the id attribute to match your conneciton name
Your legacy database should now be connected to Sitecore interface, you can check it is present in the database selector list from the right of the desktop
The powershell command now needs a "from" and "to" location. Assume your database is called "legacy_master", the following should work:
copy-item "master:\media library\*" "legacy_master:\media library\"
I've found Hedgehog TDS (and sometimes Razl) quite useful for doing this.
Create a new TDS project (don't version control it), and download all the items you need to your local machine. You can for example connect the "Debug" build to your source 6.6 instance, and a "Release" build to your target 7.2 instance. Then you can just synchronize the items to your target machine. It's sometimes good to synchronize one or a few branches at a time if you have long latency connections.
The good thing about this is that you're in total control of your content and can see what fields are updated etc. During an update process, it's sometimes useful to compare other parts of the db as well, just to ensure you don't miss any changes you've made to the platform.
Since I mentioned Razl as well: I've found Razl quite good if you have a whole branch that you know should be transferred from one db to another (such as the case you describe). TDS is a bit slower, but more universal - and you may have a TDS license already so it may not be worth an additional Razl license.
I've just added item transfer from one DB to another so you can Copy-item between databases starting with Sitecore PowerShell Extensions 3.0. Thanks for the great idea!
Just to add another option you can perform tasks like this using Revolver.
WARNING: Try this in a test environment first
if we assume that:
the context item is the media library item
the current database is master
the target database is called master72
then something like this should work:
cp -r -n master72/sitecore/
I recently uninstalled, then re-installed WAMP, But now my domains(zend projects) are malfunctioning. I can only access the front pages for these domains but not any further pages, which I explained in a previous thread Everything suggested on the thread and more have not worked so far.
So I have another idea from searching google which suggests that WAMP has not been completely uninstalled when I did the first uninstall, and the solution is to go to regedit after uninstall, do a search for "wamp" then delete all records related to wampserver. I'd done this but I'm getting 216-records and only three of them has a mention of "wamp" on the record names. I feel it can't be right to delete all 216-records and i'm scared because these records point to other programs and systems in windows. But this blog seems to suggest that I delete them all as below:
...into the registry. Highlight 'Computer' and press the [Ctrl][F]
key combination to launch a search box. Type in 'wamp' as a search
term. Delete all instances of a record pertaining to WampServer. On
a healthy installation, there may be 70 such entries or more. Just
grit your teeth and get it done, making sure all the while that the
search result is indeed a WampServer related entry...
I have deleted the 3-records I found with mentions of "wampserver", but yet no solution to my problem. So my question is: Could the instruction possibly be to delete the entire 216-records in order to completely clear my system of all traces of the old WAMP installation?
Removing WampServer should consist of:
stopping and uninstalling the services (wampapache and wampmysql) either with the uninstall services batch file included or on the command line
deleting the wamp folder
Bear in mind any changes to:
Your web root folder(s)
Your hosts files
Your firewall
Now, if you've done the above and have problems still, it'll likely there are other problems. Such things as different httpd configs, .htaccess files, different versions of wampserver and components like PHP and it's modules, databases and their security credentials, etc.
Check the above, and if there are more specific errors feel free to post them too.
Thanks guys for your time. I think my actions as in the OP were successful in completely uninstalling wampserver. Just that my fresh instal of WAMP was mis-behaving and not finding pages beyond the home page. It's been sorted by enabling mod_rewrite. Though I'm not quite sure what went wrong as I'd applied the same mod_rewrite severally without a resolution.
I have an MSI package I maintain with Installshield 2012 Pro.
The package was created a few years again and requires periodic maintenance as new versions of the application is installs are released by our development team. This MSI has been used in many locations, on many machines without issue.
At one customer location, they've install about 20 copies of the application on 20 machines. Each machine is built exactly the same.
Periodically, for an unknown reason registry entries relating to that application go missing. Not all of them, a select one or two... the same entries always go missing.
We so far have failed to track the exact root cause, however one of our support engineers noticed the MSI repair dialogue appearing when they opened the application shortcut. Following this, the registry entries went missing.
On each instance of the registry entries going missing we have removed the MSI from the c:\Windows\Installer directory. On machines we've made this change too, the registry changes so far have not disappeared again.
This leads me to think the MSI is somehow removing the selected registry entries during the repair, but I don't understand how.
There are at least 50 registry entries under the same key as the entries that get removed. (these are created by the application not the installer)
The MSI package doesn't insert any keys at all during install
There are no custom actions at all
I only have one key file set in the whole MSI, and this is for a component installed in Windows\system32
None of the shortcuts are 'Advertised'
There appears to be a clear link between removing the MSI from the Installer directory and no further occurrences, but I fail to see what in my MSI could cause specific registry keys to disappear.
I realize the exact reason this this is subjective to my MSI or the customers systems, so as generally as possible I ask:
Why would Windows launch the MSI repair function, considering the above
Can an MSI alter the registry, considering the above
Is there anyway post installation of an MSI to disable the auto repair function for this MSI?
How should I alter the MSI to ensure auto repair doesn't occur?
Thanks
Start by proving whether the auto repair is related to your product. Check the application event logs for the component id that caused Windows Installer to kick off the auto repair. Then, if it's part of your installer, figure out why.
It seems unlikely that your MSI would alter the registry. Although you do not specifically say there are no RemoveRegistry table entries, it's hard to imagine any snuck in accidentally.
There are only bad ways to disable auto repair (some global, some involving not registering your installer). Avoid them.
First figure out what's wrong. Then figure out how to fix it. For instance if in step 1 you determine the component triggering auto repair is part of your install, perhaps set the logging policy on a machine where this occurs so you can get a verbose MSI log.