I have window XP 2003 server, which is placed in a room where no one can enter to logon it.
for monitoring some applications
I created a console application myServer.exe, which dont have any UI,
I want that this application (e.g., myServer.exe) start automatically as window bootup (e.g., before window logon)
and I need to do this work using windows service.
(note: please don't suggest me any other solution, I need to use windows service to accomplish this task)
The WinNT resource kit includes a utility called SRVANY.EXE that can be used to run any application as a service. ocdecio's solution is better but if for some reason you can't redesign the app SRVANY.EXE may work. Here's the KB Article.
You can develop Windows services directly in C#. If you have Visual Studio Professional, there is a built-in project template for a Windows service.
MSDN has a walkthrough of creating a service with C# that explains the process clearly.
If you don't have Visual Studio Professional, you can still create a service. You'll just need to create a class that inherits from System.ServiceProcess.ServiceBase manually.
A quick Google search turned up a couple of other links that may be helpful to you:
http://www.codeproject.com/KB/system/WindowsService.aspx
http://www.c-sharpcorner.com/UploadFile/mahesh/window_service11262005045007AM/window_service.aspx
Related
We need to upgrade a current Windows application that extracts data from a remote Oracle database and writes it to a text file on the local disk. This application will be scheduled to run at specific time.
Right now we have a Windows forms application with config file and using ADO.net and direct sql statements in the code first built using VS 2005.
What is the optimal upgrade path given we have Visual Studio 2015 and Windows server 2016.
Can this be accomplished using other than Windows form Application? Thankyou!
One way to do this would be to try to move the logic to a console application and then use the Windows Task Scheduler.
You could also use a Windows Service for this: Windows Service to run a function at specified time
Personally, I think that the Windows Task Scheduler with a console application would likely be easier. (That's just my opinion, though).
Otherwise, you could use UI Automation for this, but it would be a little annoying. (There are other ways of doing this kind of automation that can be found on Google; I suggest searching on "how to automate a Windows Forms application" if you'd prefer to use a different way to do this).
A couple other references:
how to automate some actions on Windows form Application?
How to Automate simple Windows Form Application using MSAA?
In advance, sorry for stupid question, but all search results in google are off-topic for me.
I want to create a C# application, that will run continuously on an Azure VM. It should NOT be event driven, as it will use different factors (db monitoring, time schedule, overall usage) to decide its activity.
Now, should I just create a console app in VS Express 2013 for Desktop and run it using RDP on VM? Or is there some azure-specific project that I can use (maybe for better integration with management portal)? All I can see and find is web-related (a website, a webjob, a background worker, a webapi), and mine app will not in any way be accessed remotely (it will periodically check db shared with a ASP.NET website)
It is possible. You should create the equivalent of a Windows Service, but then for Azure.
There is a useful question for that already on SO: Windows Service to Azure?
It has a reference to a full walk though: Migrating a Windows service to Windows Azure.
The corresponding azure type is "Cloud Services / Worker role". They work just as windows services.
So you can basically take all classes from your windows service (except Service1.cs) and put them in the new azure project.
The copy all start/stop code from your Service1.cs to the corresponding class in your new Cloud service project.
http://www.windowsazure.com/en-us/documentation/articles/cloud-services-dotnet-multi-tier-app-storage-4-worker-role-a/
I would like to download a file to the DownloadsFolder in a Windows Store App. And then I'd like to bring up a Windows Explorer open on the DownloadsFolder (actually on the folder I create in the DownloadsFolder)
But I can't figure out how to do it.
This stackoverflow question Launching a Desktop Application with a Metro-style app suggests using Launcher.LaunchUriAsync. But the documentation claims:
You cannot use this method to launch a URI in the local zone. For example, apps cannot use the file:/// protocol to access files on the local computer. Instead, you must use the Storage APIs to access files.
And indeed, I was trying to use the "file:" protocol to bring up the explorer window. When I did try this mechanism Launcher.LaunchIUriAsync fails.
If the browser can do this, why can't I?
Is there a way for me to bring up windows explorer, or is that outside the real of possibility?
I don't think you can launch the Windows Explorer from metro. One thing you can use, however, is the File Picker.
http://code.msdn.microsoft.com/windowsapps/File-picker-app-extension-0cb95155
If you're willing to have some non-Windows Store components in your solution, there is a workaround for this. Although you can't launch a process directly, you can always run a HTTP listener inside a Windows service which listens for commands from your sandboxed Windows Store (Metro-style) app and launches Explorer (or any other process) for you. A trivial way to do this would be a Web API service inside a Windows service - just implement the GET action in your controller and have arguments for the executable to launch and optionally executable arguments as well.
This is kind of doing an end-run around the sandbox security, though, so you might want to have a tailored Web API instead which just launches a pre-packaged set of apps (like Explorer or one of your own apps).
Of course, for consumer apps this is not a good solution because you can't just install everything from the Windows Store. For LOB apps, though, it's not a bad compromise because you typically have more control over the environment. This is a good way to surface some metrics or other data into a live tile and have your desktop app launch when the tile is clicked. Whether or not this makes for a good user experience is a totally different conversation.
BatRT allows you to run batch file commands from WinRT applications. It utilizes URI calls. This can be used to open up applications or perform file operations.
I have purchased a license of AddTapi.NET to simplify my development using TAPI in a product that runs as a Windows service. I was able to use the TAPI in a Windows GUI and console application and ported the code into my Windows service. At that point, I noted that the code which uses the speech API such as TapiCall.Speak or TapiCall.Play (wavefile) was not generating sound on the phone line and was remaining silent.
There are a couple of previous questions that may relate to my issue.
Question: Playing Voice over a modem from a Windows service indicated a problem using speech that was resolved by spawning a GUI thread in the Windows service. I attempted to do this but was unsuccessful in getting the speech to be heard on the phone.
Question: Access violation with Tapi in Windows service seems to indicate an initial problem with TAPI in a service yet was resolved by using the AddTapi product. The ticket does not explicitly mention the use of the speech API though (SAPI)
I am programming in C# using Visual Studio 2010 and .NET 4.0. I am trying to get this to work on Windows 7. I received an e-mail from AddTapi that indicated that Microsoft changed the security to disallow use of the voice subsystem from services in Win 2008 Server, Windows Vista, and Windows 7. The above articles seem to indicate some success with AddTapi although it may not be on Windows 7.
Given that the main system that I am working with is a Windows service (and child processes), what would seem to be the best approach to getting the speech to work. If I put the SAPI code in a console application, I would like this to be managed without requiring a user to be actively logged onto the computer. There is nothing graphical about my TAPI code. Should I take an approach similar to Article: Launching an interactive process and spawn an interactive process? Have there been any success stories using TAPI speech in a Windows service?
We resolved this problem in AddTapi.NET 5.0. Version 5.0 can use Speech API (TapiCall.Speak and TapiCall.Play) in Windows service applications. There is no need to use a separate process and the service can run under default Local Service account.
For everyone who doesn't use AddTapi.NET, the key is to use SAPI5 SpVoice object speaking to a custom stream. You cannot instantiate SpAudio or SpMMAudioOut objects in Windows service, so you will need to implement your own stream class and set SpVoice's output to that stream.
I had the same requirements as your project (TAPI in a Windows Service using AddTapi.NET). I also received the same response. I tried some of the other posts out there recommending that I run the application in a separate thread so I tool my entire solution and converted it to a WPF Application with a simple page that would never appear but had all the AddTapi configuration happening in the constructor.
NO SUCCESS.
The application would run fine when run from the WPF application but when the WPF page was instantiated in the STAThread enabled thread Play and Speak still would not work. I have been looking all over for an answer on this but there isn't anything but others stating that there really is no solution (no real solution).
Running my application through a seperate process simply won't cut it and since running in a seperate thread won't work either I'm going to have to consider running this application as a regular windows app (will require logon).
Wish I had a solution, sorry.
In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).
I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)
There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.
Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.
There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.
Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.
If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.
Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app