I need to run a GUI application as part of BuildMaster deploy. Currently I added a PowerShell action that launches that application. The problem is the process is started but there is no GUI. I guess it is caused by the fact BuildMaster agent (that executes the PowerShell script) is a Windows Service. Is there any way to resolve it?
A Windows Service cannot launch applications with a GUI (as of Windows Vista / Server 2008 and newer at least), as they run in session 0 and will never be seen by an actual user. You might be able to hack around this by setting the "Interact With Desktop" flag, but that isn't really recommended at this point.
Is it possible to re-architect the application that has to be run into something that doesn't present a GUI and instead accepts command-line arguments?
Related
First of all I don't understand windows services. Coming from a linux background it feels like very much of a black box.
We have a .net core 6 application that we want to run as either an executable or as a service. It uses the
WebApplication.CreateBuilder(args);
function. It also logs a lot to stdout (I know... we should be using a logger)
It works fine when we run by clicking the executable. But when we register it as a New-Service using powershell it will start and run for a few seconds and then stop.
We have done this with the older .net code and we put a special if block to detect if the application is running as a service or in the console.
Im not quite clear how the windows service knows that the application is not running. Do we have to return something from the application to show it started successfully.
Is there a way to see stdout when it run as a service.
Fitnesse download page only has option for standalone.jar and this is also what the instructions are for. Is it somehow possible to install FitNesse on a separate app server, such as Tomcat? There's not directly any war/ear to download, but can I bundle one somehow?
I'm experimenting with acceptance testing frameworks and need to run the tests on a very specific test environment, and thus require a possibility for installing on an already running app container where the tests are executed. Changes for getting even java executable from command line in this environment are slim, and if possible, the process would take probably months to realize.
I do not believe it is possible, but even if you were to get the wiki running inside an app server, a test run would still try to start a new java process (by starting the java executable) so you still need access to that executable.
But does the test environment really need to be in the app server? I usually use FitNesse to test an application from the outside: the test framework makes remote (http) calls to an application running in an app server, but it does not run in that same app server itself.
I am attempting to upgrade an existing system from Windows XP Professional / IIS 5.1 to Windows 7 Ultimate (32-bit) / IIS 7.5. The original system ran a classic ASP website (only available to the localhost) that used 'ASPExec' to launch desktop applications on the local machine (.bat, .cmd, .exe, etc). Under Windows 7 Ultimate / IIS 7.5, the applications fail to launch from the ASP page.
As tests (The end goal is not to launch notepad), I have tried:
<%
Set Executor = Server.CreateObject("ASPExec.Execute")
Executor.Application = "notepad.exe"
Executor.ShowWindow = True
strResult = Executor.ExecuteWinApp
%>
I have also tried:
<%
Set wshell = CreateObject("WScript.Shell")
wshell.run "notepad.exe"
Set wshell = Nothing
%>
Both methods will cause notepad.exe to show in the Windows Process list, but fail to launch the application on the desktop. This is true for any .exe I try to run, and .bat or .cmd files simply fail to do anything.
With IIS 5.1, the original author of the ASP application used the "Allow Service to Interact with the Desktop" option on the "IIS Admin" service and "World Wide Web Publishing" service to make this work. All issues aside with allowing desktop interactive services, IIS 7 no longer uses the "IIS Admin" service, so this is not an option.
I am looking for either a workaround from the Windows/IIS side or another option in ASP that might acheive the same desired end result.
You won't be able to do this with Windows 7/IIS 7.5. The reason this worked was because you were running IIS5.1. Back in the days of IIS5.0/5.1 you had three different process models:
In Process (or Low Isolation mode) - where every site ran inside the inetinfo.exe process
Pooled Process - sites ran in an external surrogate process inside COM+
Out of Process (or High Isolation mode) - where each site runs inside it's own COM+ process
Most likely your IIS5.1 instance is configured to run in "In Process" mode and under the SYSTEM account. Because you can configure the IIS service to interact with the desktop, and because your Classic ASP script is being executed inside this process it is able to launch executables and they appear on the desktop.
In IIS7 life is different. Your code will run inside an application pool process which is spun up on demand. There is no way to configure pool processes (w3wp.exe) and allow them to interact with the desktop, even if running under the local system account.
Also unlike IIS6 you can't configure IIS7 to behave as if it's IIS5; IIS7 is a bottom up rewrite with a new architecture.
A possible workaround would be to write a simple WCF service with a HTTP endpoint that starts when the user logs on (hosted in a Windows app that hides or minimises itself to the notification area). You could then make calls to this service from your Classic ASP code using something like MSXML2.ServerXMLHttp and get the WCF service to launch these processes on your behalf.
This archived copy of chapter 29 of Keith Brown's "The .NET Developers Guide to Windows Security" explains the machinations involved in getting a service application to interact with the desktop:
The .NET Developers Guide to Windows Security - chapter 29 - How to Display a User Interface from a Daemon (source: archive.org)
Quote:
Option one is to get yourself into the interactive window station, and
option two is to have a process already in the interactive window
station display a UI for you.
An easy way to put a daemon in the interactive window station
(WinSta0) so it can have its own user interface is to package it as a
service that runs as SYSTEM and check the box that says, "Allow
service to interact with the desktop." This tells the SCM to launch
your service process in the SYSTEM logon session (WhatIsALogonSession)
and to attach your process to WinSta0 instead of the noninteractive
window station in which the SYSTEM daemons normally run,
Service-0x0-0x3e7$.
This is what you probably have already on your XP box. But as I explained, there is no way to configure worker processes to do this because you can't configure the "Allow service to interact with the desktop." flag, even though you can configure a pool to run as the local SYSTEM account. When the book was written this applied to Windows 2000/2003. With the advent of Windows Vista/2008 and onwards you have the added complication of UAC and getting past that as well.
What you should consider instead is option two: Use two processes
instead of just one. One process must be launched in the interactive
user's logon session and WinSta0. It should contain all the user
interface elements you need, and it can connect to your daemon process
using any secure form of interprocess communication you're comfortable
with
This is essentially what I've suggested.
I wrote an asp.net web application, which launches a powershell script. The program ran without any issue when I debugged it in my development environment. After publishing and deploying the asp.net web application (by the way the target server is the same machine localhost), by clicking the button for launching the powershell script, nothing happened. It means the powershell script was not launched. I attached the debugger to the deployed asp.net and saw that the Shell.Invoke() was hit as before and the command was also correct. However Shell.Invoke() returned immediately and the powershell script was not launched. In my environment the powershell execution policy is RemoteSigned.
Since the program in the development environment works perfectly and in the deployed case also hits the same code, I don't think it has to do with the code but more with security, certification,...???
Has anyone experienced the same? If yes, please advise me what I should do.
I appreciate your help in advance.
Thx
Might have something to do with the application pool identity not having the right permissions:
You might want to run your PowerShell invocation from a system service with explicit permissions though. That will take a steeper curve though.
I've created an Azure server instance. I've deployed a simple application to it. As part of the deployment process I enabled Remote Desktop Connections.
I have some standard ASP.net applications that run on Windows, is there something to stop me deploying these applications manually to IIS using Remote Desktop. I've read so much about having to migrate standard ASP.net apps to Azure. I don't want to this as we will have customers who will still use Windows Server 2003/2008 so I don't want to have to maintain 2 versions.
Well, as I understand it, in theory you could deploy stuff using remote desktop. But when the instance shuts down/restarts you'll lose it all (unless you've built it into your startup scripts) and have to re-load everything each time. The main reason they suggest you have at least two instances is so that when one shuts down for updates etc there is always at least one other running.
The "Windows Azure Accelerator for Web Roles" project allows you to create an Azure web role which then enables you to use web deploy for all your other web sites - I'm guessing that will be a whole lot better approach and is definitely worth a look. Also, I believe smarx.com is a good place to browse for info and ideas.
Using a startup task and the Azure Bootstrapper you can download, unzip, install almost any kind of 3rd party software that supports either xcopy deployment (just copy the files) or an unattended(silent) install.
Assuming you aren't using Azure storage or anything like that, there shouldn't be any difference with the IIS application. If you are using anything specific to Azure, you can use the RoleEnvironment.IsAvailable to test if you are running inside Azure or not. That will return true for the emulator as well. If you want to use Azure storage from both, you can add the settings in the web.config to use if not running in Azure.