In my current .Net 4.0 solution, I have one project containing a lot of XML files as embedded resources. There is a lot of development activity going on with these files and there is a very real chance that one of the developers on my team will forget to set the build-action of a particular XML file to embedded resource.
What I have done to insure that this does not happen, and which works perfectly for local builds in VS2010, is to create an automated test in NUnit that counts the number of resources using Assembly.GetManifestResourceNames() and then compares this with a file count in the correct source directory sub-tree of my resource assembly. As long as these match it means that all the files have build-action correctly set to "embedded resource".
Now, my problem is that my test uses a relative path to find the directory of the files in the resource project and working directory is not the same on the build server (which uses TFS2010).
What is the best way to solve this? I have thought of using environment variables which can be set differently on developer machines and on the build server but ideally I would like something that would require the minimum amount of configuration on developer machines and build server.
Ok, this is the solution I ended up with:
The test checks for a specific environment variable using Environment.GetEnvironmentVariable and if not set uses a relative path that works on development machines using Visual Studio 2010, otherwise it uses the path in the environment variable
For the build server (Team Build) I set an argument for the build process to equal the environment variable and then in my NUnit task I set the NUnit Environment variables to the value of the the build argument.
This solution makes setting up new developer machines hassle-free but may require some configuration of build-agents if they deviate from default path setup.