We have got a web application and a windows forms application. The web application contains a download link to download this forms application.
This forms application will check the client machine privileges and drive space etc. and will update the values to a global database using some webservice calls.
So the web application will continuously checking the global database for the status ie how much checking has been completed by the forms application.
So as soon as the download popup appears for the forms application to download, the web application will start to check the status. But if a user cancels the download or if a user close the forms application, then in these cases how the web application can stop checking for status.
But in my case the web application will always check for the status change , even if the client cancels the download or closes the forms application. So how to avoid this?
I think a timeout is your only real option here. Basically the web side will only check for a certain amount of time before giving up. Your status table in your database should include a "last update timestamp" field. If the status is not "complete", and the current time is greater than that timestamp by X seconds, the webserver assumes the process has timed out.
You could try to have some thing like a switch as part of a record or some thing in the Database, so the very next time your web app tries to read lets say the bit field it would know that it should stop checking. You could control this bit field as ON & OFF via your forms application. Then your web application you can setup a polling mechnism that checks the db every so often before timing itself off all together based on the bit field or if not been done then aftera period of time.
Having said that your forms application would need to be able to call the outside world where your db is some where located and update it, it can be done many ways, web service call, http, ect...
Update:
I apologies for the delay in replying but did you understand what I said? If your winforms application can call your web service then it can tell it to store a flag field some where like a record in the db for example that your web-application is polling and checking and then by setting that flag field your web-application would know to stop doing any thing with that record, item.
As you mentioned you are worried about:
User clicking cancel on download:
In this scenario you would not set the checking of your record by your web-application unless the user has downloaded and run your win-forms application for the first time, so dont start checking upon dowload of the win-forms application but start checking once for the first time the user has opened it, you can do this upon start of the winforms application by setting the flag field from your winforms app by calling your web-service. You will need a polling mechanism on top of this every so often, like a service.
When the user closes the winforms application
In this case you would upon termination/close of your winforms app call your web service and set the flag field not to check that record, item any more.
You will need polling in any case as I am thinking you will have many users and hence you will need to monitor the db for incoming messages from your winforms app. Also please be aware as some users are behind firewalls, limited security permissions on their machines and on private networks and your winforms app may not always be able to call your web service.
Hope that helped.
Related
I am new to .NET and seeking help for the Windows Service Updates Notifications.
I have a use case that is somewhat similar to "https://stackoverflow.com/questions/41232170/c-sharp-show-notification-prompting-a-update".
The application is developed in C#.NET and is deployed and running as Windows Service.
However, the application is not using any MSI installer to install it. I am using a batch script that configures the Windows Service application.
Now, I want to show the notifications about the updates about the Windows Service to the user, when the system gets restarted.
I came across about the usage of WCF or by using the Task Scheduler, but not sure which one would be the better solution.
Please advice.
Ok, there are (were, because MS disabled the first one that I'm going to explain) two ways to notify your user about updates from a service.
First, the bad, ugly (and non-working in recent versions) way: interactive services.
You can configure a service as interactive, if you add the SERVICE_INTERACTIVE_PROCESS flag the service will be able to create a GUI that will be attached to Display_0. This presents a ton of problems (trying to show a GUI when there's no user session, if you have two sessions open only the first one will show the GUI and so on) but it's a cheap dirty way to show data to the user. Avoid it.
Second, the right way: a standalone GUI program.
In this case you create a secondary program that will show the data to the user, you can start it with the user session or let the user decide if he wants to receive info by opening manually this application. This program needs to receive the updates from the service in some way, which is better is up to you but I would use UDP for this, in this way your service doesn't needs to care if any GUI app is connected or not, you broadcast an UDP message and everyone listening will receive it, you don't need to mantain a server that handles connections, you don't need to have an storage in order to maintain the event data and it will support any number of instances of the GUI (if more than one user has started a session in the machine all of them will get notified).
But as I said, that would be my preference, you can do it as fancy as you want, you can use Pipes, use a file that contains the event and use a FileSystemWatcher to get notified when changes happen in it, you can even host an ASP .net web app which implements a SignalR hub and then you can create your GUI in html. It's up to you decide which mechanism is the best for your scenario.
I want to pop up an application using windows services.
Right now the code that I am using is:
System.Diagnostics.Process.Start(#" ");
That code does not pop up the application when I start running the services.
You can not do that. User session interaction has been removed since Windows Vista. The process would be started in the session that the service runs in, which per definition is not desktop interactive.
What you can do is run windowless console-only tools.
Long story: Before Vista all services ran in the same session as the first logged in user ("session 0"). Since this is a security issue, this was changed in Vista, where a dedicated session ("session 0") is active from the start for services. The first user logs into session 1, the next user into session 2 etc.
Due to the separation of these sessions it is no longer possible to create desktop interactive services - there is no desktop session for services.
This also means you can not display message boxes or run desktop interactive tools in session 0 - there's nobody who can see them.
Is that the exact code that you're using?
If so you're not actually giving the process anything to start, just an empty string. You need to pass it the name of the executable.
For example:
System.Diagnostics.Process.Start(#"C:\Windows\System32\notepad.exe");
If this is not the exact code, please post modify the question with the exact code.
I have a windows service which gets the screenshots. But its creating only black screens. I know this happens because of session 0 isolation. I searched on internet and couldnt find any approved solution for this problem any working ideas will be really good.
1- Is there a way to change the session of a windows service and get the desktop screen of another user's session like session 1, session 2?
2- Is there a way to start a console application which runs in an another session other than session 0 from a windows service?
a windows service is designed to run also when there are no users connected, it works like a server process always up and listening, or up and doing something, or idle.
I think what you need is a client application which runs inside every logged user' session and eventually does the job then, if needed, communicates with the service to carry some job done.
I am saying here that instead of having the windows service running in another session than 0 you can create a small executable (probably with no UI at all) that starts up from the start up folder of all users at every user login. such application is then running inside the proper session and has access to it, it can get the screenshot then either store it somewhere itself or call some end points in your Windows Service (running always in session 0) and make the service to elaborate the screenshot taken from the client application of it.
this is the way I would do it, not trying some "magic" to tell Vista and 7 to start a service inside a session of a user that in the end is not logged in yet when the system starts.
Is there a way to change the session of a windows service and get the desktop screen of another user's session like session 1, session 2?
No.
Is there a way to start a console application which runs in an another session other than session 0 from a windows service?
This can be done but it's messy. It involves impersonation of the logged on user, manipulation of user tokens, and launching a process into a different session with CreateProcessAsUser(). This article describes what is needed.
As an aside, you don't want a console application because that will splat a console window on your screenshot. You just want a standard Windows app (using the GUI subsystem) but one that does not show any visible windows.
I wrote a C# application using RESTful web services. This application should interact periodically with our server application. I want this program to keep running in the background even if the user logs out of the computer. How can I do this in C#?
If you don't want your application to stop when the user logs out, then the application can't be running in the user's session (really a WinStation). That implies your app needs to run in a different session. The sessions that don't logout are service sessions. Run Task Manager and add the Session ID column, and view all processes, and you'll see what I mean.
So your application needs to run as, or be launched by, a service.
In addition to the first answer don't keep the service running under the specific user account. If you do so then also it won't work if you logged off.
I wonder is it possible to run my application before login on windows.? Its actually a WinForm application(Preferably other than Windows service).
I mean my application must be running even before log in and it should sit on System Tray from which I can "show" or open Interface for user.
To have:
Something happen between system startup and user login
An icon in the notification area for users to interact with
You must break your application up into two separate components. One of these will be a WinForms/WPF application which provides the notification area icon and allows the user to interact with it. The other will be a Windows Service, or possibly a scheduled task.
Once you've done this, the windows service can focus on doing whatever needs to be done prior to logon and the notification area application can assume responsibility for showing the results, or whatever else to the end user.
To answer the question you posed in comments regarding reading data from the Event Log, yes this is possible. There are other questions on here which will give you that particular answer:
read the windows event log by particular Source
Read event log in C#
This MS article might help but it is a bit old:
http://support.microsoft.com/kb/142905
Hopefully it'll put you on the right tracks though.
I think, it doesn't make sense, to acquire user input before a user has logged into the system. So, if the application needs input from a user, why start it before the use has logged in? If the application just starts some background work, than you should use a windows service, as this is the prefered way in windows.
Type in run gpedit.msc, for Group Policy,
There you can set start up script.
Application will launch before Windows Login,
Step to produce :-
Start --> Run --> gpedit.msc --> Local Computer Policy --> Windows Settings --> Script (Startup/ShutDown),
Add you .exe
It will launch Before login.
Do not try more in Group Policy, it may happen harmful for System
By Programmatic logic,
Try with registry key
this value is updating in registry,
by our program we can update directly registry then we can call application
You can schedule any application to be run when computer is powered on using Windows Task Scheduler. There is a corresponding option there.
But why would you need this? You should use a service for this.