I see it all of the time when installing updates to retail applications, but after searching for two days, I have not found a way to do it. I am trying to create a package with InstallShield LE in VS 2012. One of my customer requests is to warn the user when the program being updated is running, and allow them to close the app (or possibly have the install try to close it). Is there any way to do this (the simpler the better)? Thanks in advance for your help!
This should just happen. However you may need to make sure that you didn't remove the file and re-add it to your installation; instead make sure you update it at the source location and rebuild. (This helps ensure that the underlying component settings remain the same, which may be relevant to Windows Installer's Files-In-Use detection.)
Related
For the last 3 days I have been trying to figure out how to install node.js. I tried every solution that I found on the internet, like disabling certain components during installation, installing both x86 and x64 etc, none of them worked.
My OS is Windows 10 x64. I tried different versions of node.js and they all return the same error shown in the screenshot below.
I tried installing through the command line and got the log. But I could not find anything useful from the log either. Please help.
The log can be found here: this path : https://drive.google.com/open?id=1OkkK36hlQeBX0xTNuOuilGaNr1u3S55e
MSI (s) (74:88) [20:49:45:955]: Executing op: ActionStart(Name=RegisterEventManifest,,)
MSI (s) (74:88) [20:49:45:961]: Executing op: CustomActionSchedule(Action=RegisterEventManifest,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="wevtutil.exe" im "C:\Program Files\nodejs\node_etw_provider.man")
MSI (s) (74:A0) [20:49:45:969]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI33C1.tmp, Entrypoint: CAQuietExec
CAQuietExec: Error 0xc0000409: Command line returned an error.
This is the relevant part of the log and where the install keels over, noise removed. 0xc0000409 is very, very nasty. STATUS_STACK_BUFFER_OVERRUN is a stack corruption error, triggered by code that protects against viral attacks.
Searching for "nodejs install 0xc0000409" takes you to this bug report, notable from December 2015. This issue has been dogging users for a long time, but they are having trouble finding the root cause. The generic workaround is to disable this install step by disabling the installation of the ETW performance counters.
Which works, but is but a band-aid. I think macario1983's comment points at the real troublemaker. It got a lot of helpful votes in just two days. And points at the kind of viral rootkit that programmer's voluntarily install, the kind that can so easily cause a STATUS_STACK_BUFFER_OVERRUN error with no decent way to identify the code that causes it. Anti-malware has become a cure that is worse than the disease, Avast in particular is a truly awful product and does not belong on a programmer's machine.
So decent advice is to 1: disable the anti-malware product before installing Node. 2: get rid of completely if it is Avast. 3: disable the performance counter registration. 4: try the updated installer, patched 4 days ago.
I disabled the AVG antivirus(version 18.4.3056) but not windows firewall and then i was able to install nodejs.
Possible options to solve this:
1. Removing previous installations traces
If you have previous installations, make sure that they were uninstaled completely. If HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\_V2Providers\{1e2e15d7-3760-470e-8699-b9db5248edd5} record exist in your register, remove it.
2. Disabling Performance Counters
If you don't need Performance counters feature, try to install without it (or maybe even without Event Tracing).
3. Disabling security and giving the full permissions
Clean Temp Folder
Disable your antivirus/firewall for the period of installation.
C:/users/$user/AppData/Local/Temp- Right Click on Temp and go to Properties > select Security Tab > give the user permissions by checking Full Control on permission
Install Node.js
I had today the same problem with Windows 10 64 bit and Node.js 8.11.2: disabling completly Avast just for the time of the installation solved the issue.
I was trying to install Node.js through node-v8.11.2-x64.exe, but it was rolling back every time at the end. The error in the event log was about wevtutil.exe, version 10.0.17134.1
I had the same issue on a Windows 2012R2 server installing node-v8.11.2-x64, and disabled the McAfee anti-virus to no avail. When I went to clean out the TEMP folder as suggested in this thread, I noticed that several files and folders were locked and could not be deleted, so I rebooted the machine (with the anti-virus disabled). After the reboot, I noticed that the locked temp files had been deleted, and I was able to install node.js, including the Performance Counters and Event Tracking options.
I spent one day for that ....Best solutions is download zip example node-v12.16.2-win-x86.zip.
I just came back from MWLUG and started to open up some Xpages DBs to work on, when all of the sudden I am getting 1000s of errors like this:
I googled the issue and I believe it has something to do with the path of the org.eclipse.pde.core.requiredPlugins.
When I opened up the packages and looked at fixing an error I got this:
The problem is that I do not know what the correct setting for this should be, or how to fix it. The apps run fine, but obviously something is wrong.
Any help would be very much appreciated.
Bryan
==================================================
I may know more about the problem. In designer when I go to File==>Application==Application Management this is what I see:
A different install has several components under it.
I updated my designer and client and admin to 9.0.1 FP4 last week. That is the last thing I remember doing before this messed up (along with installing the Debug Toolbar).
How can I fix my designer install?
Strange indeed, you should check your hard drive for bad sectors.
Looks like a broken DDE in general. The plugin XML file maybe broken so the app manager doesn't show you the plugins installed. Therefor I assume DDE starts very quickly, right? Because nothing is loaded.
I had this before and my "solution" was:
de-install DDE and Fixpacks
delete workspace folder
re-install DDE and Fixpacks
re-install plugins ad setup workig sets
This is a pity but at least you get a clean install. You don't have to delete everything (e.g. the DATA folder)
I am working SDL TRIDION 2011 SP1 version. Suddenly I am unable to see the Trdion site in Internet Information Services(IIS) Manager. Please tell me the procedure how to get it back again.
Remove Tridion Completely (uninstall), then run the installer again.
You won't loose any data (it's all in the database), and you're likely to get your server up and running way faster than trying to fix by hand.
As #bart suggested, your best option to get the web application back (assuming it really has gone), is to run the repair option with the installer. There are a lot of folder specific settings which would be very hard to recreate manually.
I created a setup file which is working awesome.
Now whenever I rebuild an application without changing anything but Package Code is changed and then while I am going to install this version then a dialog will come "Upgrade Dialog" which ask me for upgrade an application.
Now in this situation I want to display an additional dialog created by me.
I am using the Insatllshield 2012 BASIC MSI project type.
I solved this problem.
There are two properties exist in Installshield named "IS_MINOR_UPGRADE" and "IS_MAJOR_UPGRADE".
When there is a minor upgrade at that time IS_MINOR_UPGRADE will set to 1. And same for Major upgrade.
So using these properties, I can recognize the Upgrade mode.
Any time you change the package code but not the product code you are talking about a Minor Upgrade or possibly a Small Update if you don't change the ProductVersion. Either way, the only way to create a custom message like you ask is to write your own setup.exe / update.exe bootstrapper to detect the update scenario and display your confirmation UI.
There's nothing built into MSI or IS that allows you to easily change this.
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.