Dealing with too many environments
Getting straight to the point, remote chances are that you may be using way too much environments on a single release. Normally, this would never happen, as the usual route is to have dev, qa, staging, and production environments at most. And because of that, they never thought this could possibly become an issue.
When you edit a release, a web api call is made to check the current user’s permission to access each one of them. If this method happens to fail, you won’t be able to access the context menu options for each environment (such as variables or deployment conditions). Click here to read more.
All the groups
Sometimes it’s difficult to know who is in which TFS group. The groups keep getting bigger, some people change from one department to another, a group gets created for a particular set of special permissions, and so on, and so forth. Be it for auditing or just to keep things tidy and organized, knowing who is in which group can be a tiresome task by navigating group by group.
For all that matters, let’s say [Tfs_Configuration] is our TFS 2015 configuration database. With this, you can get group membership recursively until you figure out who is in which group. Please note that this may not be the best/fastest way to do it, as I didn’t worry too much about optimization. Click here to read more.
This post is not programming-related. It’s also purely anedoctal and based solely on my own experiences.
I’ve recently watched all the unfold fiasco regarding Mighty No. 9. For those who don’t know, it’s a game that was promised to be almost like a “spiritual successor” of megaman, but apparently failed in a outrageous way. When this kind of thing happens, as always, we see some people take an initial stand, and everyone else following the bandwagon. Some judge, others defend. “It’s not that bad”, “It’s atrocious”, and everything in-between. One post that got my attention was: “If it was me doing a game like this, I would be so proud. I don’t understand why people are bashing it so much”. Click here to read more.
Can’t touch this
This is basically an issue which is likely to happen (AFAIK) if you’re currently using Server Workspaces in TFS. Due to the size of the solutions and projects I’m working in, changing to a local workspace feels a lot slower. Now, I’ve recently switched some of my projects to .NET Core, and building one of them has yielded the offending error:
Failed to make the following project runnable: aaa.bbb.ccc (.NETFramework,Version=v4.5) reason: Access to the path ‘g:\xxx\yyy\zzz\bin\Release\net45\uvw.dll’ is denied.
This is caused by the fact that those files are marked as “read-only”, which is the default for files in source control that are not checked out. Click here to read more.
But I do have permissions!
I’ve come across a pestering access issue on TFS2013 (On-Premises), where I couldn’t delete some branches because I had no access to path/*. After reviewing my permissions a thousand times on the accusing path, I almost gave up and used tf destroy to incinerate them. (PROTIP: don’t do that unless you ABSOLUTELY have to). Most of the times, this problem is caused by a permission set in some subfolder or file inside of the folder you’re willing to delete. The thing is: VS doesn’t tell you exactly what files have the treacherous permission set that drives you to insanity. Click here to read more.
I am getting ready to participate in the next Ludum Dare (LD35), and being my first time, I wanted to do it on Twitch as well. So I started setting things up, such as adjusting my screen and webcam layout and getting some music. I’ve found that there was no easy way to show my current playing track on spotify. Not the way I wanted, anyway.
What have I tried?
First, I tried capturing the Spotify App windows partially, but it hides part of the song if it’s longer than the widget size. It was kinda ugly. Then, I tried using their api, but it seems there is not such method to get the current playing track. Without any further options, I noticed that the song/artist names showed up on the title of the window. So I’ve come up with a quick and dirty C# wpf app to capture the title and format it to my needs. Click here to read more.
This is related to the implementation of a custom plugin using ITeamFoundationRequestFilter.
You can go to the first part of my post series by clicking the link below:
This post is a fix to a possible problem while reading requests if you’re using Git.
The problem with InputStream
In my first posts about implementing ITeamFoundationRequestFilter, I’m using HttpContext.Current.Request.InputStream to read the contents of the request. It happens so that, depending on the implementation, this may break Git functionality. If you access the InputStream before trying to push content to git, the following error is shown: Click here to read more.