Auto Upgradable WCF service - c#

I'm working on application that does some tests on Windows Servers. Front end of application connects to small application installed on each server via WCF.
Problem with this flow is that when i make slight update to small application on server or even change WCF server signature i should re-install this application again on numerous servers.
How did you tackled such problem or would advice to ?

WCF handles most compatibility issues without complaining such as adding new parameters to a method (old clients still work, new parameters are initialized as default). Removing params also does not affect the client (extra params ignored). Other changes and how to deal with them can be found here: http://msdn.microsoft.com/en-us/library/ff384251.aspx.
For deployment, as stated in another answer click-once is a quick way to have client machines auto-update, if you prefer more of a push model, you may be able to setup msdeploy to push a build out to the other machines (provided you have access to them).
Hope this helps.

could you use a more restful service, this would give you a little more flexibility to change?
Could you use click once deployment, to automatically redeploy when the app changes (if it is an app)?
http://msdn.microsoft.com/en-us/library/ms730203.aspx

Related

What is the ideal method for creating a Windows application and service package?

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.

Cannot keep alive Web Application on IIS after Recycling or Restarting

I have an MVC application that send an e-mail periodically using Quartz.NET. Although the published application works properly on IIS, it cannot works after recycling application pool or restarting the application on IIS. Searching on the web I found several post suggesting to make some changes on config files or IIS, but none of them working properly. So, is there any method to solve the problem? I need a solution that can be applied on application side (or on IIS side if it is simple just making a config changes, etc.). I think this is a common problem when keeping an application on IIS, isn't it?
Note: I use Windows Server 2008 and IIS 7.5.
You do not mention in your question where your application is going to run so I guess it's going to be hosted in-house.
Following your comment I gather you do not have any problems installing and running a Windows Service on your server.
My suggestion - and something I've implemented in the past - is to use the ASP.NET MVC application only as a UI where you create, delete or suspend your jobs/triggers which will be persisted in a database so, whatever happens to your application, you won't lose your jobs/triggers and they will be executed as soon as the application goes back on-line.
The database will be shared with the other layer, the Windows Service, which will be responsible for running your scheduled jobs.
First step is to setup and use AdoJobStore to store Quartz.Net data. As you can see in the post there are a few providers you can use.
Second step is to create and configure your Windows Service. I would use TopShelf to host it. The implementation is very simple and straightforward; plus you can use the Quartz.Net integration provided here.
If you go through the documentation you won't find any problem integrating the solution.
Quartz.Net depends on some configuration you have to add in your app.config/web.config. In this answer there's a detail explanation about the configuration and AdoJobStore.
There are a few things to remember implementing this type of solution.
Your Web Application is going to set the property threadPool to ZeroSizeThreadPool in your config:
<add key="quartz.threadPool.type" value="Quartz.Simpl.ZeroSizeThreadPool, Quartz" />
or in your code:
properties["quartz.threadPool.type"] = "Quartz.Simpl.ZeroSizeThreadPool, Quartz";
and it's never going to start the Scheduler (your windows service is going to use that).

Replacing Click-Once with another installer that supports non Windows Security

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.

Best Practice for storing settings for a .NET Windows Service: Service Property Settings, Serialization,

I am working on a .NET Windows Service where I am trying to store settings that will be used when the service is started and while it is running. I have searched through posts on SO and found that using the Settings in the properties of the project is great for use with console and winforms applications. However, Google and SO are silent when it pertains to storing these settings with a windows service.
Does anyone one know if it is proper to use these settings in a .NET service? If not, is Serialization my next best choice? Has anyone had practical uses for settings in a service and found that it is best to use a specific method?
I've had problems with using Settings.settings. For instance, if you need to make changes at run-time, there can be problems with the settings being overridden by those that were initially stored in the settings.settings file as opposed to what's shown should be stored per the app/web.config. Consequently I make all my Web Service proxy settings "static" in the properties and pull them manually from the app/web.config via a helper method and programmatically set them. This circumvents any problems.
An example of the issue we had: I pointed my development machine to a web service on a test server to test the code that consumed the web service. When the code was moved to our test server, no problems manifested - as the test server was still pointed at the same web service on the same test server. However, when we moved the application to the production server and reconfigured the web.config to point at the production server we started getting screwy results. It took quite a bit of effort to pinpoint that even though we had reconfigured the application to point at the production server's implementation of the web service, it was still connecting to the web service on the test server. It wasn't until we changed settings.settings on my development machine and recompiled the application that it worked. Further to this, we also noted that if there were DNS problems connecting to the production web service, rather than fail, it fell back to the original settings that were specified in the settings.settings from when we created the web service proxy in our application - the proxy generator actually hard codes them. Consequently when there were network outages, instead of getting easily diagnosed connection failures, it simply fell back to the test server and we started getting incomprehensible data issues. I'm not sure if this was a known problem or if it's been fixed, but it's certainly something you should be aware of.
Consequently, since then, I've always set the service properties to static and used a helper method to read the correct settings from the web.config directly and written them programmatically as this seems to circumvent the problem.
It may seem like the problem I had has nothing to do with yours because I was using Web Services which isn't anything to do with Windows Services, however, any environment where you need to be able to change the settings at runtime without having to recompile could be affected by this issue, so you should be aware that if you run in a Dev/Test/Production environment or indeed any environment where you need your app to be reconfigured at run-time (i.e. without having to recompile) that you can get unpredictable results when using settings.settings. Beware.
I normally use the registry to store information I need in my service i.e port etc.
string lsbkey = #"Software\mycompany\adas";
RegistryKey adaskey = Registry.LocalMachine.OpenSubKey(lsbkey, false);
try
{
object regip = adaskey.GetValue("IP");
object regport = adaskey.GetValue("PORT");
localip = regip.ToString();
localport = int.Parse(regport.ToString());
}
catch (NullReferenceException ne)
{
localip = null;
localport = 0;
writelog(#"Aborting Service, IP or PORT doesn't exist in \local machine\software\mycompany\adas : "+ne.Message);
status = 0;
}
I use the Settings.settings stuff for storing the config for my services and I've had no problems. Just the usual that the user settings that are changed will be stored in it's usual obscure location that you have to hunt around for if you want to edit them by hand.
I dont see any reason not to use Settings in the properties of the project as you would for a winForms app. We do this, and it works fine.

Is it possible to create a standalone, C# web service deployed as an EXE or Windows service?

Is it possible to create a C# EXE or Windows Service that can process Web Service requests? Obviously, some sort of embedded, probably limited, web server would have to be part of the EXE/service. The EXE/service would not have to rely on IIS being installed. Preferably, the embedded web service could handle HTTPS/SSL type connections.
The scenario is this: customer wants to install a small agent (a windows service) on their corporate machines. The agent would have two primary tasks: 1) monitor the system over time and gather certain pieces of data and 2) respond to web service requests (SOAP -v- REST is still be haggled about) for data gathering or system change purposes. The customer likes the idea of web service APIs so that any number of clients (in any language) can be written to tap into the various agents running on the corporate machines. They want the installation to be relatively painless (install .NET, some assemblies, a service, modify the Windows firewall, start the service) without requiring IIS to be installed and configured.
I know that I can do this with Delphi. But the customer would prefer to have this done in C# if possible.
Any suggestions?
Yes, it's possible, you may want to have a look at WCF and Self Hosting.
Yes, it is possible (and fairly easy).
Here is a CodeProject article showing how to make a basic HTTP server in C#. This could easily be put in a standalone EXE or service, and used as a web service.
One technology you might want to check out is WCF. WCF can be a bit of a pain to get into but there's a great screencast over at DNRTV by Keith Elder that shows how to get started with WCF in a very simple fashion.
http://www.dnrtv.com/default.aspx?showNum=135
You could take a look at HttpListener in the .Net framework.
I would highly recommend WCF. It would fit very well into a product like you are describing. There are a good number of books available.
Sure, you can do that. Be sure to change the Output Type of the project to Console Application. Then, in your Main function, add a string[] parameter. Off of some switch that you receive on the command line, you can branch to ServiceBase.Run to run as a Windows Service or branch to some other code to run a console application.
This question is somewhat older but since I needed something similar some time ago it felt like this question is still relevant.
I wrote a small Rest-API with NancyFx and OWIN. OWIN is a standard interface between .Net applications and web servers. With OWIN it is possible to create a self-hosted WEB-API. Nancy on the other hand is
a lightweight, low-ceremony, framework for building HTTP based
services on .NET ยน
The combination of those two makes it possible to create a self-hosted C# Web service.
I am quite sure that there are many more possibilities to create something like this by now but since I used it like this I thought the Information might be useful to someone.

Categories