My installer started off years ago and thus has a Quick Launch bar task.
Name: "{userappdata}\Microsoft\Internet Explorer\Quick Launch\Public Talks"; \
Filename: "{app}\CommunityTalks.exe"; \
MinVersion: 4,4; \
Tasks: quicklaunchicon
When compiling this raises the warning:
Warning: The [Setup] section directive "PrivilegesRequired" is set to
"admin" but per-user areas (HKCU,userappdata) are used by the script.
Regardless of the version of Windows, if the installation is running
in administrative install mode then you should be careful about making
any per-user area changes: such changes may not achieve what you are
intending. See the "UsedUserAreasWarning" topic in help file for more
information.
How should we handle that?
Remove the "Quick Launch" toolbar functionality from your installer.
No one is using that nowadays. The "Quick Launch" toolbar was removed in Windows 7 (2009).
Related
I'm working with OpenEdge Progress-4GL AppBuilder and Procedure Editor, and now I'd like to start working with the OpenEdge Debugger, release 11.6.
As found on quite some places on the internet, I've taken following actions to enable debugging of my Progress application:
Using Proenv, I've launched following command:
prodebugenable -enable-all
I get following response:
OpenEdge Release 11.6 as of Fri Oct 16 19:01:51 EDT 2015
==============================================================================
PROGRESS Debug Enabler
==============================================================================
Debugging is enabled for the Progress 4GL installed in
C:\PROGRE~1\OpenEdge.
For your information, some information on environment variables:
proenv>set DLC
DLC=C:\PROGRE~1\OpenEdge
proenv>set WRK
WRKDIR=C:\OPENED~1\WRK
proenv>set ENABLE_OPENEDGE_DEBUGGER
Environment variable ENABLE_OPENEDGE_DEBUGGER not defined
As far as my application is concerned, the application is based on a shortcut, which looks as follows:
C:\Progressx86\OpenEdge\bin\prowin32.exe
-basekey "INI"
-ininame c:\progress\our_application\progress.ini
-pf c:\progress\our_application\misc\run_our_application.pf
-p our_application.r
-rr
The file "run_our_application.pf" contains a list of entries, like the following:
-db our_DB
-H DC1
-N tcp
-S 6543
To the mentioned shortcut, I've added -debugReady 5001 in order to enable debugging, based on TCP portnumber 5001. When I launch the application, I get a warning message about this, and netstat -aon gives me following entry:
TCP 0.0.0.0:5001 0.0.0.0:0 LISTENING 11344
Where 11344 is confirmed as the prowin32 application.
In OpenEdge debugger, I've following entries in menu item "Edit", "Preferences", "Attachable":
C:\progress\our_application
Z:\Progress\our_application\PRG
C:\Progressx86\OpenEdge
For your information: The Z:-drive is an external server drive, Z:\Progress\our_application\PRG is the directory where files (*.w and *.p) get compiled into *.r files, the file our_application.r can be found there.
Nevertheless, when I open a *.w file and I go to the menu "Debug", the "Attach to Process" menu item stays disabled.
What can I do in order to debug my application/*.w file?
There are several ways of debugging. Start simple. You should be able to use any of the following:
from the procedure editor
Instead of selecting [ Compile / Run ], select [ Compile / Debug ]. The AVM will start executing the current file and the debugger will suspend execution on the first line.
from any alert-box
Add -debugalert to your startup parameters and every alert-box will display an additional 'Help' button. Clicking on it will show the stack-trace and a 'Debug' button. Clicking on that will start the debugger, execution is suspended at the line of the alert-box, this can be your own alert-box or an error.
stand-alone debugger
Start the debugger application (the Windows shortcut starts proDebugger.bat) and select [ Debug / Attach To Process... ] you can then either enter a PID or select a local running session (AVM).
remote attachable debugger
This is what you seem to be trying to setup - this allows you to attach the stand alone debugger (see option 3) to a process running on another machine, this can be useful when you have an AppServer or WebSpeed agent that you want to debug.
PDSOE debugger
Not relevant for you since you are not using Progress Developer Studio for OpenEdge, but just mentioning it for completeness. This allows adding break points in your source code by double clicking in the left margin and stepping through your source code instead stepping through a debug-listing.
I found the option to install silently from command line (vscode-installer.exe /VERYSILENT), BUT it still opens automatically at the end of the installation, thus making unattended installation on multiple computers inconvenient.
I checked Inno Setup's documentation (that's what the Visual Studio Code installer uses), but there's nothing related to disabling Visual Studio Code autostart (even on very silent installation).
There might be a way by using /COMPONENTS, /TASKS or /MERGETASKS, but for that I need to know what is already available for use.
Is there a way to make it install completely silently?
There's a hidden task runcode, that gets automatically selected for silent installations. To unselect the runcode task, use the /MERGETASKS=!runcode option.
VSCodeSetup-1.10.1.exe /VERYSILENT /MERGETASKS=!runcode
(Credits for the /MERGETASKS=!runcode go to #RobertWigley)
The above is based on build/win32/code.iss in the GitHub repo:
[Tasks]
Name: "runcode"; Description: "{cm:RunAfter,{#NameShort}}"; \
GroupDescription: "{cm:Other}"; Check: WizardSilent
[Run]
Filename: "{app}\{#ExeBasename}.exe"; \
Description: "{cm:LaunchProgram,{#NameLong}}"; Tasks: runcode; \
Flags: nowait postinstall; Check: ShouldRunAfterUpdate
Filename: "{app}\{#ExeBasename}.exe"; \
Description: "{cm:LaunchProgram,{#NameLong}}"; \
Flags: nowait postinstall; Check: WizardNotSilent
I found to run within Powershell I used Start-Process, Execute-Process seemed to be deprecated for me.
The below is the line I use.
Start-Process -FilePath "path/to/vscode/VSCodeUserSetup-x64.exe" -Argument "/VERYSILENT /MERGETASKS=!runcode"
Execute-Process is a built-in function for PowerShell Application Deployment Toolkit (PSADT) and the -Parameters parameter is also not a standard parameter, but part of that custom function.
Instead, use Start-Process -FilePath "VSCode.exe" -ArgumentList "/VERYSILENT /MERGETASKS=!runcode"
You can pass any of the arguments in the -ArgumentList
Execute-Process -Path "VSCodeUserSetup-x64-1.30.1.exe" -Parameters "/VERYSILENT /CLOSEAPPLICATIONS
you can use this for PowerShell installation.
My Intent
I have an image generated by BitBake on which I'm interested in changing the window manager to metacity or maybe something similar.
My Process
I've added require recipes-graphics/images/core-image-x11.bb into my core recipe, which provides a simple Matchbox terminal window but seemingly no other functionality. If I add matchbox-desktop and matchbox-session-sato, it adds a bit more usability but not what I'm looking for.
I've included the default package from the metacity_2.34.13.bb recipe from the meta-gnome layer from the OpenEmbedded Metadata Index in the IMAGE_INSTALL variable of my core image. This installs several components including a metacity command in /usr/bin. If I run that command, I get the following message:
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications
(metacity:1124): GLib-GIO-ERROR **: Settings schema 'org.gnome.metacity' is not installed
Trace/breakpoint trap
I've navigated to /usr/share/glib-2.0/schemas and run glib-compile-schemas ., then run:
startx
metacity --replace
again. Now, the output is:
Window manager error: Unable to open X display
I haven't found a clear solution to this error which applies to my specific situation.
Update (2/29):
I may have now found a solution to this error, using these commands:
X&
export DISPLAY=:0
metacity&
At this point, I seem to be running something on one of my VTs. I can run demos like glxgears in that VT (glxgears is included in the mesa-demos recipe), but I don't know how to actually create a usable environment.
My question(s)
I'm not using much from meta-openembedded/meta-gnome (just metacity) or meta/recipes-gnome (adwaita-icon-theme, gnome-desktop3, gsettings-desktop-schemas and gtk+3), so am I missing some recipe which automates the addition of metacity?
(if not Question 1) How can I solve the error Window manager error: Unable to open X display?
The x11-common recipe adds a X session script that will run /usr/bin/x-session-manager: that is responsible for starting your desktop environment.
The way to implement a new session/DE in OE-Core is to use update-alternatives for "x-session-manager": see the matchbox-session recipe for the default implementation and mini-x-session recipe for an alternative.
mini-x-session might be modifiable for your needs so you don't need to write a new one: A /etc/mini_x/session file like this might do the trick:
# start any apps here, e.g. "my-desktop &"
exec metacity
Going from this (a running window manager) to "usable environment" might still be lots and lots of work, depending on your definition of usable.
My team is attempting to perform an automated installation of Sitecore via Salt using the Sitecore executable. We prefer to use the .exe over a manual installation of the zip package because the installation wizard handles registering Sitecore as an installed program by modifying the registry. This would theoretically let Salt know that the "state" has been fulfilled.
When running the executable with the /? argument, the following list of options is displayed:
/? or /help : this help screen
/i : install (default)
/x : uninstall
/q : force silent (no UI) mode
/qb : force basic UI mode
/nq : force full UI mode
/nosplash : do not display splash screen
/Log : enable logging
/LogFile [path] : specify log file
/ConfigFile [path] : specify configuration file
/ExtractCab : extract embedded components
/DisplayCab : display a list of embedded components
/DisplayConfig : display a list of configurations
/ComponentArgs ["id|display_name":"value"...] : additional component args
/ControlArgs ["id":"value" ...] : additional control values
/CompleteCommandArgs [args] : additional complete command
Despite our best efforts, we are unable to find documentation on these arguments apart from the descriptions above. I think what we're after is a way to provide a config file to the executable (using the /ConfigFile argument) that contains the following information:
Install / uninstall
Installation type (full / client-only)
Instance name
Database credentials
Running the /DisplayConfig command only displays language options and that's about it.
Does anyone know how to provide a config to the executable and/or pass it the arguments it needs?
I wrote a blog post about the issue of getting the Sitecore installer automated:
http://jermdavis.wordpress.com/2014/04/24/unattended-installs-of-sitecore/
I think that might help you?
For anyone else who needs an answer to this, this is how me and Derek got it to work:
../salt-states/win/repo/sitecore/init.sls
Sitecore:
7.1:
installer: 'salt://win/repo/sitecore/Sitecore 7.1 rev. 130926.exe'
full_name: 'Sitecore 7.1 rev. 130926 - Sitecore130926'
reboot: False
install_flags: ' /q /ExtractCab && msiexec.exe /qn /i SupportFiles\exe\Sitecore.msi TRANSFORMS=":InstanceId1;:ComponentGUIDTransform1.mst" MSINEWINSTANCE=1 LOGVERBOSE=1 SC_LANG="en-US" SC_CLIENTONLY="1" SKIPINSTALLSQLDATA="1" SKIPUNINSTALLSQLDATA="1" SC_INSTANCENAME="Sitecore130926" SC_LICENSE_PATH="C:\inetpub\temp\sitecore_license.xml" SC_SQL_SERVER="SERVER" SC_DBPREFIX="Sitecore130926" SC_DBTYPE="MSSQL" INSTALLLOCATION="C:\Inetpub\wwwroot\Sitecore130926" SC_DATA_FOLDER="C:\Inetpub\wwwroot\Sitecore130926\Data" SC_NET_VERSION="4" SITECORE_MVC="1" SC_INTEGRATED_PIPELINE_MODE="1" SC_IISSITE_NAME="Sitecore130926" SC_IISAPPPOOL_NAME="Sitecore130926AppPool" SC_IISSITE_HEADER="local.domain.org" SC_IISSITE_PORT="80" SC_IISSITE_ID="2" SC_PREFIX_PHYSICAL_FILES="1" SC_SQL_SERVER_CONFIG_USER="USER" SC_SQL_SERVER_CONFIG_PASSWORD="PASSWORD" /l*+v "C:\inetpub\temp\SitecoreInstaller.log"'
uninstaller: 'salt://win/repo/sitecore/Sitecore 7.1 rev. 130926.exe'
uninstall_flags: ' /q /ExtractCab && msiexec.exe /qn /X{D0CB9951-0EC0-55B1-A2C8-4590B816E4EC}'
../salt-states/sitecore/init.sls
Sitecore:
pkg.installed:
- refresh: true
- require:
- file: C:\inetpub\temp\sitecore_license.xml
C:\inetpub\temp\sitecore_license.xml:
file.managed:
- source: salt://sitecore/license.xml
Add your sitecore license to ../salt-states/sitecore/license.xml
Thanks to JermDavis, this wasn't possible without your blog post!
Are you tied to using that tool or are you open to others? My team has had pretty great results with the SIM tool which comes directly from the Sitecore Marketplace. It has command line functionality as well as an API for more trickier installation setups. I consider this a borderline magical utility for Sitecore :)
https://marketplace.sitecore.net/en/Modules/Sitecore_Instance_Manager.aspx
I can't get windows 8 (release preview) to accept either the inf2cat or makecat approach described as solutions to the question at
What changed in the driver signature requirements for Windows 8?
unless I disable validation.
I am not signing these with any certificates at this point, just trying to get past the errors preventing the drivers from installing at all.
Windows 8 gives me a very nondescript error:
"A problem was encountered while attempting to add the driver to the store."
Looking in the event logs, there is nothing of use; only an informational entry from "Windows Error Reporting" indicating a PnPdriverimporterror.
When i use my original files with the cab files that don't match the inf, I get the error everyone else is listing:
The hash for the file is not present in the specified catalog file.
I have one .inf file that i need to generate a .cat for.
Perhaps I am doing something wrong. Ideas??
INF2CAT Approach
c:\win_xp_vista32_64>inf2cat /driver:"." /os:XP_X86,XP_x64,Vista_X86,Vista_x64,7_X86,7_X64,8_X86,8_X64
.......................
Signability test complete.
Errors:
None
Warnings:
22.9.10: usbser.sys in [drivercopyfiles.nt] is missing from [SourceDisksFiles] s
ection in \mchpcdc.inf; ok if file source is provided via LayoutFile in [Version
].
22.9.10: %driverfilename%.sys in [drivercopyfiles.ntamd64] is missing from [Sour
ceDisksFiles] section in \mchpcdc.inf; ok if file source is provided via LayoutF
ile in [Version].
Catalog generation complete.
c:\win_xp_vista32_64\mchpcdc.cat
MAKECAT approach
--- start of catalog.cdf file---
[CatalogHeader]
Name=mchpcdc.cat
ResultDir=.\
[CatalogFiles]
<hash>mchpcdc=.\mchpcdc.inf
---end of .cdf file ---
c:\win_xp_vista32_64>makecat catalog.cdf
These same files, w/ the cat from either approach install just fine in Windows 7.
I think this problem is to do with "windows driver signing enforcement". You can resolve this by disabling this option. Go through with below link:
http://tivadj-tech.blogspot.in/2012/09/certificate-check-error-when-installing.html
I just tested this on Windows 10 and 8 PRO now, to get this right, follow these steps:
1) From your Start menu, locate your DDK's "x64 Checked Build Environment" i.e. the custom DOS build screen. Right-click, run-as administrator...
2) Compile your source with the Build tools etc.
3) Go into your compiled code, and then create your test-certificate (you don't need to purchase one just yet, use your self-signed one created with the line below):
makecert -r -pe -ss PrivateCertStore -n CN=newhex.com(Test) NewhexTest.cer
The above means your certificate is called "newhex.com(Test)" and the generated file is "NewhexTest.cer"
4) Create / Edit your .CDF file which contains items about what your CAT file's contents.
5) Create your CAT file by executing:
makecat -v MyCDF.CDF
This should generate an un-signed CAT file that includes all files specified by your CDF.
6) Sign your CAT file as follows:
Signtool sign /v /s PrivateCertStore /n newhex.com(test) /t http://timestamp.verisign.com/scripts/timestamp.dll MyDriverWhatever.cat
This should result in a CAT file that is signed, but don't just install it, because your Windows can't trust Newhex's cert since it's not in the keystore, to fix this do:
7) Add your certificate to your private Key Store, remember this step MUST be done by an administrators access, otherwise you will get an error about (Keystore not found etc):
certmgr.exe -add NewhexTest.cer -s -r localMachine root
This should add into your keystore, Once done, you can then:
8) Go into your device manager, and add your new driver, you would get a warning but will be accepted and installed without the need to reboot with a forced (Don't check cert type account).
I tried this already and it works on Windows 10 and Windows 8 pro versions.
Kind Regards
Heider Sati
You are supposed to use inf2cat, not makecat, because you have an INF file.
You should work on addressing those warnings from inf2cat by fixing your INF file. Here is my INF file that uses usbser.sys and doesn't cause any warnings: https://gist.github.com/3647208
I was able to fix my INF file thanks to the advice from chinzei in the first post of this thread: http://www.microchip.com/forums/m488342-print.aspx
If you continue to have trouble, please edit your question to include the source of your INF file, or at least a link to the source.
I encounter the same problem and was able to install my driver with a TEST certificate using the instructions provided here:
http://msdn.microsoft.com/en-us/windows/hardware/gg487328.aspx