ASP.NET

How to change the endpoint url of services that Silverlight clients use.

Tim Huffam — Mon, 09 Jan 2012 02:17:26 GMT

If your Silverlight app references services, the endpoints to these services are stored within a config file within the xap bundle - which is usually deployed as .xap file within the ClientBin dir of your web app.

To change the end point urls:
1) Rename the xap file (eg within E:\Demos\MySilverlightApp.Web\ClientBin) to .zip.
2) Unzip it
3) Edit the ServiceReferences.ClientConfig file (to update the endpoint url) and save it.
4) Recreate the zip file
5) Rename the .zip file as .xap

That's it.

TFS 2008 error: MSB4131: The "Reason" parameter is not supported by the "GetBuildProperties" task.

Tim Huffam — Thu, 03 Feb 2011 23:22:32 GMT

This error occured on our TFS2008 (RTM) build server after installing VS2010.

This is caused because VS2010 updates the MSBuild targets file Microsoft.TeamFoundation.Build.targets but not the Microsoft.TeamFoundation.Build.Tasks.dll file (which preforms the tasks mentioned in the targets file).

To resolve you need to update TFS (build) server with SP1. See this article.

HTH
Tim

Error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk

Tim Huffam — Wed, 08 Dec 2010 19:46:27 GMT

This error occurred on our TFS2008 build server which we had upgraded to cater for VS2010 projects (by installing VS2010 on the build server - see this article).

Error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

However - although we had installed VS2010 on the build server - we had not installed the web development components (Visual Web Developer) - this is what caused the error.

To fix - simply add the web development components:

Go into Control Panel - Add or Remove Programs
Select Microsoft Visual Studio 2010, and click on Change/Remove
In the VS Maintenance Mode screens, select Add or Remove Features
In the Setup - Options page make sure 'Visual Web Developer' is checked.
Click on Update.

You shouldn't need to restart your build service.

HTH
Tim

Creating mulitple TFS Build services on the same server - one for VS2008 projects and one for VS2010 projects

Tim Huffam — Thu, 02 Dec 2010 02:51:59 GMT

This is for TFS2008.

This is based mainly on this article: http://blogs.msdn.com/b/jpricket/archive/2007/08/03/tfs-2008-running-two-build-agents-on-the-same-machine.aspx
But also had input from these:
http://www.woodwardweb.com/vsts/000398.html
http://blogs.msdn.com/b/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
http://blogs.msdn.com/b/jimlamb/archive/2010/04/13/configuring-multiple-tfs-build-services-on-one-machine.aspx

Also the following article discussing upgrading a TFS2008 build server to cater for VS2010 projects: http://www.richard-banks.org/2009/11/how-to-build-vs2010-solutions-using.html

Scenario:
---------
We want to use the existing build service the way it is - for VS2008 projects.
We will create a new build service, on the same machine but using another port - for building VS2010/.Net 4.0 projects.
**For this we must have first installed VS2010 on the build server! (see article mentioned above).

The reason we're creating another service is that we found certain VS2008 projects would not build using MSBuild 4.0 (intended for VS2010 - but supposedly catering also for VS2008). The main problem area was unit tests and the private accessor's VS generates (to provide access to private/internal members of a class being tested). The following link provides a work around, but we found this just opened up more problems - and in the end decided that the multi-service solution would get us up and running quickest: http://blogs.msdn.com/b/adamroot/archive/2009/12/10/building-vs-2008-unit-test-projects-in-msbuild-4-0-beta-2.aspx

To create the 2nd build service (VS2010/.Net 4.0 projects): ----------------------------------------------------------- 1) Copy build service executable and config file (tfsbuildservice.exe & tfsbuildservice.exe.config) giving them another name (eg tfsbuildservice_2.exe & tfsbuildservice_2.exe.config). They are located within the following directory: <Program Files>\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies

2) Modify port setting. Edit the new config file (tfsbuildservice_2.exe.config) and update the following line with a new port number (eg 9193): <add key="port" value="9191" />

3) Make the new service use .Net 4.0 - by changing the MSBuildPath - so it references MSBuild 4 (for VS2010/.Net 4.0 projects). Change the following line in tfsbuildservice_2.exe.config from: <add key="MSBuildPath" value="" /> to <add key="MSBuildPath" value="C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319" />

4) Configure URL ACLs. Do this by running the wcfhttpconfig.exe utility in the new directory using the following syntax: wcfhttpconfig reserve <domain>\<user name> <port number> *** You must run this command as a local administrator.

5) Create the new windows service. Execute the following command at the command prompt - as an administrator. Note the spaces after the equals signs. sc.exe create "VSTFBUILD_2" binpath= "D:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService_2.exe" DisplayName= "Visual Studio Team Foundation Build Service 2 (for VS2010 and .Net 4.0 projects)" *** You must run this command as a local administrator.

6) Open the new service's properties and set the account and password to run as, then start it. It would also pay to set this service's startup type to automatic.

You will need to create new Build Agents to point to this new service.

HTH
Tim

Upgrade TFS 2008 to be able to build VS2010 solutions/projects - need to delete workspaces

Tim Huffam — Sun, 22 Aug 2010 22:51:06 GMT

After following steps in this link, I found that my projects would still not build correctly.

The error I got in the build was:

"The path C:\Documents and Settings\myBuildServiceUser\Local Settings\Temp\myProject\Build1\Sources\WindowsFormsApplication1 is already mapped in workspace myBuildServerMachineName_16."

To fix this problem you need to delete all workspaces on the build server (owned by the user account that the build service runs as) - these are named buildservername_nn where buildservername is your build server name and nn is a number it assigns as it generates them (upon the first time a build is run). It appear that these old workspaces are incompatible with the MSBuild 4.0 engine - hence we delete them so it can re-create them upon next build.

To get a list of all the workspaces on the build server use this command:

tf.exe workspaces /owner:myTFSBuildServiceUser /server:myTFSServer /computer:myBuildServerMachineName

tf.exe is run from the VS command prompt (TFS/VS2008 install dir: C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE).

or just run a build - to get the error message mentioned above - this will provide the problem workspace name (eg myBuildServerMachineName_16).

The following command will delete a workspace:

tf.exe workspace /delete /server:myTFSServer workspaceName;myBuildServerUser

See this article for how to delete workspaces.

Attrice's Team Foundation Sidekicks provides a nice GUI to both view and remove workspaces.

UPDATE 21 September 2010:
Updated/re-written to correct a number of things.

If you get the following error:
"TF30076: The server name myTFSServer provided does not correspond to a server URI that can be found. Confirm that the server name is correct."
Then you will need to specify it's full URI eg:
tf.exe workspace /delete /server:http://myTFSServer:8080 myBuildServer_16;myBuildServerUser
See this article regarding this error.

HTH
Tim

VS2010 debugger catching AssertFailedException instead of running and failing tests

Tim Huffam — Thu, 29 Jul 2010 02:18:10 GMT

When workig on a project in VS2010 and performing a "run tests in context" the debugger was catching and halting on a test that fails, raising the exception AssertFailedException. I thought this was strange as the same test (in fact any test) that failed in VS2008 would simply just be noted in the test results as Failed...

Turns out it's the way I've been running tests..

Both VS2008 and VS2010 have the same shortcut mappings:
- "ctrl-r, t" for "Run tests in context"
- "ctrl-r, ctrl-t" for "Debug tests in context"

I've always done "ctrl-r, ctrl-t" - holding down ctrl then pressing r, releasing r then pressing t (while still holding down ctrl) then t then releasing ctrl. This is actually "ctrl-r, ctrl-t".. so should have been invoking "debug tests in context" - but in VS2008 it was not detecting that I was holding down the ctrl when pressing t.

So, now that vs2010 is properly detecting the ctrl key, its running "debug tests in context" (as it should), hence I'm seeing the AssertFailedException being caught by the debugger instead of just failing the test.

So the solution is for me to use the proper shortcut to "Run tests in context" which is": "ctrl-r, t" - hold down ctrl, press r, release r and release ctrl, then press t (by itself).

HTH
Tim

Databinding a .Net WinForms ComboBox to an Enum

Tim Huffam — Thu, 08 Apr 2010 03:00:19 GMT

This is quite simple...

Define the enum eg:

public enum MyEnum{
  ItemOne,
  ItemTwo,
}

Within the form set the datasource of the combobox to the values of the enum eg:

myCombo.DataSource = System.Enum.GetValues(typeof(MyEnum));

To have the combo auto select a value based on a bound object, set the databinding of the combo eg:

class MyObject{
  private MyEnum myEnumProperty;
  public MyEnum MyEnumProperty{get {return myEnumProperty;}}
}
MyObject myObj = new MyObject();
myCombo.DataBindings.Add(new Binding("SelectedIndex", myObject, "MyEnumProperty");

Turning on code coverage/instrumentation in a TFS Build

Tim Huffam — Wed, 17 Jun 2009 04:32:14 GMT

This requires a testrunconfig file that has been configured correctly. To do this I did the following:

In VS2008, right click on Solution Items folder and select Add - New Item...
Select Test Run Configuration and enter the name WithCodeCoverage.testrunconfig.
Open/edit this file in VS.
Select the 'Code Coverage' item on the left, then selected (checked) the assemblies I wanted to instrument
Click Apply to save these changes.

Note that you can select which is the active test run configuration from under the Test menu in VS2008.

Now we need to update the TFS build...

Open your TFS build file (eg TFSBuild.proj)
In the section starting with
<PropertyGroup>
<!-- TEST ARGUMENTS...
Add the following line (after the comments and before the closing of PropertyGroup):
<RunConfigFile Condition=" '$(IsDesktopBuild)' != 'true' ">$(SolutionRoot)\DEV\Release1\Source\WithCodeCoverage.testrunconfig</RunConfigFile>
(update accordingly to suit your build server paths).

That's it. Queue a build to test - you may need to verify your server build paths to get it working (I did).

HTH
Tim

How to turn on unit testing in your TFS build

Tim Huffam — Wed, 17 Jun 2009 03:54:27 GMT

The following will make your builds (running on a TFS Server) execute your unit tests after the build:

Open your build file (eg TFSBuild.proj). VS2008 has a nice xml editor for this.
Search for the RunTest node and change it from:
<RunTest>false</RunTest>
to:
<RunTest>true</RunTest>
Look for a section that starts with:
<ItemGroup>
<!-- TEST ARGUMENTS ...
and add nodes within this (after the comments and before the closing of the ItemGroup node) - one entry for each unit test assembly you have eg:
<TestContainer Include="$(OutDir)\My.App.UnitTests.dll" />

Thats it - check in this file and queue a build.

An error I got while getting this working indicated that the MSTest.exe could not be found - this was because TFS Client had not been installed on the build server - once these were installed it worked fine.

Something else you may want to do is ensure that a build is triggered every time someone checks in. To do this, edit your build definition (right click on your build within Team Explorer and choose "Edit Build Definition...") - click on the 'Trigger' item in the list on the left and make sure the "Build each check-in (more builds)" item is checked.

HTH
Tim

How to unit test against resources (localization) values within Visual Studio 2008

Tim Huffam — Fri, 22 May 2009 21:07:55 GMT

When unit testing you sometimes need to test that values are being set to the correct literal/constant value - and this value is often stored in a resources file.

However, for some reason the VS2008 'Create Private Accessor' feature did not work for me for resources (maybe be cause they're all static properties and the generated _Accessor classes need to be instantiated). So to make these resource available within the unit test project I simply made the Resources class public (by default it's internal).

To do this:

Open the resource file (eg Resources.resx) using the Visual Studio resource editor tool (just double click on the .resx file).
At the top of the editor tab there is a drop down box labelled "Access Modifier" - change this from Internal to Public and save the file.
Rebuild the project.

Your resources will now be accessible in your unit tests.

HTH
Tim