Even with the advent of ORMs, under the hood ADO.NET is still the core infrastructure used to access databases. There are many cases where using ADO.NET is still the easiest solution and oftentimes you find that you have to mix in some ADO.NET with your ORM calls. This is a testament to the solid design of ADO.NET. The biggest issue with ADO.NET is that it requires quite a bit of boilerplate code to retrieve data from the database. In this series of articles I’m going to demonstrate how I do data access when working with ADO.NET. The end result will be simple code to access any database in a (relatively) generic manner without the need for boilerplate code. Here’s a rough outline of where I’m going.
UPDATE: And then I saw this. Oh well, there went my idea.
Have you heard about Goat Simulator? How about Rock Simulator?With the advent of indie game devs we’re getting lots of great games but occasionally a few questionable ones show up. When I first heard about Goat Simulator I thought it was a joke. Later I found it available on Steam. A coworker bought it and said it was hilarious but it got repetitive after the first hour. That got me to thinking, maybe I can create my own simulation? So here you go: Cat Simulator.
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.