In VS2010 Beta 2, from the Help Library Manager, after selecting local help, and downloading the VS Documentation, it won't launch.
Here's what I have installed:
Here's what I'm clicking in the Start Menu:
Here's the result:
Ideas?
Thanks,
Adam
I recommend reporting this bug on Microsoft Connect so that the Visual Studio product team can take a look at this.
This seems like a rather specific problem and not a general programming question.
I also had problems with VS 2010 Beta 2 help, or rather with MS Help 3, which is new with 2010 . There is a known issue with the Help Listener Service trying to listen on port 80. MS document a procedure to change this port, and my help was back up after following it. From the the ReadMe_ENG.htm file that is installed with MS Help:
Removal of Help 3.0 will not remove content from user's machine;
they should run HLM to remove content
Product Documentation shortcut will not work after uninstall of Help
3.0
Help Library Manager requires the BITS service to be running if you
want to use the “Check for Updates” or
“Find Content online” features.
Removing content and installing
content locally does not require the
BITS service.
Help Library Manager will hang if you attempt to install offline
content but there is not sufficient
disk space for the BITS service to
download the content
If port 80 is used by another process (not via the http.sys service)
then the Help listener will not be
able to attach and use port 80 and
will fail. The port number can be
changed by adding a string registry
value ListenerPort under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Help3
with the value of the port to use (eg.
81). Due to the http.sys ACL settings
it is necessary to run the following
http.sys configuration command from an
admin elevated command line. On
Vista, Win2k8, and Windows 7 run the
following native command: netsh http
add urlacl url=http://127.0.0.1:/help/ sddl=D:(A;;GX;;;WD)
On Windows Xp, and Win2K3 run the
following command:
httpcfg set urlacl /u
http://127.0.0.1:/help/
/a D:(A;;GX;;;WD)
If the command is not found then it
might be necessary to download the
httpcfg.exe from Microsoft as part of
the Windows XP Service Pack 2 support
Tools
(http://www.microsoft.com/downloads/details.aspx?amp;displaylang=en&familyid=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en).
Now the Microsoft Help Listener will
run on the selected port number.
ADDENDUM:
I also ended up installing MS Help 3 manually, and using the Help->Manage Help Settings menu command. On the VS 2010 installation 'disk', I ran WCU\Help\HelpSetup.exe, after removing help via Add/Remove programs. Note the folder HelpSetup installs to, and then in VS 2010, open the Help Library Manager (Help->Manage Help Settings), then Find Content on Disk, and then supply the location HelpSetup installed to. Help 3 will take it from there.
Related
I want to use Graphics diagnostics tools in c# application. In VS 2015 Community, Debug -> Perfomace profiler. Then I click to GPU Usage and start application. "The Graphics Tools opnational feature needs to be downloaded and installed". Ok. Error in installer: "The Graphics Tools faild to install. The DISM installer reported error 87". And link to msdn how to solve a problem. I do all what I see in instruction, but there is a trouble at step 3. There is no components for installing. Why?
System: windows 10 corporate,
Version 1607,
Build 14393.447
Thank you!
I get the same issue because my machine is in a domain with some policy limits. After I remove the WUServer value from the registry key of HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, the Graphics Tools will be listed in Add New Features list.
Please check whether your machine is in a domain with some policy limits. If there has a WUServer value set, it means your machine is managed by the domain policy, please contact your company IT supporters to remove this limit.
go regedit → HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU and change UseWUServer to 0, after restart you will able to install Graphics Tools from Add or Remove Programs → Mange optional features → Add a feature. After successful installation change UseWUServer back to 1 and reboot your machine.
To install graphics tools needs enable and start > Firewall and Updates at Windows Services. After all stop and disable this services.
Here guide how install >> https://learn.microsoft.com/en-us/windows/uwp/gaming/use-the-directx-runtime-and-visual-studio-graphics-diagnostic-features
Or video at youtube >> https://www.youtube.com/results?search_query=graphic+tools+windows
I'm trying to use this Visual Studio extension for 2013, which recreates the built-in installer functionality from Visual Studio 2008/2010: http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx?CommentPosted=true&PageIndex=2#comments
It works, allowing me to edit the project as before. It has the install and uninstall commands when right-clicking the install project, too. It installs fine.
When I try to uninstall, though, I get the following error and then the uninstall rolls back:
Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Wow6432Node\Microsoft\
EAPSIMMethods\18\FastReauthContext. Verify that you have sufficient
access to that key, or contact your support personnel.
I am not doing anything with that registry key, and there don't seem to be any relevant results on google-- at least not in the normal top 5 pages. Does anyone know what causes this or how I can fix it?
While I am not able to uninstall, I am able to increment the version of the package and allow it to remove the previous install and install the new version (all at once) successfully.
I am using Windows 8.1 Pro 64 bit, the projects are compiled for <AnyCPU>, and the installer is configured for x86.
EDIT I am running Visual Studio as Admin. When uninstalling from the Control Panel, I am also clicking the 'allow' button in the UAC dialog window that pops up.
I know how to give myself access to a registry key (permissions). I want to know why this key is trying to be removed. I support this app on several machines and I don't want to have worry about remembering an uninstall hack in the future.
EDIT This only seems to be an issue for a 32x installer on a 64x OS or a Windows 8 issue. I was able to use the same 32x installer to successfully uninstall the app on a 32x Windows 7 machine.
This must be an environmental problem, that key doesn't have anything to do with installers. EAP-SIM is an authentication protocol for wireless networks. The FastReauthContext key almost surely was meant to avoid having to provide a username+password each time your machine reconnects to the network. Which makes the registry key content very sensitive of course, it can only be read by a service that runs with the System account.
So, something goofy going on with your networking setup. Verify that you can successfully reconnect to such a network. If you used a VPN before then make sure it is active again. Something like this. Update your question with anything that might be relevant to networking when you first installed the app.
I have had similar problem and what I found out this is caused by MSI attempting to delete whole "Software\Microsoft" section in the registry. Lucky you that it encounters this error and rolls everything back.
So the solution is the following:
Since you have installed your program whenever you try to uninstall it the system will run msi from cache that is usually located C:\Windows\Installer.
Find your package in the cache. Here is an article that may help you http://csi-windows.com/blog/all/27-csi-news-general/334-identifying-cached-msi-packages-in-cwindowsinstaller-without-opening-them
Open the package in Orca. You must do this as administrator.
Go to Registry table and find record with "Software\Microsoft" as a key. Most likely the Name column will contain either "-" or "*" value. This means that during uninstall MSI will try to delete whole "Software\Microsoft".
Either change the Name value to empty or "+" or try to change key to something like "Microsoft". The second option will cause that installer will not find the key to delete during uninstall, but it will skip this error and let you uninstall your program.
You installed an untested installer on your dev machine? Speaking from experience, don't do that! Snapshotted VM's are cheap and will save you from this sort of pain.
Visual Studio Deployment Projects (or VSI as it's now called ) is known for creating very poor quality installs. The combination of those two put you where you are today.
I would need to look at the full uninstall log and your MSI using ORCA to understand exactly what is going on. MSI Zap and a manual cleanup of resources is probably required at this point.
While installing my msi i get the follwing error
Error 1935. An error occurred during the installation of assembly component {98CB24AD-52FB-DB5F-A01F-C8B3B9A1E18E}. HRESULT: 0x800736B3. assembly interface: IAssemblyCacheItem, function: Commit, assembly name: Microsoft.VC80.CRT,type="win32",version="8.0.50727.42",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"
I do carry Microsoft_VC80_CRT_x86.msm in my MSI. But the problem is that i do not see this issue in all machines. This is faced only on a 2012 Windows Virtual machine.
Can anyone please tell me why this error would normally come?
I think you have a corrupted windows O/S. Otherwise it is correct to test on VM's configured with a variety of virgin operating systems that you want to support. Additionally I highly advise to never use this merge module. Instead using a bootstrapper/chainer (WiX Burn, InstallShield Setup Prereqs or Suite Installation ) to install the stand alone versions of the redist from Microsoft. This helps draw a line in the sand between a Microsoft problem and a problem with your installer. It also makes upgrade servicing easier.
I got the same error message on windows 7 (32bit).
This was caused by a failure in windows update for my case.
After that, I cannot install any other program on the computer. I searched from internet and found suggestions made by Microsoft engineers: repair the system from Original Installation disc with "update to latest" choice unchecked.
However, I found another simple solution which also works for my case.
1． Click START>> and type “regedit” to run register editor;
2． Find the following directory in register: HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control;
3． search by F3 for the key RegistrySizeLimit and double click the DWORD;
4． Change the key value into ffffffff(Hex) or decimal 4294967295, then click OK;
5． restart the computer;
6． run cmd.exe with Administrator's privilege, and type SFC /SCANNOW followed by Enter in command line; this scanning may take several minutes until the status is 100% and finishes;
Then the problem can be fixed!!
I got this error in my Win7x64 VM after I installed .NET Framework 4.5 required by my MSI. I had a fresh OS install with no Windows updates, plus VS2005 SP1. I ran this Microsoft FixIt: http://support.microsoft.com/kb/976982/en-us, but it did not help until I restarted the VM. Once I restarted the VM, the error disappeared. I think all I needed was a restart, but I provide the above details in case it was the FixIt that actually fixed it.
On a windows 2016 server, I solved the problem by resetting DCOM security to default
launch dcomcnfg
then set Default Authentication Level to Connect
and Default Impersonation Level to Identify
I've just installed Windows 7 x64 Ultimate on my desktop PC. I installed IIS, Visual Studio 2008, registered ASP.NET, etc.
I have this ASP.NET 3.5 website I'm working on running EXTREMELY slow on this new IIS. On STA and PROD servers (Windows 2003 Server) and on my old XP/IIS 5.1 everything runs smoothly.
A page which usually takes 1-2 seconds to load is taking 8 seconds!!!
I saw this post on IIS forum. It says something about Vista/7 not pooling connections (just to let you know, the website is running locally but it's connecting to a SQL Server 2005 hosted on a remote server).
It seems that it takes a while to "start loading" the page... I mean, I click refresh and it stays for several seconds "Waiting for localhost"... Then when it gets response it loads the whole page normally...
I don't have a clue how to force Win7/IIS7.5 to pool database connections.
EDIT: I've created a new empty ASP.NET web application to see if the problems happens too. The answer is no, it responds fast as it should with an empty default page. Maybe is something related to the DB connection. I will do a further test. It should be a way to fix it...
EDIT 2: Debugging the app I noticed that the delay occurs AFTER the execution of .NET code (Page_Load, etc)... so the delay seems to be somewhere when IIS serves the page to the browser.
For those having the same problem, here's two possible solution.
1) Disabling IPv6 support in Firefox (only for Firefox)
Most of the authors that I found out about suggest this approach as quickest and cleanest solution. What you need to do is basically to open configuration settings in Firefox (about:config) and to change network.dns.disableIPv6 setting to true.
2) Change localhost settings in your hosts file (all browsers)
This came to me as an idea to check where and how can I interfere in IPv6 settings on my machine. I saw one of the comments on above mentioned sources saying that one can get rid of the problem by simply replacing localhost with machine name in the url.
It didn’t take me long to check and see that disabling my IPv6 localhost lookup does the same thing as disabling IPv6 directly in Firefox.
What you need to do is basically to comment / delete this particular line in your hosts file:
#::1 localhost
Note: ::1 notation is IPv6 equivalent of the IPv4 127.0.0.1 lookup address.
I believe the second solution might be more suitable for users who do not want to disable IPv6 in general, and the first one for all others that still do not use IPv6 in their regular work.
I was having the same issue: extremely dead slow site performance using IIS 7.5 on Windows 7 64-bit with a Core 2 Duo with 4GB RAM and 3 Application Pool Processes running only 1 website. Here's what I did to get the speed back to IIS, problem solved...
The trick for me was to run IIS using 32-bit workers, as instructed by Microsoft on IIS.net, which you can read here:
http://learn.iis.net/page.aspx/201/32-bit-mode-worker-processes/
Simple solution provided (I don't want to rewrite it here)... Either you can run a 1-line command from the Windows Command Prompt or a 1-line command from Windows PowerShell. I just ran it from the command line (make sure you open Command Line or PowerShell as Administrator -- right-click > Run as Administrator).
Thanks,
Marty McGee
You can try running multiple processes as application pools:
Open IIS
Click Application Pools
Right click the app pool for your app
and click Advanced Settings
Find the
"Maximum Worker Processes" and update
it to 3 (or the number of processes
you want to allow to run).
I know the op was running IIS 7.5 and this may not apply to him, but I'm posting this as it might help others running IIS Express 8.0. I had the same problem and none of the IPv6 or hosts file changes worked for me. My asp.net MVC4 project was really slow after hitting F5 to refresh js changes on localhost. It was happening across all browsers - Chrome, FF, and IE. Eventually I discovered that IIS Express 8.0 is extremely slow when serving up js files and seems to be a bug. If I ran iisexpress on the command line and hit F5 I could see each js file took 4 or 5 seconds to load.
I ended up uninstalling IIS 8.0 and installing IIS express 7.5 and straight away the problem was fixed. Here are the steps I followed:
Uninstall IIS express 8.0
Delete the IISExpress folder (on Win 7 it's in My Documents\IISExpress)
Install IIS express 7.5 (Link to IIS Express 7.5 download)
IIS Express 8.0 seems to be installed with VS 2012 so if you had a new install or possibly a service pack update this might upgrade the previous IIS Express version.
This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):
LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". in light.exe(0, 0)
The FAQ is now deleted, however, the text from it said:
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Additionally, these are the errors that show up in the event log:
MSIInstaller: Failed to connect to server. Error: 0x80070005
Product: [ProductName] -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
Intuitively:
VBScript and JScript were registered under admin.
Integration service has permissions for the desktop interaction and all the files
Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)
I'm out of ideas so far.
How do I solve this problem while keeping ICE validation?
End of the story:
After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.
To disable ICE validation you can set SuppressValidation to true in the .wixproj file:
<PropertyGroup>
<SuppressValidation>true</SuppressValidation>
</PropertyGroup>
Or pass the -sval command line option to light.exe.
Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.
I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..
It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).
It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.
Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.
The problem can be easily reproduced:
Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
Launch cmd.exe
Execute the batch file you created
From the same cmd.exe window:
Try building the MSI package using WiX with ICE validation on OR
Run smoke.exe to validate your package OR
Simply run msiexec /i Package.msi
All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.
So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:
set > environment.txt
The goal is to get file environment.txt smaller than ~30 kB.
The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:
Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:
ICE validation needs an interactive account or administrator privileges to be
happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).
imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.
I got the same error on Windows Server 2012 Datacenter as Build Agent.
To solve the problem :
List item
Go to Environment Variables on the build agent machine
Create two System Variables
"PF86" which is equal to "C:\Program Files (x86)"
"PF" which is equal to "C:\Program Files"
They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
Close and build and enjoy!
It worked for me. :)
UPDATE
I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.
I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.
From http://wix.sourceforge.net/faq.html#Error217:
In WiX v3, Light automatically runs validation--
Windows Installer Internal Consistency Evaluators (ICEs)
--after every successful build. Validation is a
great way to catch common authoring errors that can lead to service problems,
which is why it’s now run by default. Unfortunately, there’s a common issue
that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to
fail. For details on the cause and how to fix it, see
Heath Stewart's Blog
and
Aaron Stebner's WebLog.
I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service.
This solution worked for me:
http://support.microsoft.com/kb/315353
Log on to your computer as an administrator.
Click Start, and then click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type msiexec.exe /unregister, and then press ENTER.
Type msiexec /regserver, and then press ENTER.
Restart Windows
Also, verify that the SYSTEM account has full control access permissions to the
HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.
I have some suggestions.
Try updating the Microsoft Installer version on the build server
Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...
I got this error from my Azure build agent running on-premises.
My solution was to upgrade its user account from "Network Service" to "Local system account".
Go to your build machine and restart the Windows Installer service
None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:
Some of the WiX ICE validations are implemented using VBSCRIPT.
So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
Chances are that somehow the user that runs your build lost access to this DLL.
As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.
Here are the steps that I took to fix the issue:
Open cmd (run as admin) on the build agent machine.
Run RegEdit
Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
Look for the InprocServer32\Default Key
On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry
Once I updated the path, everything started working as usual.
My solution is similar to Vladimir's one. My CI user was admin of the computer.
But the following steps were mandatory to allow my jenkins build to succeed:
log in as CI user using rdp
open a dos command prompt
execute: %windir%\system32\msiexec.exe /unregister
execute: %windir%\system32\msiexec.exe /regserver
then i got a successfull job