I have created a windows service which consumes a WCF Service hosted at some location.
The WCF service endpoint is specified in app.config of this windows service.
I am not sure whether what i want is really the right understanding i have about services or not.
So here i go.
I have created a wix installer which encapsulates all my dependent third party dll's into one installer.
Now, the question is do i have to copy all the xsd files the client folder?
If yes , then does changing the WCF endpoint in app.config later once installed , would the new-endpoint be readily adopted by the windows service ( obviously as long as the contract remains same ) or even if it changes.?
I am not able to phrase the question well, maybe that's why even enough of googling didn't bring me any answers.
Please guide me understand this.
The .xsd files need to be copied if your service/dlls make use of them at runtime. I would assume this is the case since it's not likely (although it is certainly possible) that the .xsd files are only used in the development environment. If you have any questions about this, you can always try to install the service on another system and see if it runs successfully without them. Trial-and-error is not the most efficient way to test software, but it works 100% of the time.
As for modifying the endpoint in the app.config post-deployment, the WCF service hosted by your Windows service will happily adopt this providing that you restart the service. This is one of the most appealing features of WCF, namely that how you connect (TCP, HTTP, P2P, etc.) and where you connect (endpoint) can be specified without having to change the code. If the contract changes, things get more sticky. Additions to the contract, e.g., new methods, would presumably be non-breaking changes, but modifications to existing methods would require the code to be rebuilt and redeployed.
HTH
Related
I am new to Service Fabric and don't fully understand the concepts but I am looking at a way to change the configuration at runtime like is possible in Cloud Services and App Services without performing an upgrade (and having to up-version the config file to do so).
For example, imagine that one setting is "Email destination", which might be changed several times a month and should be picked up automatically by the service.
It seems that ConfigurationPackageModifiedEvent is only fired for upgrades and that there is no other way to update and trigger this.
Otherwise, is there another way to relatively simply update a value that the service is using?
The assumption that SF team went with us that any change should be a versions change. That includes configuration packages as well. You could deploy configuration package only to advice what you need w/o modifying the code or data packages.
Alternatively, using an external source of data could be an option. You could put it behind a dedicated service in SF to abstract the details.
I would like to expose a number of WCF web services in AppHarbor. However, it is unclear to me, how to actually start the services, once the code has landed at AppHarbor. My questions are very fundamental:
Given a bunch of compiled code, how does AppHarbor know which dll/exe to execute? And which method on which class?
Should I start the service hosts myself, or should I just provide an .svc file?
So, basically, I miss a clear picture of how AppHarpor figures out what code to execute, and in case of WCF web services, how these should be started.
Here you can find information:
https://appharbor.com/page/how-it-works
I have deployed multiple WCF services projects on appharbor. First you have to know that when you push your code to AppHarbor it will look for only one .sln file. If there are more it'll throw an error.
Once you have deployed yor sevice it will look something like this:
Now, AppHarbor will make a list of every available commit you have pushed into the server so it will let you choose whiche one of them will be the one activated.
Since Appharbor compiles and builds the entire solution, you would have to push the entire project folder and not only the .svc file.
How would it know how to start it? That depends on the .sln file since it compiles the project it would be the same as when you debug it on your local browser. You don't have to start anything, once you have choosen a build to deploy, appharbor will do all the hardwork.
I hardly recommend it for .NET solutions ;)
Hope it helps.
More links:
http://support.appharbor.com/kb/getting-started/deploying-your-first-application-using-git
I am relatively green with C# and WCF. I have landed on a project where I am creating self hosted WCF services running as Windows services but am starting to wonder if I should use IIS instead (which we don't currently use) as managing all of these services could eventually get cumbersome.
Despite my best efforts, I have yet to find any definitive information about why I might favor one approach over the other. The services are primarily used for utility stuff like resizing images, retrieving files, etc. and are called by both C# and Java clients.
Thanks
The shortest answer would be 'it depends'. On your requirements. You can self host without problems, but IIS will manage resources more effectively and enable you to fine tune stuff more easily than self-hosted.
For instance, in IIS would be more simple to deploy a new version or remove and old one.
Either way is fine.
Generally, using the builtin IIS hosting capabilities can make deployment and configuration simpler for you. Also you have the activation model of http.sys - which means IIS will start the necessary process for you when an appropriate message arrives.
Clients of any platform can connect to the WCF services regardless whether they are self-hosted or IIS hosted.
ps: how to allow IIS-hosted WCF services to store their configuration data in distinct xxx.config files
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
My application is currently made up of 2 different solutions.
1) The Shell which contains all the WPF and front end logic
2) The BackEnd which contains all the WCF service implementations and NHibernate related data access. At the moment, there are 6 different WCF service contracts defined.
I currently have this working quite well in Visual Studio but need to consider the deployment options for when the application is installed on to a users PC. As far as I am aware there are numerous different ways of hosting WCF services -- in-process, as a Windows Service, in IIS. I am intrigued to know how people go about configuring this type of setup in a Prism application.
The nearest info I have found so far is from http://wcfguidanceforwpf.codeplex.com/releases/view/27987 but I don't think it is quite what I am looking for.
I would like to know :-
a) How and if you can allow the users the choice of different hosting strategies for WCF services?
b) All the examples I have seen show the ServiceHost opening and starting one service. Is this the recommended practice and I would have to create 6 Service hosts or could I start six WCF services in one ServiceHost?
c) If the WCF services are run in process for testing locally for example - do you use the bootstrapper in the Shell and open all 6 WCF services or is there some other place that this happens?
d) What strategies you use for configuring the endpoints or is it simply a case of modifying the app.config files?
e) If there are any decent references online or book that I have not managed to find that cover Prism desktop / WCF configuration?
Apologies for the amount of questions but usually I can piece together an idea of what I need to do from extensive Googling but on this occasion I cannot find anything other than the link above that seems to match what I need to know.
Any help with this on any question would be most appreciated.
Alex
Let me begin by saying that Prism and WCF are mutually exclusive frameworks, and the use of one does not preclude the use of the other in any way.
a) Why would you let them decide how to host their WCF service? The easiest configuration is IIS hosting, which requires minimal setup. One IIS web could host all of your six services, unless you needed a memory barrier by putting each one in a separate application pool. Running the services in a Service Host is tantamount to writing an EXE (e.g. Windows Service) to serve the client. A lot more work and configuration (from the Windows Service side, WCF configuration is the same, unless it conflicts with IIS by running on HTTP:80). You have many options for the how, but you're using WCF, so I assume you have a client/server scenario. If you have a Windows server, use IIS, imho.
b) You can run as many WCF services inside the same Service Host as you want, but if one fails, the whole EXE crashes. That is why I suggest IIS application pools, which auto-restart on failure, and can be configured to run each service in a different application pool.
c) There are different strategies for where to put service integration code, depending on how your application is structured. I would suggest writing a "Service" class for each of your WCF services and register each with your container, so you can use an ImportingConstructor on your view models that need any particular one. You would initialize and register these classes in the bootloader. At this point you may be asking yourself if you really needed 6 and maybe should consider consolidating into 1 WCF service.
d) I disagree with Sebastian here. WCF configuration is simple if your service is simple. The more complicated you need it to be, the more complex the configuration. By default, you need very little configuration, and I would look at the WCF Service Configuration Editor tool included with Visual Studio to modify both your app.config and web.config, but don't get confused which one you are working on! The simplest way to configure the client is to use the "Add Web Reference" and point to the URL on the server machine. Remember that WCF allows you to configure multiple end points for the same service (an end point is a URL with a port and service name), and each endpoint can have one of many different protocols (I use basicHttpBinding, wsHttpBinding, or netTcpBinding, depending on my needs). I suggest starting with wsHttpBinding, which is one of the easiest to debug. Modifying the app.config or web.config by hand is going to get you in trouble, because one mistype and you're debugging for hours. Stick to the editor.
e) You will not find a good reference on both Prism and WCF, because one does not affect the implementation of the other. By encapsulating your WCF service code inside of a service class served up in Prism by the container, you remove any dependencies between Prism itself and the services, and don't cause yourself headaches later on by inadvertently coupling them together. Later, you can inject your view models with a Moq service class that doesn't make calls to the actual service for testing purposes. Prism has a very good CHM file that has all you need to know about Prism, WCF has great documentation on Microsoft's web site (no book required, unless you want to get fancy, like with that Windows Service).
Feel free to follow up.
Follow up #1:
As I use IIS to host my services, I haven't the experience to guide you on implementing a ServiceHost for multiple services. However, IIS allows putting multiple services into the same application pool (which is basically a single instance of W3WP.exe running on your machine), so I am pretty sure it can be done.
Edit: After reading the WCF Guidance for WPF you provided, I can see that you create one ServiceHost instance inside your EXE for each service you want to host. So you'll need 6 ServiceHost instances, and manage them separately in the EXE code.
Factoring your services is a matter of design. You chose to have one service per domain class. If I did that in my application, there'd be over 100 services. Instead, I chose a to implement a command pattern which allow me to make requests for the objects I want, regardless of type, and it returns them to me in one, clean interface.
I am confident you will not find guidance on accomplishing your design between Prism and WCF in any book. You may find some in blogs, however, here is what I suggest:
Encapsulate your WCF service creation and operations inside of a class (e.g. DataAccessService) that can be injected into your view models through dependency injection (see ImportingConstructor attribute). Use the eventaggregator service to publish events from your DataAccessService if errors (or other notifiable events) occur, and handle them in your view model. Don't create cohesion between your view models or views and the WCF services by calling between them directly, as that will violate both SRP as well as prevent the ability to test the view models without touching your web services (an external dependency).
a) For the "if": sure, why not? For the "how": Write different modules that deploy your services to IIS or Windows Services or Console Hosts and let the user choose which one to run.
b) One Service per host but multiple endpoints with different bindings are possible.
c) In process means that they start when you start your application? Then I would go for the bootstrapper.
d) There is nothing simple about configuring WCF via app.config. The tooling in Visual Studio is puny and the number of knobs and dials is legion. Using code for configuration at least gives you Intellisense support.
e) I don't think that this is a very common combination so I would not bet that there is any literature out there. But for any questions regarding WCF I would recommend reading Programming WCF Services by Juval Lowy. I think the code samples also contain a WinFormsHost for WCF service which might be another option for your "where do I host services" problem.
What are some best practices for being able to deploy a Windows service that will have to be updated?
I have a Windows service that I will be deploying but might require some debugging and new versions during the beta process. What is the best way to handle that? Ideally, I'd like to find a ClickOnce-style deployment solution for Windows services but my understanding is that this does not exist. What is the closest I can get to ClickOnce for a Windows service?
A simple solution that I use is to merely stop the service and x-copy the files from my bin folder into the service folder.
A batch file to stop the service then copy the files should be easy to throw together.
Net stop myService
xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre
net start myService
I have a system we use at work here that seems to function pretty well with services. Our deployed system has around 20-30 services at any given time. At work we use a product called TopShelf you can find it here http://topshelf-project.com/
Basically TopShelf handles a lot of the service related stuff. Installing, Uninstalling etc all from the cmd line of the service. One of the very useful features is the ability to run as console for debugging. You build one service, and with a different cmd line start you can run it as a console to see the output of the service. We added one custom feature to this software that lets us configure profiles in advance. Basically our profiles configure a few things like logging, resource locations etc so that we can control all that without having to republish any code. All we do is run a command like
D:\Services\ServiceName.exe Core.Profiles.Debug or
D:\Services\ServiceName.exe Core.Profiles.Production
to get different logging configurations.
Our build script creates install.cmd and uninstall.cmd scripts for each of our services all we do is copy the files to the server and run the script. If we want to see debug output we stop the service and double click the exe and we get a console to read all the output.
One more thing that topshelf has which we don't use because its not necessary is the concept of shelving (there is documentation on this website for this). This allows you to update the service without having to "restart" but you still need to copy the files manually unless you build an automated system for that.
However, my suggestion if you need 100% service availability is to have a redundant system. No matter how you configure your service for updates you cannot avoid hardware failure causing downtime without an automated failover system. If said system was in place my recommended update strategy would be to turn off 1 node, update, test, turn on turn off the other node, update, test and turn the 2nd node back on. You can do this all of course with a simple script. This may be a more complicated system than you need but if you can't take a service offline for a simple restart that takes 5 seconds then you really need some system in place to deal with hardware issues because I can guarantee it will happen eventually.
Since a service is long-running anyway, using ClickOnce style deployment might not be viable - because ClickOnce only updates when you launch the app. A service will typically only be launched when the machine is rebooted.
If you need automatic update of a service then your best bet might be to hand-code something into the service, but I'd forsee problems with almost any solution: most install processes will require some level of user interaction (if only to get around UAC), so I can't imagine this would lead an answer that doesn't involve getting a logged-on user in front of the screen at some point.
One idea that might just work is active-directory deployment (or some similar equivalent). If your service is deployed via a standard MSI-type installer, AD allows you to update the application silently as part of the computer policy. I suspect you'd have to force the server to refresh the AD policy (by rebooting or using gpupdate from the console), but other than that it should be a hands-off deployment.
I would suggest using the "plugin" approach on this, that is, using the Proxy Design Pattern.
While using this pattern, an independant thread may verify over a folder for updates. You will need to use ShadowCopy over your assembly deployment. When your service update-thread encounters a new version of your service, it shall unload the current production assembly and load the new version, without stopping the service itself. Even more! Your service should never notice the difference, if there is no breaking code within your assembly.
I would suggest to create a normal setup project, and add the windows service project output in that setup project.
For more information please refer to http://support.microsoft.com/kb/816169.