I have been trying to detect if Tomcat is installed on a host system in my NSIS script.Here is the section that does it
Section Tomcat
ClearErrors
Var /GLOBAL tomcatVersion
ReadRegStr $tomcatVersion HKLM "SOFTWARE\Apache Software Foundation\Tomcat\7.0\Tomcat7" "InstallPath"
;ExecWait "$EXEDIR\apache-tomcat-7.0.22.exe"
DetailPrint "$tomcatVersion"
SectionEnd
When I go to "regedit" and check the path of that specific key, it has a value, but the print statement returns a blank.
Can someone suggest what is the best way to troubleshoot this and/or any errors that I might be facing?
There is an interesting thing I noticed, that If in the above code, if I point the ReadRegStr command to read
HKLM "SOFTWARE\JavaSoft\Java Runtime Environment" "CurrentVersion"
It returns a value, so syntactically, the code does work.
If the Tomcat installer is a 64 bit installer then a 32 bit process will not find that key, in NSIS you can use SetRegView 64.
If you are using RequestExectionLevel in your script and the Tomcat installer was virtualized by UAC then you must read it from the VirtualStore (Unlikely in your case since you can see the key in regedit)
Process Monitor is also handy to debug registry issues...
A little late to the party, but this thread comes up if you google for "nsis install tomcat", so I thought I would share this nice example I found...
https://github.com/mathiaslin/openmrs-pgh-190/blob/master/metadata/installer/installer_setup.nsh
Related
Before reporting to Microsoft I want to ask here. I have a problem that I cannot see Live Visual Tree of my WinUI 3 application. I cannot even see the in-app toolbar. I can see both in WPF and UWP application, no problems. I have these options for hot reload, that should be fine.
I am using VS2022 17.3.1 and Windows App SDK in version 1.1.4. Weird is that it was functioning without problems, but one restart of application just broke that. I also tried adding the ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO to environment variables manually, but no luck there.
It seems that 32-bit WinUI 3 app is working fine, it only affects 64-bit WinUI 3 applications. Even the new and blank ones. Packaged/unpacked type doesn't affect the problem.
I tried uninstall and install VS again, no changes.
So I did finally find a solution (more of a workaround) to this.
Run following commands in elevated cmd, where you replace WindowsAppRuntime version with version you currently have (for me it is Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe):
takeown /f "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe" /r /d y
icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe" /grant Users:(RD,R,REA,RX) /t
Don't know what it does, but it is working. This solution is taken over from Developer Community
UPDATE:
You have to repeat this procedure when you update Windows App SDK to a new version.
Here is a PowerShell command that loops over all WindowsAppRuntime folders and applies the fixes on #benderto's answer.
Get-ChildItem -Path 'C:\Program Files\WindowsApps\' -Filter 'Microsoft.WindowsAppRuntime*' | Foreach {
takeown /f "C:\Program Files\WindowsApps\$_" /r /d y
icacls.exe "C:\Program Files\WindowsApps\$_" /grant "Users:(RD,R,REA,RX)" /t
}
You don't need to restart Visual Studio for this to take effect. Restarting the debugging session is enough.
After lots of reinstallion, 100+?, I came across with this information then problem solved.
It is very frustrating the recent quality of Visual Studio 2022 after 17.2. Each update gets me reinstall loops again, again and again, just because something broken.
This time, MAUI (WinUI 3) XAML Hot Reload won't work.
XAML Hot Reload
So I created 3 VMs and installed with different detail of workloads, and tried to figure out "What's wrong". But I failed.
The error seems random. However, I did get some thing strange.
The Hot Reload was "working" after installaion and I left the VM on. After awhile back, I stopped debugging and restarted to debug, the working one became "not working" somehow over time, so I compared two snapshot, one work, one did not. After comparing installion configuration, run with user, run with admin, MAUI App with .net 6.0, MAUI App with template 7.0, both registry, both disk contain (entire C:). I found nothing, all identical as they should be.
Checking Logs:
Event Log, AppData\Local\Temp\VSLogs, AppData\Local\Xamarin\Logs\17.0, the Output of VS
However, the Output: debug. Did make me tracing the component binding process, also found nothing.
The One "Not Wotking":
The One "Not Wotking"
The One "Working":
The One "Working"
Huge data but no luck:
Assembly binding log
Windows Policy, no luck: Audit Access Deny
I have to say the error logs are well hidden.
After lots of google thing, I came across with this information then problem solved. It is a Permission problem.
And then I dig a little further, here i found:
VS Output:
WindowsAppRuntime, installed at first run, may be update after
C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe
The list of files that Permissions are different (Not Working vs. Working):
CoreMessagingXP.dll
dcompi.dll
dwmcorei.dll
DwmSceneI.dll
DWriteCore.dll
marshal.dll
Microsoft.DirectManipulation.dll
Microsoft.Foundation.winmd
Microsoft.Graphics.winmd
Microsoft.InputStateManager.dll
Microsoft.Internal.FrameworkUdk.dll
Microsoft.UI.Composition.OSSupport.dll
Microsoft.UI.Input.dll
Microsoft.UI.Windowing.Core.dll
Microsoft.UI.winmd
Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.Core.winmd
resources.pri
WindowsAppRuntime.png
WindowsAppSdk.AppxDeploymentExtensions.Desktop.dll
wuceffectsi.dll
en-GB\Microsoft.ui.xaml.dll.mui
en-GB\Microsoft.UI.Xaml.Phone.dll.mui
Microsoft.UI.Xaml\Assets\NoiseAsset_256x256_PNG.png
Conclution:
The "Microsoft.WindowsAppRuntime" will get installed on first run and will not get uninstalled with Visual Studio uninstallation.
The "Microsoft.WindowsAppRuntime" may get updated and permission also get changed.
The ACL permission of Microsoft.WindowsAppRuntime folder and files in it may change somehow after some time, same version (Did not go this far to see why).
Manipulate the Permission manually does the trick
Simple Rest (SYSTEM access right is required, PsExec):
psexec64 -i -s cmd.exe /k icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe\*.*" /reset /t
Minimun Reset (for my case, as soon as this reset done, the hot reload shows up when debug, remember to restart debug):
psexec64 -i -s cmd.exe /k icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe\Microsoft.Internal.FrameworkUdk.dll" /reset
I've downloaded WampServer twice. The specifications for my WampServer are: "Apache/2.4.17 (Win64) PHP/5.6.16 - Port defined for Apache: 80" and for MySql: "5.7.9 - Port defined for MySQL: 3306". The first time, it worked for sometime (2 weeks) and then it started to complain about:
*** ERROR *** The PHP configuration loaded file is: - should be: C:/wamp64/bin/apache/apache2.4.17/bin/php.ini or c:/wamp64/bin/php/php5.6.16/phpforapache.ini".
When I tried to try to move php.ini files to the right locations there was many of them ("for production ,"for development", "phpforapache" and one that just said it was an ini file). Since I was getting the error that no mbstring extension was found, I went ahead and made sure i un-commented ;extension=php_mbstring.dll from all those ini files. Guess what, nothing worked.
So I decided to uninstall WampServer and downloaded it again. It worked. But after I shut my computer down, it gave the same exact problems as before.
I've been looking online to see how I can fix this problem. There are many solutions but none of them seem to work. There's one where there must not be Internet Information Services on, one where I have to set the system environment variable value to the path of my php ini file, one where I must make sure no other service or program is using port 80. I have made sure that port 80 isn't accessed by other programs already.Then, other solutions mentioned that i should change 127.0.0.1 on my httpd.conf file to "all". Finally, there's another problem that says Skype should not be turned on. I do have Skype for business, but is not turned on. I've tried to delete it and uninstall many times, but somehow is not going away. However, WampServer has worked for me in the past.
More strange things: The only way that WampServer will turn green is if I double tap on the desktop icon. Then, it asks me if I will allowed it to make changes to my hard drive. I've tried stopping services and restarting them, but it wont start this way. Also, when I typed localhost it takes me to the WampServer homepage, but if I try to access "phpMyAdmin" it gives me that the extension to "mbstring" is not found. Here is probably the strangest of all: When I click on my task manager and check for services running on my computer, it says that "wampmysql64" and "wampapache64" are both running, while the the icon for WampServer is red. Also, if i test the files under the www folder: one of them is called "testmysql.php" it gives me this error: Fatal error: Class 'mysqli' not found in C:\wamp64\www\testmysql.php on line 7. The other file "test_sockets.php" gives the server error: Extension PHP sockets not loaded.
I don't know why this product is out there if it will do as it pleases: move files, change ports and all these extensive checks that must be made in order to make sure it works. Am seriously looking for an alternative. Sad, cause the graphical interface seems so easy to understand and navigate through.
Please can someone give me a hand. I am seriously thinking about uninstalling WampServer, loading it again and giving it another go. But, i know all those problems will come back.
I ran into the same problems as you did, and I got the answer by checking on their forums. To begin with, exit Wampserver. According to this page*, you should take the following steps:
Open a command prompt window, and run as administratorC:\Windows\system32>
Move to the apache directory C:\Windows\system32>cd C:\wamp\bin\apache\apache2.4.17\binC:\wamp\bin\apache\apache2.4.17\bin>
Create a symbolic link linking the php.ini to phpForApache.ini in the PHP directory
C:\wamp\bin\apache\apache2.4.17\bin>mklink php.ini C:\wamp\bin\php\php5.6.15\phpForApache.ini
You should get a response that sayssymbolic link created for php.ini <<===>> C:\wamp\bin\php\php5.6.15\phpForApache.ini
For Wampserver to run correctly, it has to be run as administrator. So locate the desktop and start menu shortcuts for Wampserver and right-click. Then select Properties > Shortcut > Advanced and check Run as administrator
After applying changes, you can start up Wampserver again and it will run normally.
*The page is in French, so you may need to run it through Google Translate
I resolved that issue: I just renamed the file phpForapache.ini in the php directory to php.ini, then I copied this php.ini to apache directory; finally all the troubles is resolved.
I hope this helps you.
Thanks for the answer #tizak. What I did is I uninstall wampserver and downloaded the previous version for my 64 bit machine. It hasn't given me any problems.
I am having a problem with using Apache/Perl to get access to Excel files using Microsoft Data Access Component (MDAC). Somehow I must set the "CommonProgramFiles(x86)" system environment variable in order to get this to work. Otherwise, I keep getting this error message:
System.InvalidOperationException: The .Net Framework Data Providers
require Microsoft Data Access Components(MDAC). Please install
Microsoft Data Access Components(MDAC) version 2.6 or later. --->
System.IO.FileNotFoundException: Retrieving the COM class factory for
component with CLSID {2206CDB2-19C1-11D1-89E0-00C04FD7A829} failed due
to the following error: 8007007e.
The server configuration is:
Windows Server 2008 R2 in 64-bit
Server is installed with Microsoft Access Database Engine 2010
Apache 2.2.25 (that is 32-bit)
Perl 5.12.3 v5 (that is also in 32-bit)
I have my Perl CGI script to call my C# program (that is built for "Any CPU").
The C# program uses MDAC to open and read Excel files (not trying to launch Excel, only try to read data from the Excel files).
I have verified that the server has the latest MDAC available in these 2 folders:
C:\Program Files\Common Files\System\Ole DB
C:\Program Files (x86)\Common Files\System\Ole DB
I have also checked the registries and they look fine. Anyway, I don't have any problem running my C# program directly at the command prompt (it can use MDAC to get access to Excel files). I only have the problem when I use Apache/Perl to use my Perl CGI script to call my C# program (that is when I get that error with MDAC).
I can work around this problem by specifying CommonProgramFiles(x86) in my Perl CGI script, like this:
$ENV{ "CommonProgramFiles(x86)" } = "C:\\Program Files (x86)\\Common Files";
I have this question:
Why do I have this problem? And why setting that CommonProgramFiles(x86) system environment variable can workaround this problem? Why that system environment variable is empty before I set it? Does this have to do with the fact that I am running 32-bit Apache/Perl in a Windows operating system that is 64-bit?
Please help me to understand this issue. Thanks in advance.
(The original version of this post had a question about a second problem. Turned out that problem had to do with an extra double quote in the string. I fixed this, and that problem has gone away. That's why I have removed that second question from the post)
Jay Chan
I did some more research and the issue is the following: until release 2.4.9, the Apache startup routines have mapped "commonprogramfiles(x86)" to "commonprogramfiles_x86_" and that variable does not exists in the environment unless you create it... I have not tested it, but creating that environment variable and making it point to the same location as commonprogramfiles(x86) would probably fix the issue too.
Since the compiled Apache distributions are only using up to version 2.4.46 as we speak, they don't have the fix that allows the parenthesis in environment variables. That's why you still need the PassEnv directive to ensure that Apache passes the correct values to 32-bit CGI scripts.
The following post has some useful details about this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=46751
I used to have the same problem in with Apache 2.4 with dBase compiled apps using ADO-32 bit as dBase is 32-bit. Something has recently changed, possibly with Windows 10 2004 20H2. I needed this fix in July-Aug 2020 but now I don't, the environment variable already exists. Since my Apache version is dated April 2020, that cannot be the reason for the change.
I tried to do some research about this but all I could find is that those environment variables are system ones existing at least since 2017, so why I needed to set this var is a mystery to me, but I would like to understand this, so if you find something, post a follow-up...
https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables
I'm using WiX 3.5. Recently, the following WiX error started occurring frequently on the build server:
light.exe (,): error LGHT0301: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/#Codepage, Package/#SummaryCodepage, Product/#Codepage, or WixLocalization/#Codepage; or make sure you provide the path to a valid Windows Installer database.
Which "database" does the error refer to? (None of the WiX source files have changed in a long time, so I doubt it's a code page problem.)
Other people have reported that this error may be caused by Trend Micro Office Scan, which is indeed installed on the build server. I asked the system administrator to exclude the build directories from the scan, but this error still occurs. How can I determine whether the virus scanner is the culprit? (The error doesn't always occur, so if I disable the virus scanner and the next build succeeds, I still don't know whether the error has gone away permanently.)
The "Disable the ICE validation" worked for me - just a setting through Visual Studio 2012 in the .Setup.
After studying the WiX source code and running Process Monitor, I found that excluding the build directories from the virus scan is insufficient.
Explanation: When light.exe runs, it creates the target MSI file in a temporary directory. (This file is the database that the LGHT0301 error message refers to.) After light.exe closes the MSI file, ntrtscan.exe opens the MSI file for read access and read-only sharing. Later, in the database validation step, light.exe tries to reopen the MSI file for read/write access, and a sharing violation occurs.
Solution: Exclude the temporary directory from the real-time virus scan. On Windows Server 2008, for example, this directory is C:\Users\«username»\AppData\Local\Temp.
This is a common problem with build processes and antivirus. The scanner will detect the new MSI package and try to scan it. Meanwhile the build process also tries to validate it by running the Internal Consistency Evaluators (ICE) suite and you get a failure because the database has a mutex on it.
You should just remove the virus scan from your build output folders. Alternatively decouple the validation from the Light command so that the antivirus scan relinquishes the MSI handle before you run the ICE validation.
I had the same problem which was actually really related to codepages and language settings of my system.
Adding English input language in Windows' regional settings solved the problem on my German Windows installation.
The real cause was Trend Micro real time scanning!
(The following is only for historical reference)
I followed #Michael Liu answer and solved the problem
I had the same problem.
I am not referring to Codepage (or SummaryCodepage) in any of those tags, or in fact anywhere in the WXS. Putting Codepage="1252" didn't change anything.
Finally, I tried adding
encoding="utf-8"
to the XML tag which previously only had a version='1.0' attribute. This fixed the problem, as described in "Failed to open the database" error. - SOLVED
It was also the antivirus program for me.
An easy way to check if the problem is related to the anti-virus program is to disable the ICE validation in the WiX project setting (using version 3.7). This worked for me, and is a permanent setting now, since in our company you can't change the setting of the antivirus software.
This is the most common error I found while using WiX. The easiest solution for this is go to Properties of your project → Tool Settings → (Check) Suppress ICE Validation.
I have access to a remote Solaris terminal which crashes occasionally, and I have to ask someone with physical access to boot the machine up, which it does successfully. I would like to know which tools/files should I look at to find out the cause of the crash so that I can make the necessary configuration changes and avoid it in the future.
What tools you can use will depend on what version of solaris you have running and what the actual problem
is. The first thing to do is check the system console (which it sounds like you don't have access to) and the /var/adm/messages file. This file is updated with system messages and the newest will appear at the end.
Next, you can look for a system core file. If a core file is created, it would be in /var/crash/hostname where "hostname" is the name of the machine.
If you have an actual core file in the /var/crash/hostname directory, this set of commands will give you a good
string to search google with:
# cd /var/crash/hostname
Replace "hostname" with the hostname of your machine.
# mdb -k unix.0 vmcore.0
If you have multiple core files, select the most recent version.
> ::status
This should give you a panic message, cut and paste that into google and see what you can find.
For more core file analysis read this:
http://cuddletech.com/blog/pivot/entry.php?id=965