Team Test

[trailway]

I am using Visual Build 7.2a in conjunction with Visual Studio 2010 RC. I created a trivial C# application with unit testing (which requires using the .NET 4.0 framework). I can run the unit tests in Visual Studio itself without problems.

I created a "Team Test" step and added a reference to the test DLL in the "Test containers" on the Test tab. When I try to execute the step I recieve the following error:

Could not load file or assembly 'file:///C:\...\TestProject2.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

[kinook]

When I tried that, I got:

4/19/2010 11:16:44 AM: Building project step 2 - Team Test...
Starting execution...

Results Top Level Tests
------- ---------------
Passed TestProject1.UnitTest1.TestMethod1
1/1 test(s) Passed

Summary
-------
Test Run Completed.
Passed 1
---------
Total 1
Results file: C:\Users\xyz\Documents\Visual Studio 2010\Projects\TestProject1\TestProject1\bin\Debug\ TestResults\user_computer 2010-04-19 11_16_45.trx
Test Settings: Default Test Settings
4/19/2010 11:16:46 AM: Build successfully completed (elapsed = 00:00:02).

http://www.kinook.com/Forum/showthre...?threadid=3044

[trailway]

Trivial example attached.

Can you let me know if this works for you?

[kinook]

4/19/2010 11:35:49 AM: Building project step 2 - Team Test...
Starting execution...

Results Top Level Tests
------- ---------------
Passed TestProject2.ProgramTest.MainTest
Passed TestProject2.ProgramTest.ProgramConstructorTest
2/2 test(s) Passed

Summary
-------
Test Run Completed.
Passed 2
---------
Total 2
Results file: D:\Files\Kinook\Support\VisBuildPro\Forum\TestResu lts\user_computer 2010-04-19 11_35_50.trx
Test Settings: Default Test Settings
4/19/2010 11:35:51 AM: Build successfully completed (elapsed = 00:00:01).


I tested with Visual Build 7.5a and Visual Studio 2010 Pro RTM on Windows 7 x64.

[trailway]

Thanks for the feedback. I spent all day trying to figure out why this does not work for me.

It appears to me that Visual Build is using the wrong version of MSTest. When I turn on command line logging what I see is that it runs MSTest out of "Microsoft Visual Studio 9.0". If I change the 9.0 to 10.0 and execute the revised command line locally, it works.

I do have Visual Studio 2008 and Visual Studio 2010 both loaded. How do I get Visual Build to use the 10.0 MSTest?

[trailway]

Well... I think that I have sorted myself out.

I found out that I had a VisBuildPro.macros in "C:\ProgramData\Kinook Software\Visual Build Professional 7" which appeared to point to older Visual Studio. I removed this directory and reinstalled Visual Build.

I think that this does bring up a good point though. Shouldn't there be a step for Team Test for VS 2008 and one for VS 2010? If not then how should I switch between them?

Is there another way that I can specify the tests using the VS solution which is version specific rather than simply pointing to the test DLL? Maybe this gives you the information you need in order to determine which version of MSTest to run?

BTW, I have Visual Studio Professional not one of the more advanced versions. Thanks for your help!

[kinook]

http://www.kinook.com/VisBuildPro/Ma...testopttab.htm

[trailway]

First, thank for your help and rapid responses. I appreciate it.

I did the following:
1) Deleted my custom VisBuildPro.macros. Actually I removed all the Kinook files under 'Program Data'
2) Removed Visual Build
3) Reinstalled Visual Build

If you click on "Visual Studio & .NET Macros" in Help under Actions/Microsoft the article states that DOTNET_DIR, DOTNETSDK_DIR, and DEVSTUDIO_NET_DIR should all point to the highest versions of the respective utilities. I find that to be true except for DOTNETSDK_DIR which points to v6.1 versus v7.0a which the latest on my system. Is this wrong? Should I patch this on my system?

The other thing I want to say that I think that there is a fundamental design problem with the Team Test step, i.e. it needs to be redesigned to be Visual Studio version (or framework) specific. The fundamental issue relates to moving to the 4.0 CLR framework. What happens when a customer has existing bld files which run against Visual Studio 2008 and then moves to Visual Studio 2010? In this case they must go back and manually edit the old Team Test build steps to use the old MSTest. Confusing? I think so.

[kinook]

Originally posted by trailway
First, thank for your help and rapid responses. I appreciate it.

I did the following:
1) Deleted my custom VisBuildPro.macros. Actually I removed all the Kinook files under 'Program Data'
2) Removed Visual Build
3) Reinstalled Visual Build

If you click on "Visual Studio & .NET Macros" in Help under Actions/Microsoft the article states that DOTNET_DIR, DOTNETSDK_DIR, and DEVSTUDIO_NET_DIR should all point to the highest versions of the respective utilities. I find that to be true except for DOTNETSDK_DIR which points to v6.1 versus v7.0a which the latest on my system. Is this wrong? Should I patch this on my system?

With previous SDKs, this registry value would be updated with the SDK path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\CurrentInstallFolder

It appears this isn't happening with v7.0a (and I don't see another value that defines the current version), so you will need to manually update the path in the macro value.

The other thing I want to say that I think that there is a fundamental design problem with the Team Test step, i.e. it needs to be redesigned to be Visual Studio version (or framework) specific. The fundamental issue relates to moving to the 4.0 CLR framework. What happens when a customer has existing bld files which run against Visual Studio 2008 and then moves to Visual Studio 2010? In this case they must go back and manually edit the old Team Test build steps to use the old MSTest. Confusing? I think so.

Some users are probably happy if they don't need to update the step when upgrading to VS 2010. At any rate, you don't need to change the steps, just update the global DEVSTUDIO_NET_DIR global macro as needed (or define a project or temporary macro of the same name to override within a project or to switch between versions).