I have a project I am working on where I need to create an app and service package for Windows. I would like the service process to run as SYSTEM or LOCALSYSTEM so that credentials are irrelevant. The application frontend will be installed and executable by any user on the machine. Data from the frontend application will be passed to the service - most likely paths to directories selected by users. Once started the service will listen for a command to do some action while accepting the aforementioned paths.
I'm using C# on the .NET platform and I've looked into creating a standalone service and a standalone application separately as well as creating a WCF service library and host application - that's as far as I've gotten.
All of these methods seem overly complex for what I am trying to achieve. What is modern convention when attempting something like this? I'm willing and able to learn the best method for moving forward.
Edit: This was flagged duplicate. I'm not looking for information on HOW to communicate with a Windows service. That's remedial and not at all what I'm asking. I'm looking for validation that I'm on the right track and if I'm not, I'm looking for suggestions. I've been told that I'm on the right track and pointed towards named pipe binding.
Windows Service is certainly an option for hosting WCF, although it kind of is a deployment nightmare. It really depends on your environment and the capability and support of your system admins as I've had many clients where deploying a windows service, as you need admin rights to install and update it, was simply not practical.
Console applications may sound like a terrible idea but the practicality of being able to drop them on a share and run a powershell script to start them is very compelling.
But frankly IIS hosting has the most advantages in my mind as the product is designed for ease of deployment and up time. And you can use any transport binding in IIS that you can use in a Windows Service or Console.
As for the binding itself named pipe is not really a popular option in many enterprise scenarios as it is incompatible with anything but .NET. Although the same can be said for binary which is one of the more performant bindings. The WSHttpBinding is probably the most popular binding in scenarios that require unknown callers. WebHttpBinding is an interesting option as its HTTP/REST based, although that requires further decoration of your operations and honestly if your going that route you should really be using Web API.
I currently have an in house C# app that is delivered via click-once. I'm moving to the cloud and would like to have the Click-Once delivered from there (will be accessed from multiple countries and I can't use IP ranges to block out intruders), but it appears that the only way to secure the download is using windows security which is not an option for my clients.
I'm looking for a nice way to deliver the initial software and then keep the clients updated.
I've heard about WIX but I can't seem to find any information around updates from the internet and it.
Does WIX support this? If so can someone point me at an example or reference?
If it doesn't support it is there another solution someone can recommend?
Here is my usage scenario:
- User logs into a website supplying credentials, (username/password or certificate) then has the ability to download and install the application.
The application must check on startup of the app for a new version and if there is automatically download, install then run it. (would be nice if the user must resupply credentials for the update but not a necessity)
Bonus points if it will work on any web server such as a simple Node.js implementation.
WiX Only handles the installation via the bootstrapper or MSI you have generated, so I would assume that it's most likely a windows installer setting of some kind when it is first created. The element ClickThrough is supposed to be able to handle this scenario, though I don't know much about that.
The way my work colleagues dealt with this is by using IIS and an ASP.NET web service, along with a DLL that has methods to check with the web service if there is an update, and then prompts the user about the update and asks if they wish to update (did I say update enough in that sentence?).
Hope this helps.
We have a three tier application entirely developed in .NET 4.0 (C#). As the enterprise application server we use COM+ 1.5 (I know it's a little bit legacy...). There are a server part and a client part both developed in C# for .NET 4.0.
The server part exposes services inheriting the ServicedComponent class and returning objects which implement the "Serializable" attribute. The client calls the remote classes via the COM+ exported proxy of the component. We distribute the client app through ClickOnce and we have to install, with Admin privileges, the COM+ generated Proxy onto every client machine. This is the bad point.
So we are trying to evaluate other techniques which allow us to eliminate this proxy installation but it's not so clear how to do this. We'd like to find a low impact way that allow us to use the same COM+ part and including in some way the Proxy into the client side code.
We have tried to use code like this in the client part but still requires the COM registration.
Type comObjectType = Type.GetTypeFromProgID("SumNameSpace.SumClass", "servercomplus", true);
SumInterface comObject = Activator.CreateInstance(comObjectType) as SumInterface;
We thought that using in the client part the interface instead the class would have to work, but we have the exception:
Runtime.InteropServices.COMException (0x800401F3): Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))
This error should happen if there aren't the correct information about the Interface in the Windows Registry, but we don't know...
Any idea?
thanks a lot
There's no question you need the COM+ proxy installed on all the client machines, and you want to install it with the proxy installation package. The error you're getting is the result of the missing ProgID entry under the HKEY_CLASSES_ROOT hive in the registry. This registry entry, among others, is provided by the installation package. This isn't all the the proxy installer provides; I found a pretty good overview here.
It sounds like what you are really looking for is to create a custom application manifest for your ClickOnce deployment. This should allow you to bundle the proxy installer as a bootstrap prerequisite into your ClickOnce deployment. However the install will still require administrative permissions; I don't see a way around that (see note below). Here is a link to a tool that works with ClickOnce manifests that was created by Stackoverflow user Greg Jackman. I don't have any experience with this, but based on Greg's post it looks like it may be helpful to you.
One final note: even if you do find a way to run the installation package as a non-elevated user, you don't want to do that. Running non-elevated will change the way the package interacts with the registry. Short story, it will fail silently.
Use group policy to distribute the components?
We have two backend applications, one that is reponsible for acquiring data from the internet and storing it in a database, and the other that is effectively a COMET server, accepting connections from the internet, hooked into the http pipeline via the HttpListener API.
In development, both these items have been created as console applications that are started manually under an admin account. Obviously, this is unsatisfactory from a security POV.
When we move to production, both these applications will be ported to run as Windows services using ServiceBase.Run and provided as installers for installation on the deployment platform.
As somebody who knows very little about Windows security, ACLs and the like, I would like to know what steps I can take to secure these applications (such as have them run in an account of lowest necessary privilege) and how one would create an installer that sets up the necessary service accounts and privileges for these accounts.
To be clear, I am not asking how to make a service installer - we have this already, but rather what steps are required to make the service installer actually install the service under a low privilege account with rights only to the minimum resources required to get the job done. Part of the answer would be how to allow the service account access to the Http pipeline.
EDIT: We can probably use a custom action with code from here for the http pipeline reservation.
Are there any other steps one might take to shore up the security of such applications?
TIA
I hope these articles will help you :
Designing Applications to Run at a Low Integrity Level
Defend Your Code with Top Ten Security Tips Every Developer Must Know
CLR security
Security Fundamentals
Managing Directory Security Principals in the .NET Framework 3.5
Building A Custom Security Token Service
I want to turn a program I have into a service so I can use it without logging it. Basically what it does is it backs up specified folders to a specified location using SSH. However the problem I'm running into is I don't know how to tell it these items. I only know how to start, stop, and run a custom command with only an integer with a parameter.
How can I do this?
Windows Service, not a Web Service
edit: The folders it backs up will not remain consistent and will be updated at every runtime
You can instantiate your service and pass command line arguments using the ServiceController class.
using (ServiceController serviceController = new ServiceController(serviceName))
{
string[] args = new string[1];
args[0] = "arg1";
serviceController.Start(args);
}
"arg1" will then be available as regular command line arguments in main() when Windows starts up the service.
I see that you (or someone) voted Sebastian Sedlak's answer down, because he mentioned hosting a WCF Service in the Windows Service. Your reply was
It's in nice bold lettering in the question. Not a Web Service, therefor WCF is out of the question
I think you misunderstood what he meant. He wasn't talking about a Web Service. He was talking about hosting a WCF Service within your Windows Service.
It's far from the same thing. You can host a WCF Service within any Windows (Forms/Console/Service) application. The point of doing so, is that the application is then reachable for communciation via its internal WCF Service, in the same fashion as you can communicate with a Web Service (you can also host WCF Services in IIS, btw, which would then make them "Web Services", in the sense you seem to be referring to).
In a Windows Service, this means you can send any command to it and also get any information you want from it - while it's running.
In fact, I am working on a project right now, which is a Windows Service that I need to be able to contact and pass commands to - and get information from - at runtime. For example, I want to be able to tell it where to store certain things, what to log, to have it reset/restart - and poll it for status messages. I do this by hosting a WCF Service inside the Windows Service. That WCF Service exposes a set of methods, that in my case includes receiving commands and returning status information. So when the Windows Service is running, I can contact it (even remotely), via its built-in WCF Service and tell it what to do.
This an extremely easy thing to implement, and in the case of Windows Services, can provide you with a much richer interface to the Service than through the basic standard commands.
However, you specified that you wanted your Windows Service to receive its folder settoings each time it starts up, which makes such a passive setup less than ideal (as it would be unable to do anything until you passed it the right folders).
One way to deal with this (using a hosted WCF Service), would be to have the Windows Service running all the time (i.e. automatic startup). Its default state would be idle. Then you could issue it a "start processing"-command, feeding it the correct folders to work on (through a call to the corresponding WCF Service method). Similarly, the WCF Service would expose methods giving you the status of the application (current folder, progress, busy/idle etc). Once the processing is done, it would go back into the idle state, waiting for the next set of folders to be supplied to it.
Doing it this way would make it very easy to control remotely - you could even make an online administration panel for it, accessible from anywhere.
The issue, is that, while passing in parameters is not difficult, when the machine restarts and windows tries to restart the service, those parameters are not there. they only exist when someone starts the service from the command line.
for example. I have a windows service which hosts a WCF service. I want the users to be able to specify a non-default port number for the WCF service to listen on. They do this by starting the windows service like so... MyService -port:xxxxx
Which works fine, until the server is rebooted, then windows restarts MyService (but without parameters) and the wcf service defaults to original port #
Any service is capable of receiving command line arguments at start-up.
Would it be possible to use a configuration file to specify these items?
Store the service's startup parameters in the registry: and then, when the registry starts, it should read its startup parameters from the registry.
Windows services have executables like any other. I believe you can write it to accept command-line parameters and specify those parameters in the Windows Service configuration. You can also have it read a config file. If you're using .NET, there are config file classes in the framework.
Why not just Host a WCF Service in the Windows Service to obatain such "admin" functions?
(Remoting is also possible)
RE: config file.
Of course a config file can be used.
And the file can be changed while the service is running.
This would be a nice solution if the config file changes in fact.
All my services use an XML config file, wrapped in a class for easy reuse.
The wrapper has an option to monitor the XML file using fileMonitor for changes, optionally refreshing the content of the config file automatically, and finally raises an event to the service class.
The service then has the option of "resetting" itself as needed to incorporate the new values in the XML configuration file.
Placing configuration into the registry has a few issues:
Security (ie: installer being granted access), depending on what tree is used
The service will not be aware of changes
Portability - although minor as the install should setup registry settings
Where an XML file is easy to copy, edit, share, view and understand.
Throw in some good COMMENT blocks and a detailed XSD file, and it becomes a source of good documentation too.
Look into XPath for easy navigation and extraction of values within the XML file.
$0.02
... david ...
Concerning the app.config file - I'm rather sure that your service will read and use those files as I write all my windows-services this way ;)
So just put everything you need in the app.config under "application" (not user) and put allway edit the "yourname.exe.config" in the folder where you "InstallUtil" the service from.