]> Posts for November 2018 🌐:aligrant.com

TFS Error CS1679: Invalid extern alias for '/reference'

Alastair Grant | Monday 5 November 2018

As you can probably see by my recent posts, I've been ankle deep in TFS build agents recently.  My latest head scratching moment was configuring automated builds for a sprawl of code.  I was hoping that this project would be in a buildable state when I looked at it, and was disheartened to find this error spewed everywhere:

CSC : error CS1679: Invalid extern alias for '/reference'; 'C:\vstsagent\A2\' is not a valid identifier [C:\vstsagent\A2\=_work\1\s\blah\blah.csproj]

extern alias is used to reference two different versions of the same assembly in a project.  This raised my eyebrows as I couldn't imagine this project needing anything so complex.  Rummaging through the code I couldn't find any uses of the extern alias keywords.  Which left me puzzled and resorting to searching the net for clues.

Not a lot came up, certainly nothing recent - which meant I'm on my own.  The project built fine locally (well, it did with some fixing), but the error persisted through msbuild on TFS.  Narrowing down my searches, one loan result jumped out at me for some reason: Equals signs in solution path causes CS1679.  Who in their right mind would put an equals sign in a file path?

The answer was staring me in the face and the answer to the question is me, I'm the person who put an equals sign in a file path: but not in the project, in the build agent.

it looks like when I configured the build agent (tinkering by hand with the command line arguments), it appears I had somehow entered in --work=_work instead of --work '_work' (guess somebody is used to *nix where convention says -- has an equals between the argument and its value, and a single - uses an abbreviated argument name and a space separator for the value).

The fix is straight forward.  You don't have to reconfigure your agent from scratch, you can stop the process and edit the .agent JSON file in the agent's root directory (might be hidden), and alter the "workFolder" value to be the correct one.  Start up the agent again and life is back to normal.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

TFS side-by-side build and deployment agent

Alastair Grant | Thursday 1 November 2018

We have a general purpose web-dev VM for running test web-sites.  It has a build agent on it already for building web-sites, this works fine.  But the newer release scripts utilise Deployment Groups, which use agents.

Great, so I tried to deploy a release agent on the same server.  Buzzt.  This can't be done due to an agent already being registered:

Cannot configure the agent because it is already configured. To reconfigure the agent, run 'config.cmd remove' or './config.sh remove' first.

There is an obscure bug report mentioning that an agent can only be used for build or release, not both.  It alludes to the idea of installing multiple agents - confirmed by Microsoft Azure Pipeline Agent documentation.

I wondered if I had a failed install and removed the deployment agent, but it removed the build agent - but it did let me install a deployment agent then.  I think the problem stemmed from the build agent, which is installed slightly differently and potentially from a previous version of the agent.

To resolve the issue, I removed all the agents and deleted their directories from the server and started afresh.  I used the TFS deployment script for both the deployment agent and the build agent.  But made some changes.  For both agents, update the --agent parameter to have a more descriptive name than just the computer name (e.g. include the function it is performing).

For the build agent, the default deployment arguments need to be removed (--deploymentpool --deploymentpoolname XXXX), this will then install the agent as a build agent and not a deployment agent.

Hey presto, you should have two agents installed as a service, one doing build and one doing release.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

Entries for: November 2018

Previous Next