I have a web role (RP) running in Windows Azure that uses ACS 2.0 as the identity provider (IP). The web role is configured with a certificate to work with the authentication negotiation and subsequent security session. The certificate supports both domain.com and www.domain.com. The issue is that the federation authentication configuration of the web role can only specify one realm and the realm attribute is a required value.
I tried to install the New Relic Nuget package for an Azure solution. Unfortunately the Nuget install script failed to update the ServiceDefinition.csdef file and provided the following error.
Unable to find the ServiceDefinition.csdef file in your solution, please make sure your solution contains an Azure deployment project and try again.
One of the good things about Nuget is that the install scripts are easily available to the solution.
Sometimes things go wrong. For example, when files are not on your local disk when you expect them to be. I see this pop up every now and then when working in a team environment or even as a single develop across multiple machines. Usually it is because something has not be submitted into source control. Maybe the file was never bound to source control in the first place. I have seen Visual Studio simply miss files as well.
Normally this is not a problem. The compiler will complain if a C# class file is missing because it can’t do its job. Unfortunately a Web project does not throw a compiler error when a content file is missing. Thankfully there is an easy fix.
I’ve been having issues running deployment tasks in a TFS build today. The batch file I’m getting it to execute on a target machine just doesn’t seem to find the setup packages in the TFS drop location. I suspected that it was executing the deployment steps using a local account on the target machine. Adding an echo %username% in the script confirmed that this was the case. Even though the target machine is a domain joined machine, local accounts won’t help with getting access to the TFS drop location which is secured by an ACL.
The account used to execute a deployment step is the lab agent service account identity on the target machine.
By default this appears to be local system. You need to reconfigure the local Lab Agent service on the target machine in order to have it execute deployment steps under that account.
The deployment step now identifies that it is executing under the correct credential.
I still get a deployment step failure, but weirdly the deployment and the build were both successful.
I’m trying to get out for a ride a couple of times a week. Yesterdays ride was a bit of misadventure though. At the 3km mark, I got a puncture. Do I turn back and cut my losses or keep going up the mountain on the spare to have fun on the downhill track? Hey, I have a spare and a repair kit. Up the hill we go.
I then get a second puncture 100m from the top of the mountain.
We encountered a couple of issues yesterday when updating TFS 2012 from RTM to Update 1. The installation went well on the application tier and the data tier. The upgrade for the build service hit some problems.
The event log on the application tier contains the following error:
Operand type clash: dbo.typ_BuildControllerTableV2 is incompatible with dbo.typ_BuildControllerTable (type SqlException)
The only other issue we seem to have hit is that exposing TFS over HTTPS was broken after the install. Brian Harry indicated this would be the case but did not elaborate on the details. It seems like the installation package for Update 1 has reset the IIS configuration back to its default TFS install. The affect of this is that the https binding was removed from the site. Simply adding this back in has restored our external TFS connectivity.
I’ve been a little late to the NuGet bandwagon. Overall I am really happy with the service that NuGet provides. It is not all smooth sailing though and the following are the pain points I have hit:
- Packages aren’t all strong named so our solution can’t be either
- Package dependencies being updated might break other packages that depend on them
- The amount of binding redirects added to config files is not always desirable and don’t always work
- TFS get latest on a solution does not bring down NuGet package changes
My Using WinMerge with TFS post has to be consistently the most viewed post on this site. I have finally been able to get around to posting updated reg files to support VS2012 on both x86 and x64 platforms (see the bottom of that post for the links). These reg files will configure VS2012 to use Winmerge for TFS diff/merge operations (no Visual Studio restart is required).
I really like Microsoft’s Code Contracts. The concept is absolutely great, but I’m starting to wonder if using them is worth it. Here are the pro’s and con’s as I see them.
I’ve been taking the pain today with an issue that provided a lot of misdirection. The setup is a build agent that uses a remote PowerShell session to install a setup package from the build output. The setup package also includes the facility to remote deploy a database to a data tier machine.
It always worked from my local machine and manually from the deploy machine. I never worked from the build workflow.