In this series of articles I have been demonstrating a simple approach to making Windows services. In the previous article I discussed the different components generally involved in writing a service. I also provided the code for the service host and started working on the service instance. In this article I’m going to finish up the implementation of the service and demonstrate how all this comes together.
In the last article I provided an overview of Windows services and the issues involved in writing one compared to a normal program. In this article I will demonstrate how to write a simple service in a way that helps alleviate these issues. Before getting into the code for a service it is important to reiterate that a single process can host multiple services at the same time and each service can be started or stopped on its own. It is therefore useful to break up a service into its components so that each component does only what it is expected to do. When creating a service I find that there are 3 different components: service host, service instance(s), and service worker.
In Windows a service is a process whose lifetime is managed by the system rather than by a user. MSDN describes a service as a long running process and often times this is true. Services tend to start before a user logs in (or shortly thereafter) and run until the system shuts down. This is unlike traditional applications that start up after a user logs in and terminates when they log out. While a service looks a lot like a standard application they behave quite a bit differently. In this article I’ll discuss some of the issues around creating a service and ways to make it easier to write and debug one.
After a long delay I’m finally ready to finish up my series on creating a smarter WCF service client. Please refer to the previous articles for where we’re at.
- Identifying the issues with service references and the existing WCF client code
- Creating a smarter WCF service client
- Simplifying the calling of a WCF service
- Creating the skeleton client template
We’re now ready to generate the T4 template to back the client template.
UPDATE 1: Unfortuately not everything is going well with the reports. We were finally able to track down that the issue was with the user account I was using to configure TFS. Evidently you need to be an administrator on the machine hosting the SSRS instance (not just an admin for SSRS). Without admin privileges you cannot access the WMI provider remotely which causes the configuration to fail. Needless to say the network admins were not pleased. They tried to strip things down to the minimal privileges but nothing short of full admin worked.
UPDATE 2: We have run into another, more serious issue though, we can no longer create new team projects in any collection. I can create a new collection but creating any team project fails. It always fails when trying to create the SSRS reports and the error message is useless. The error message says it cannot connect to SSRS so the host name is bad, the connection timed out or the database is corrupt. Now I’m really annoyed. In a last ditch effort we are rebuilding the reporting databases. If this doesn’t work we may need to retreat back to the old server.
UPDATE 3: Someone from the TFS team responded that all you need to do to move the database is the following:
- Stop the collection
- Backup/restore the database
- Edit the collection settings to move the database
UPDATE 4: We finally resolve the team project creation issue. It turns out that moving the SSRS database and having TFS reconfigure to use it doesn’t restore all the permissions correctly. Thanks to this post I was able to run just the permission update scripts and we’re back in business.
I do see these options in TFS but I’m not sure whether that would include the configuration database (which got moved as well) or just the collection database. The next time I need to move the database I’ll have to try it and see.
Recently we needed to upgrade our TFS 2012 server to TFS 2013. The last time we upgraded TFS 2010 to TFS 2012 it was a nightmare so we took some more precautions this time. Alas they didn’t help. This upgrade proved to be just as big of a nightmare as the last time. Here’s my story of upgrading TFS based upon my 2 previous attempts.
In the last article we presented a solution for calling WCF services that needed only a single line of code and no
using statements. But it had many limitations including
- Reliance on a static class
- Testability was low for any code using it
- Reliance on the WCF client rather than the contract
- Not optimized for multiple calls
In reality the previous series of articles where all about setting up the infrastructure to support the final solution. All this infrastructure will be hidden from code when we are done. Let’s get started.
In the last article we replaced the standard WCF service client with an improved version. But beyond solving an issue with cleaning up the client we haven’t really improved the calling code any. In this article we are going to look at one approach for making the calling code cleaner. The less code that is needed to call something the cleaner it tends to make code. We will present one approach for making WCF calls one-liners. This is not always the best solution so we will talk about the disadvantages as well.
In the last article we made a case for why the standard WCF client generated by a service reference is not a great idea. Among the issues listed were testability and proper cleanup. To fix these issues we will need to ultimately replace service references altogether but this is time consuming for large code bases. When we started down this path at my company we did it using an iterative approach. While the intermediate stages may appear to be (and, in fact, may be) a step back we are ultimately working toward a solution that I believe is far better.
WCF is a great way to implement service-based APIs but the standard approach to consuming a service lacks a lot to be desired. In this series of articles I will discuss the approach that I’ve used in commercial applications to make consuming WCF services much cleaner and simpler. We will start with the standard approach and identify its flaws. From there we will work toward a solution that has minimal impact on consumers while providing maximal benefit. The solution itself is large but not overly complex. More importantly, once finished, you never need to worry about it again.
UPDATE: A bug was recently found when determining the difference between 2 dates across a year boundary. A corrected version has been uploaded to the site.
In .NET the DateTime type represents both a date and a time. .NET doesn’t really have a pure date type. Ironically it does have a pure time type in the form of TimeSpan. In general this isn’t an issue but when you really just need a date (i.e. the end of a grading period) then you have to be aware of the time. For example when comparing 2 date/time values the time is included in the comparison even if it does not matter. To eliminate time from the comparison you would need to set both to the same value (i.e. 00:00:00). Another example is conversion to a string. A date/time value will include the time so you have to use a format string to eliminate it. Yet another issue is that creating specific dates using
DateTime isn’t exactly readable (i.e. July 4th, 2000 is
new DateTime(2000, 4, 4)).