Damian Hickey

Mostly software and .NET related. Mostly.

SolutionCop

We've built this internal tool that, in a similar style to StyleCop and FxCop, validates your solutions and it's project's settings. Here is a screen shot from one of our smaller projects:

View the full output: SolutionCopReport.htm (22.00 kb)

I'll consider open-sourcing it if people are interested in such a tool? Leave comment or ping me on twitter.

I am currently considering an 'EnvironmentCop' - a tool to check your environment's suitability for building and running tests.

Using OpenWrap without having to install it

Well shortly after my last post on getting OpenWrap to work with TeamCity I was told that one can just include o.exe with your solution and use the switch

 

o -shellInstall none [rest of args]

 

instead.

This made me face-palm :)

In my defence, this switch is not shown via 'o', or 'o get-help'. Nor is it easily discoverable via the documentation / wiki when following links from openwrap.org. I also thought that because the default action of 'o' is to prompt you to install, I thought one had to.

And with that, I am of the opinion that 'o''s default action shouldn't prompt to install, and that installing should instead be an explicit switch ( '-install' ).

Getting TeamCity Build Agents and OpenWrap to work together

Just had some fun trying to get OpenWrap (1.0.0.53270093) working on TeamCity (6.0), and to be honest, I'm not entirely sure that I am doing it right. My build tool of choice is psake, and I am calling OpenWrap from within one of my build tasks.

Anyway, this is what I had to do and feedback is, of course, appreciated :)

1. Login to your build server with the same credentials your agents run under.

OpenWrap likes to install itself into the user specific application data folder, c:\Users\[User]\AppData\Local\openwrap, so you will need to login to your build server with the same credentials the TeamCity build agents run under. So they could access network resources, my agents run with domain credentials so this wasn't a problem.

2. Install OpenWrap with the 'i' option, "install the shell and make it available on the path?".

This will install OpenWrap in the folder mentioned above. The 'c' option, "use the current executable location and make it available on the path?" threw a DirectoryNotFoundException for me. Choosing 'n', "do nothing?" means that o.exe will continue to prompt you the installation questions.

This is where the fun begins. OpenWrap will add an entry to the user's (as opposed to the system's), PATH environment variable, creating the PATH variable if it didn't already exist. In my case, it didn't. Nothing wrong with this but there seems to a bug with TeamCity whereby, if the user's PATH environment variable is specified, the agent will use that and ignore the system one altogther. The expected behaviour would be to concatenate both.

So when restarting the agent, it's PATH enviroment variable went from this:

to this:

...and that broke a whole bunch of things!

3. Delete the User PATH environment variable.

Control Panel -> System -> Advanced Tab -> Environment Variables -> User variables for [username].

4. Modify buildAgent.properties

Open buildAgent.properties (typically located in C:\TeamCity\buildAgent\conf) in notepad and add the following line:

env.PATH=%env.PATH%;C\:\\Users\\[username]\\AppData\\Local\\openwrap

This is a workaround that adds the OpenWrap path to the system's PATH variable just for the use of the agent.

5. Restart Agent service

The agent's PATH variable should now be fixed:

And your build scripts should be able to call 'o' without problem.

 

Even though the bug is entirely lies with TeamCity, I do think OpenWrap could provide an better mechanism for such deployment scenarios. My system admin would prefer actually prefer MSI.. I don't know enough about OpenWrap's architecture perhaps an install for 'all users' would help?

If you spot anything wrong, or there is a better way, do let me know.