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
Related
I am trying to run a background service which just writes to a file on a specified interval.
There are two methods that I tried
1) Created the project with the Console application template
2) Created the project with Web Application as template
When I run the app from visual Studio, both of them run fine. But when I deploy them to IIS, only the web application version works. It must be noted that there is absolutely no difference between the code of the two projects. I have used the WebHost as a hosting strategy in both the projects as well as well as installed all the dependencies in case of Console application as there are in the Web Application version.
I must also inform that I have used the preloadEnabled="true" option in IIS as IIS needs a web request to start the application.
I am wondering what is the difference between both the project types as the code is the same? I don't want the Web Application template.
Edit 1: I forgot to mention that the service will also need to expose an api endpoint for healthcheck purposes. Will the windows service approach listen for http requests?
I used the following article for implementing my background service.
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice
After years of building background services, I learned that Windows services are the best tools to implement these applications. While there are different techniques to keep an IIS application up and running in the background and prevent it from getting recycled, in practice, the applications on IIS are not meant to be executed forever.
If you had an intention to build your app in the cloud, I would have suggested using something like Azure WebJobs or Azure Functions Timer-Triggered functions, but for on-premise, even using something like Hangfire in the web is not sustainable. The worst happens when you need backward compatibility on Windows servers that don't have the "Application Initialization" module.
My suggestion is to move your application to a simple Windows Service if you control your environment. Windows services consume less memory, are easier to manage, and can run forever without getting recycled.
WebApplications are plain the wrong tools for this.
Being always on and always reachable, WebServers are primary targets for hacking. To compensate for that, they are usually run under the most restrictive user rights you can imagine: Read rights to their programm and this instances content directory. While I do not know why it worked at all, it propably will stop working in Production.
What you wanted to write was eitehr a Service or something executed by the Windows Task Sheduler. Personally I advise for the Task Sheduler as Services have their own set of restrictions. Unless of coruse there is some detail of the requirements that you did not told us.
This article could be helpful. It's a step by step tutorial on how to convert a console application to a web application.
I've recently inherited a number of WCF webservices that are configured to use an ASHX handler within a web project to render the .SVC files in the form of http://example.com/Services/V1/MyService.svc. The services are running in the dev and production environments, WSDL comes up, and adding a service reference in a new project allows me to call MyMethod and get a response exactly as expected.
The error handling and logging story isn't great, so I'm trying to run the site locally and add a service reference to http://localhost:1234/Services/V1/MyService.svc. I can load the service at that URL and see the same WSDL that appears for the production environment, but when I try to use code similar to what's below to call my method neither the client nor the response objects are recognized the way they are when I connect to production.
using MyServiceTestProject.LOCAL_MyService;
//...
MyServiceClient test = new MyServiceClient();
MyServiceMethodResponse r = test.MyServiceMethod("arguments!");
I am able to see exactly one of the MyCustomObject classes that is only declared within my service and stops being available when I stop using the service reference, so I know that something is coming across even if it's not everything that one would expect.
The relevant parts of the Web.Config files are the same when I compare my local and dev/prod environments, and the project that's running locally is the one that was deployed to those other boxes.
Has anyone encountered this sort of behavior runnning a services project locally using IIS Express?
Edit:. The endpoints are different between the prod, dev, and local environments, using the same code in each one. Thanks for pointing out that detail I'd omitted originally.
After spending several hours on and off trying to solve this before posting the question, deleting and re-adding the service reference and restarting both my IDE and my computer to no avail, I've discovered that right-clicking on the name of the service and selecting "Update Service Reference" (circled in red in the screenshot below) would ultimately fix the problems I was seeing although VS sometimes required me to perform multiple updates before it would work.
Without performing the update, neither my attempts to delete and add the service back nor restarting Visual Studio/rebooting my PC would help address the issue. I'm not sure if it's something about IIS Express that causes the service reference to not be created with all of the necessary data the first time around or if it's one of a hundred other variables in my local environment, but at least there's a reliable way to get it working when it does fail.
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
I have created a C# web service, a web client, and successfully debugged the service with ASP.NET Development Server (that thingy that gets activated when you just press F5). All fine. Now I need a web service that is almost the same as previous, but differs in a few lines of code. For this purpose I created two new configurations, DebugNew and ReleaseNew, and set the output directory to binNew (instead of default "bin"). The problem is that original web service is executed in debugger, instead of new web service. The debugger is unaware of binNew folder. How to set up the environment to start new web service if DebugNew configuration is active?
As far as I know, web applications will only run out of the bin folder. If somebody knows how
to change that, I would be happy to call myself wrong in order to learn that trick myself.
Assuming that I am actually correct for once there, you could write a post compile script that checks which build configuration is active. If it's either DebugNew or ReleaseNew, copy the contents from binNew to bin.
If there's really only a few lines of code different though, I question whether or not putting a configuration setting in and adjusting the code accordingly isn't a better way to go. But, I certainly don't know all the facts. Just a thought I had.
I established a truce with Visual Studio (or unconditionally surrendered, depending on the point of view), and reverted output directory back to \bin. At least the setup project, which is in the same solution, maintains separate folders for each configuration.
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.