Publishing test results fails - not sure why...

No, I did not get anysort of popup or prompt when I tried to publish the data. Where could I look or what should I look for on the TFS Server (1 machine setup) to see if the error is on that end?

Regards,
Michael Shorten

MichaelShorten at 2007-9-8 >

dhopton MSFT wrote:

If you checked on the client, then the only other area I can think of is if the firewall is configured on the server.

OK... anything in particular I should look for? What ports/packet types should be cleared through the firewall?

Regards,

MichaelShorten at 2007-9-8 >

dhopton MSFT wrote:

Having looked at this - there are no other ports that need to be opened in the Server, other than the standard ports for TFS - that is 80 & 8080. I know I keep pushing this issue, but if you have ANY firewall on the client (including XPSP2's Firewall), and that firewall is enable you must add an exception for visual studio otherwise you cannot publish.

Well, here's the thing - I don't even get the dialog box that the Walkthru says I should get - when I click the Publish Test Results button, it just goes straight to the window and displays "No Test Runs were published." So I don't know that a connection is even being established.

Here's what I can tell you about my setup:

- I have Norton Antivirus only.
- I've confirmed that MSDE (as it's listed on the Security Center as such for B2) is cleared as an exception to the firewall.

Anything that I could look at on the event log or server side? This thing seems like it should be cooking.

Regards,

MichaelShorten at 2007-9-8 >

dhopton MSFT wrote:

IF you have the windows firewall enabled: Go to Control Panel Windows Firewall Exceptions Tab See if "Microsoft Visual Studio 2005" is listed, and has a check box checked next to it. If not: Add Program Find Visual Studio (It should be listed, if not navigate to: C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe or as appropriate) Click Ok Ensure that is is checked. Restart VS. Also, one additional port to check on the server: File & Print Sharing enabled - this is to enable files to be dropped correctly for big build.

MichaelShorten at 2007-9-8 >

It sounds like you have the following:

Server:
Win2k3 SP1?
Application Tier
Data Tier
Big Build
Windows Firewall turned off

Client:
WinXP SP2?
VSTS
Windows Firewall turned on but with VS as an exception

All with beta 2 builds, right?
Also, can you please verify that you have the following setup?

- A team project containing at least one completed team build.
- A node within the team project selected in team explorer

How big is the test run that you are trying to publish? It sounds like it is fairly small, but I wanted to double check. Also, did you choose to include code coverage data when you published?

Finally, to verify that I am envisioning the steps you are taking properly, is the following correct?

- Select a node in team explorer
- Run some tests
- In the test results window, click on Publish Tests
- Select a test run and a build in the dialog displayed
- Click Publish
- The test results window changes its layout somewhat and displays the error message from your first post.

To give you a little bit of background on what is going on in the publish, here's the general idea. Some of this is changing for RTM, but for beta:

Once you click Publish from the publish dialog, we:
1. Open a .Net remoting channel on the client and pass the URI to this channel to the application tier web service (VSTFWeb, specifically :8080/TeamBuild/PublishTestResultsBuildService.asmx">http://<yourservername>:8080/TeamBuild/PublishTestResultsBuildService.asmx, the PublishRun method).
2. The web service then connects back to the remoting channel on the client to upload the files in the test run.
3. As the files are uploaded, the web service writes the files to the build drop share over SMB.
4. Once all the files are copied, the web service updates the tables in the operational store on the data tier.
5. The client waits asynchronously for all of this to happen. If the operation completes, the status is displayed in the Test Results window. If the operation times out or another client-side error occurs, that error is also displayed in the Test Results window.

Cheers,
Tom

TomNguyen-MarshMSFT at 2007-9-8 >

Hi, Michael,

Thanks for the info.

Re the requirement of having a team build, we associate test results with a team build. When you click on the Publish button in the test results window, you should see a drop-down of all the builds available for the project selected in the team explorer window. You have to choose one of these to be able to publish. If you have no builds, the drop-down will be empty and the Publish button will be disabled.

If you are not using team build to build your product, then you have two options:
- If you want per-build reporting, then create team builds that mirror your real builds. These builds don't need to actually build your source, they just need to exist on the Team Foundation server.
- If you don't care about per-build reporting, you can create a single team build and publish all of your tests against that build. If you are publishing code coverage data, I don't recommend this approach. We merge the coverage data from all test runs published against a build to give per-build coverage information. If you use a single build for the entire lifetime of your product, those merge operations would get very long.

So, now back to the problem at hand. :)

I'm not sure why you never even see the dialog, but I'd like to try to check whether the client is able to contact the server at all. Can you please try the following?

- Create the directory C:\logs and make sure that your Application Tier service account has write access to the directory.
- Turn on tracing for the Big Build web service on the AT machine by uncommenting the system.diagnostics tag in %programfiles%\Microsoft Visual Studio 2005 Enterprise Server\BBIISDIR\web.config.
- Run through your repro until you see the error message.
- Open the log file from c:\logs. It should be called teambuild.server.log.
- Search for "Entered method: GetListOfBuilds" and let me know if you find it. If you want, you can also look around for any other exceptions or errors that might be reported. For now, I just want to know whether the connection is being made to the server or not.

Cheers,
Tom

TomNguyen-MarshMSFT at 2007-9-8 >

Hi,

We've had a deeper look and were trying to repro the issue and compare log files - I'll post back here when we've done that (it's in progress right now).

In the mean time we have one more thing for you to try -- publishing from the command line. To do this You'll need to work out the build ID for the build you are trying to publish too.

steps:
1: Connect to the Data Teir
2: Start SQL Manager
3: Open the VSTeamTeamBuild Database
4: Open the Builds table
5: Look for a value from the "BuildURI" Column

This is the build ID -- you can use this to publish from the command line.
example commandline:
mstest /testcontainer:path\to\test.dll /publishserver:http://server:8080 /publishbuild:06022_040032_70438

You need a VS Command prompt to invoke mstest.

Can you tell us what the outcome here is?

Also, I just want to confirm, for the sake of completeness that the dialogs and buttons you are pressing are correct.
1) You have selecting the correct Team Project in Team explorer, and the Publish button has become enabled (http://dhopton.projecthurricane.com/publish_button.JPG)
2) You are NOT seeing this dialog (http://dhopton.projecthurricane.com/publish_dialog.JPG). If you do see this dialog, then great. If not, we're still working on a possible reason for this.

When we've looked at our trace logs, I'll post back again.

dhoptonMSFT at 2007-9-8 >