Over the last few months I’ve been investigating source control solutions to replace our aging solution. After going through a few options we finally settled on TFS 2013. After much research I was able to figure out all the necessary requirements, the best options for getting it set up and running except for one crucial question. I couldn’t find a straight answer that explained how the application talked to remote database server with regards to user accounts. My guess was the TFSService account was in charge of this but I couldn’t get a definitive answer. I was really hoping it wasn’t going to use integrated authentication all the way to the database since that would be a non-starter.
With fingers crossed, I managed to get all the necessary approvals, got a new VM stood up and even got the database team to agree to create a service account that would let TFS manage its database requirements directly (rather than trying to pre-create the tables.)
When the day finally came, we ran into a slight snag. I was attempting to the do the TFS configuration from my account while the database guy watched, ever-ready to type in the service credentials. Unfortunately the database wasn’t being found no matter how correctly those credentials were typed. On a complete guess, we decided to try again while the DB guy was logged in. Sure enough this worked.
Once the configuration was complete, I was able to hit the TFS front-end and the connections to the database from that point on happened through the TFSService account. Neat. The downside is I can’t run the configuration tool to add new collections or change features since my account doesn’t have database rights. The TFSService account only applies to calls through the front-ends.
So, if you decide to install TFS 2013 on premises and to use a remote database managed by another team with very strict permissions, you’re going to need to run the configuration under an account with permissions to the database server. The web front-ends will communicate using the account configured as the TFSService account after that.
There. Weeks of trying to find a definitive answer and I finally just had to try it and hope for the best. Hopefully this saves someone else some time!
Happy controlling of the source,
Posted in TFS
Tagged Configuration, tfs
Constants and Settings are a pretty old topic, right? If you have a simple value you know at compile time which might make code more readable or might change very rarely and you don’t want to hunt through code to change it in multiple places, you use a const.
A const is beautiful. It’s static which means you don’t need an instance of an object to access the value. It’s set during compilation and immutable during the execution of a program which gives you some peace of mind the value isn’t going to get accidentally changed by someone else’s code.
Unfortunately a const can’t handle a value which isn’t known until a program starts up and can access a configuration file. In the face of this limitation I’ve seen the same (anti?) pattern repeated: the configuration value is read in with code in the constructor of a class which needs the value. Unfortunately this means the configuration value is read in every time you create a new instance. This is less than ideal given the value isn’t likely to change very often. Think about it – when you modify a web.config – are the values immediately available? Yes. Why? Because the application pool recycles! All your objects were dumped from memory and everything is loaded fresh and when the configuration code executes again, the new value is picked up.
So if the value is unlikely to change, why read it over and over again? Some people don’t – I’ve seen people use static members and only perform the costly configuration reading if the value hasn’t already been stored. This is pretty close to being optimal but it leaves a bit of clunky code lingering in your constructor and there can be a bit double-work done when an object is created multiple times in quick succession or on different threads at the same time. This is why I use static constructors paired with static readonly members to hold my configuration file specified settings.
What makes this a winning pair? A static readonly member is synonymous to a const except its value isn’t required to be set at compile time. Instead you must set the value by the end of your class constructor. A static constructor is called before you make use of an object for the first time.
Haven’t used a static constructor before? Probably not but you can probably guess it’s a constructor that’s called once – before the normal instance constructor is called. If you put your config file reading logic in this static constructor to set the static readonly configuration values, you’ll have near-const behavior with the added bonus of not cluttering up your instance constructor! More importantly, it is very similar to the code I’ve seen people write already but reduces the cost of re-reading configuration values with each new instance down to a single hit.
Keep in mind the rules go out the window if you mark your static members with the ThreadStatic attribute. Luckily this attribute should be used incredibly rarely and by people who know precisely why no option is optimal for them.
Static constructors are nice, so I’ll say it twice. Static constructors are nice, static constructors are nice.
Static constructors are nice,