I wrote a WCF service (started as command line application) and had the problem that it needs to be started with admin privileges. So I wrote a dos-script that can either start the server and/or the client and checks the privileges in the first place. Writing a dos script was a little bit like time traveling for me, but finally I managed and understood it. Here my findings:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | @echo off echo _________________________________________________ echo. echo HERE A FANCY SERVICENAME echo _________________________________________________ net session >nul 2>nul if %errorLevel% equ 0 ( echo Success: Administrative permissions confirmed. ) else ( echo Failure: Current permissions inadequate. goto end ) echo. echo. set /P startServer=Should the server be started? (y/n) set /P startClient=Should the client be started? (y/n) IF /I "%startServer%"=="y" ( echo starting server start cmd /c "Server.exe" ) else ( echo starting server skipped ) IF /I "%startClient%"=="y" ( echo starting client start cmd /c "Client.exe" ) else ( echo starting client skipped ) :end |
- line #1 calls a "hidden from dos-box" action (using @) and disables the printing of the actual commands (only the result of the call will be displayed, but not the call).
- optionally here a title can be set (using dos: title FANCYNAME) or clearing the screen can be done using command cls
- following lines show a header
- then there is a little hack by calling net session. There is no need to understand what this command is doing. The only important information is, that it quits with error 5 (access denied) if you are not currently running in admin-mode. Standard output stream and error output stream will be redirected to nul (to nowhere), so that the only effect is that the errorcode is set to 5 (failed to call the application) or 0 (everything worked fine).
- line #7: The errorlevel is a pre-defined variable set by the return code of the previous application. (Unluckily I am not sure if successful applications always reset this variable properly to zero. If you want to be sure then use the command "set" to overwrite the value to zero).
- the following shows success or error message and jumps on error to the label in line 32 what means that the script stops there.
- echo. prints an empty row. echo without . shows whether the echo-ing is on or no (as disabled in line #1).
- set /P requests the console to read from standard in and to write the result to the variable.
- now we can check for the inputted values (/I for case-insensitive). The 2 equal-signs are similar to equ, but refer to text equality and not to numeric equality
- start calls an application run in its own dos-box what is a metaphor for run asynchronously without checking the return value or %errorlevel%. I started an own command prompt and call the command with /c parmeter.
pitfalls:
- the brackets work exactly the way they were shown above. Separation to own lines are not only forbidden, the script simply doesn't work anymore.
- if the server needs some time to startup and the client should be called a few seconds later, then it is a good trick to use a ping localhost (normally 4 seconds for standard 4 packets) to "waste" some time. (start cmd /c "ping localhost >nul 2>nul && Client.exe) Another solution is the command "timeout" what seams appropriate to.
cheers,
Daniel
