So I thought I'd save myself some time in moving my visual studio installation from an old drive to my C-drive. Turns out this was a very bad idea.
I ended up trying the installers to clean up some of the mess, but they won't work, since they can't find all the files they're supposed to remove. This led me to manually delete the 'Visual studio 1x.0'-folders in an attempt to have the installers show 'Install' versus 'Modify', 'Repair' and 'Uninstall'. Now I've tried to do what support suggests on this page, https://support.microsoft.com/en-us/kb/248697, but no luck...
How can I get the installers to... install.. rather than 'Modify', 'Repair' and 'Uninstall', which they won't do anyway, since some (or most) files are missing?
Suggestions appreciated.
I just want the installer to install on C-drive, and possibly overwrite any remaining trash, be it files or configurations.
Software uninstallers sometimes fail to clean up completely. In those instances, a product like Revo Uninstaller should be able to clean up any remaining files and/or registry entries. It scans for any “leftovers” from a standard uninstaller and gives you the opportunity to selectively remove those objects that are preventing you from reinstalling.
Related
When installing visual studio if we already have deleted content of C:\ProgramData\Package Cache directory then whole setup process will be turned into a real nightmare constantly complaining about missing packages. I've searched the web for a solution and the only working one I've found is a tool called install and uninstall troubleshooter.but the problem with it is i have to interrupt setup process and use this tool to remove the package and then get back to setup again which is really cumbersome job to do.
But the good thing is for every package that visual studio fails to uninstall it logs a GUID like this {A2999714-5C2C-3729-A911-4AE198B7B2FD} in the log file.Now better and ideal solution in my mind is looking after an official website from which i be able to download each of these packages by these GUIDEs.Is there such a location in the web? or is there any better solution to solve the issue?
Why did you delete the Package Cache? Do you have little disk space? The Visual Studio installer is so complex that you are fighting windmills trying to fix this I think. Perhaps they have an uninstall tool of some kind that will clean the slate.
Is this Visual Studio 2017? If so, maybe try these links:
Remove Visual Studio
Cleaning up corrupt Visual Studio instances
I doubt it will work since you have deleted the package cache. Note that most MSI-based installers should be able to uninstall without the package cache due to the cached MSI file in the super hidden folder %SystemRoot%\Installer.
Whatever you do do not delete anything from %SystemRoot%\Installer. Then you are in a totally unrecoverable state since this is an internal Windows Installer implementation detail. Do not mess around in here unless you know exactly what you are doing.
The files in %SystemRoot%\Installer are used to uninstall from the Add / Remove Programs Applet.
Further Links:
Visual Studio 2017 Broken and Cannot Uninstall or Repair
have deleted content of C:\ProgramData\Package Cache directory then whole setup process will be turned into a real nightmare constantly complaining about missing packages
Had the same issue, but with vcredist files, couldn't install any drivers without running into errors and eventually couldn't install because install failed.
I found the solution elsewhere. It said to
Fix problems that block programs from being installed or removed
https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
download troubleshooter button on the link.
Run it - choose option - have problem with installing - it lists programs - choose the missing / problematic visual c++ runtimes in the list
it will run and get fixed.
Repeat for each visual c++ you having problems with. I ran the program multiple times.
So I'm in a situation where I need to have VS2017 enterprise installed, but I so happen to have the community version installed already (also 2017 version) with all the extensions and workloads (from the modify menu of the installer) already working in that edition.
So my question is would it be possible to share these across each of the versions so that I don't need to install presumably the same things over again?
I've thought of creating hard symlinks to the folders but I don't think that will work without all the appropriate information in some other files.
Searching only gave me guides on how to import/export plugins to another computer and from what I understand, it's basically just a list of what vs will install on another computer.
I couldn't find a exact fit solution to my problem but I did find a little workaround. Turns out the installer is a little smart this time.
First I compiled vsclone, then I put the output into cmd after installing vs_enterprise.exe.
The modify window should appear and everything is selected, click modify then wait for it to finish. The thing is that the installer surprisingly detects already installed workloads although after installing, microsoft magically adds 6gb of files to the folders it installed to (still better than the 16-17 gb that it would take if it reinstalled everything).
Finally I got a program that could help run symlink /j on multiple folders that included the vs packages after transferring those folders into my d drive (I'm running a laptop so I have very limited ssd space).
Final product works with all workloads installed properly, hope I didn't miss anything important here. I unfortunately didn't analyse the filesystem before hitting modify so we may never know what used 6gb...
I'm desperate to fight against this problem: when I enable nuget on a solution and it grabs missing packages from web, it constantly tries to check-in them to TFS, although I definitely don't want it
There's a lot of advices on the web regarding this problem, but none has helped so far. I've done the setup according to this: http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages, tried to "cloak them" as it is recommended here: http://www.xavierdecoster.com/post/2011/10/17/tell-tfs-not-to-add-nuget-packages-to-source-control - all in vain. I'm stuck. Probably I lack some critical understanding of how does TFS client work with NuGet and VS 2010.
Any help is appreciated. Thanks!
The only way I know is a little bit manual but can be automated at some point.
The big issue is the packages folders being overcrept. You can undo the packages in Visual Studio, the files won't be deleted. There is also a CLI for that:
C:\project\Main\packages> tf undo /recursive *
Do not use this command when you have pending changes on the repositories.config file.
You just need a little .bat file to check for pending changes (repositories.config file) and do the cleaning.
I've given up an any NuGet / Solution based approach to this problem.
I simply setup my workspace so that the packages are cloaked.
For example setting up your workspace like this means Packages is ignored by Source control:
Status Server Path Local Path
Active $/TFS/ C:\Code
Cloaked $/TFS/Packages
Even cloaking the packages folder as DaveShaw suggests can still cause problems, especially when adding packages to large solutions. Best way I've found so far is to create another Visual Studio configuration...
devenv /RootSuffix NoTFS
and then delete the TFS provider for that configuration
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0NoTFS_Config\SourceControlProviders\{4CA58AB2-18FA-4F8D-95D4-32DDF27D184C}
I'd suggest exporting that part of the registry before deleting and make sure you delete it from the NoTFS configuration.
After that you can run Visual Studio when you want without with TFS by starting it with the RootSuffix parameter above.
I have a web setup project built using VS2008. I've converted my solution to VS2010 and now when I build my new installer and run the install from the MSI it installs fine, then at the last step, removes all the files it's just installed.
I have RemovePreviousVersions set to true. If I turn this off the files remain in place (but I get multiple instances in the Programs and Features in the control panel).
If I run the install again, the files reappear. From then on, the files always remain, even when installing another version. So, the problem seems to be with running an installer built using VS2008 and then running the same installer built by VS2010. The upgrade GUIDs on each installer are the same.
What is the cause and how can I fix this?
I haven't tried porting a setup from VS2008 to 2010, but having the same upgrade code for different build versions will cause problems; simple explanation is the msiexec installer fails when it tries to remove the old components because the older components have the same upgrade version as the newer components being installed. There is a VS project setting where you can automatically generate a new upgrade code each time you rebuild your .msi; I generally select this and saves a lot of these versioning headaches.
Uninstall all copies of your app using
add/remove programs
Delete the contents of your %TEMP% folder ( to
get rid of any "old" (VS2008) copies
of your .msi)
Update the GUID for the VS2010 version (I think you do this by right clicking on the
GUID in the properties window and clicking "genereate new GUID")
rebuild the project and try again!
I just encountered this error. Had the exact problem when upgrading. I tried the solution at:
https://connect.microsoft.com/VisualStudio/feedback/details/559575
I edited my MSI-file in Orca resequenced RemoveExistingProducts right after InstallInitialize (sequence number 1501). This was found in the InstallExecuteSequence table. This was originally sequence number 6550.
That solved my problem.
What I've discovered is that changing the UpgradeCode will prevent the files from being removed, however it's then treated as a separate installed program - i.e. in the control panel (Programs and Features) my program appears twice. Logically, I think, this is because it's not the same program.
My only option seems to be to programmatically uninstall the old version in the installer of the new version by writing a custom action.
I've submitted a bug to Microsoft Connect and they've confirmed it's reproducible.
I have a Visual Studio 2008 solution that contains several projects.
Most projects in this solution write a .dll when built.
My installer project in this solution copies these .dlls to a target application directory.
My uninstaller for this solution does not remove these .dlls, even though it should.
My installer doesn't overwrite old versions of existing .dlls, which causes my application not to function.
If I delete the existing .dlls prior to install, the application works well.
I've monkeyed with many many settings in the solution for these .dlls. Nothing seems to work.
I've added extra copy actions to the install project, in an attempt to overwrite existing .dlls. A couple of these extra copy actions can not be deleted, because the delete choice is disabled from the drop-down list when I right-click on them. Weirdly, the original detected dependencies can be deleted.
Any ideas are most welcome.
Thanks,
-Vince