A place for spare thoughts

21/02/2012

MSTest 2010 without Visual Studio at build server – again

Filed under: MSBuild, Unit testing — Ivan Danilov @ 02:53

A while back I wrote on that topic. Today I found that that solution was not working when MSTest private accessors were used in the solution.

In general I think that these ability to access private members of the class encourages bad design and nullifies one of the most useful features of testing: necessity to think about how your class can be used and how convenient its interface is. If you have ability to work with privates – you don’t have to think. You could just write code as it goes. How are consumers of the class supposed to use it when even its author can’t?!
Thus, IMO, ability to generate private accessor to a class is one of the most abominable things in testing and I’ll never ever use it.

But unfortunately others do sometimes. If you have such a project and try to build it on a machine that was setup using my previous advice – you’ll see something about compiler can’t find out meaning of name YourClass_Accessor. Of course it can’t – it wasn’t generated yet! To overcome this issue you have to copy in addition to previous files also this folder:

c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\

It contains *.targets file that was foresightfully imported even in default Microsoft.Common.Targets (even if you will never have MSTest – you still have line to import it if it is found), one assembly with custom MSBuild Task implementation and some exe-module. For some reason, MSTest developers can’t manage to write a product without such hacks at every corner. Whatever.

So, you just copied these files and msbuild will find them. Do not even hope to have such a luxury for your products 🙂
But when I rerun the build – I found such error:

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets(14,5): error : Could not load file or assembly ‘file:///C:\work\TestSolution\TestProject\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll’ or one of its dependencies. The system cannot find the file specified.

What?! Why the hell MSTest tries to load an assembly from current directory and not with normal binding mechanism? I have this assembly on my build machine and it actually can be loaded when referenced from project in normal way. I didn’t found answer to that question as well as option to alter this probe somehow. But with fusionlog I found that just after probe to current dir it tries to load same assembly from its default location at c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Ok. Let’s stick to it. And I’ve copied all of my assemblies not to c:\vs2010stub as I suggested in previous article, but to default c:\Program Files (x86)\Microsoft Visual Studio 10.0\ folder. And it worked – private accessors got generated and publicized correctly.

So I made related changes to my archive and re-uploaded it to old location. Just unpack somewhere on build server and run install.bat. Should work afterwards.

Advertisements

4 Comments »

  1. […] If you’re using MSTest private accessors – you’ll also need this as I discovered much later. Zip-archive linked below is already […]

    Pingback by MSTest 2010 on the build server without VS2010 installed « A place for spare thoughts — 21/02/2012 @ 02:57

  2. Hi there,

    Thanks for your post! I’ve done exactly the steps as you had outlined in your previous article but with the destination folder location of the assemblies on c:\Program Files (x86)\Microsoft Visual Studio 10.0\ folder plus the additionational steps you had outlined in this article. I’m doing this for my Test Build machine coming from my Dev machine. Both Dev and Test Build machine had Win 2008 64-bit. Apparently, when I tried to run MSTEST, it gave me the following response:
    “Visual Studio Ultimate is required to execute the test ”WebServiceCheckCoded’ {16ad43d4-ddf3-dd3f-6291-0712f23987828ed}’.

    Results
    —————-
    Not Runnable
    ….
    ….
    ……… Not Runnable”

    By the way, I’m using VS2010 Ultimate on my Dev machine and creating automated web service testing tool. This works perfectly on my Dev machine, however, I’m finding it hard to run with MSTEST on my Test Build machine.

    Any thoughts on this?

    Thanks,
    Andy

    Comment by Andy — 22/02/2012 @ 06:47

  3. Hi. It seems that Web tests are not supposed to run without not only VS installed, but even without concrete version, namely Ultimate. It could be that there’re some licensing problems exist.

    http://superuser.com/questions/118915/what-version-of-visual-studio-2010-is-required-to-run-web-tests
    http://stackoverflow.com/questions/3500766/running-visual-studio-2010-ui-tests-not-on-ultimate

    We don’t have such tests (luckily), so I can’t say is this problem could be solved at all, but as a way to investigate – try to inspect test failing more closely. Actually it is how I came to the result myself.
    Your first friend is Fusion log viewer – if there’re some failing binds just before exit – it could be that mstest just can’t find some additional assemblies.
    If that doesn’t help – try to analyze failing run with procmon from sysinternals suite. Look at not-succeeding operations could reveal cause.

    And if mstest is just checking license – probably you don’t have another option then to install VS 😦
    Or to go from MSTest to something more acceptable.

    Comment by sparethought — 22/02/2012 @ 06:57

  4. […] MSTest 2010 on the build server without VS2010 installed – again […]

    Pingback by How I failed using MSTest on TeamCity without Visual Studio ← 5th day — 06/03/2013 @ 18:23


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: