views:

105

answers:

2

I've got a pretty simple web site project that I want to build using CruiseControl.net.

On one page there is a user control nested within a repeater control, and I need to get a strongly typed reference to that user control in the ItemDataBound event handler:

  ASP.usercontrols_stars_ascx stars = (ASP.usercontrols_stars_ascx)e.Row.FindControl("stars");
  stars.StarCount = Convert.ToInt32(drv["rating"]);

This works fine in VS2008 but breaks in MSBUILD with the following error:

w:\CCNet\InflatableBoats\Working\IBWeb\UserControls\DisplayReviews.ascx.cs (49,):

errorCS0234: The type or namespace name 'usercontrols_stars_ascx' does not exist in the namespace 'ASP' (are you missing an assembly reference?)

I think it might be a namespace problem because MSBUILD doesn't seem to recognize the ASP namespace that the web site project uses for user controls and pages.

Thanks, John

A: 

You should reference the codebehind class instead of the ascx generated class. The ascx class inherits your codebehind class. So define your StarCount property in codebehind, reference that, and you should be fine.

jrummell
A: 

Apparently if you reference an assembly from the Browse tab that is listed in the .NET tab of the Add Reference dialog (which is not the same as the GAC) and that is in the same install location, Visual Studio will assume that you want to use the Registry to find the file. I think it sets Specific Version to True, which is the only way you'll notice it in the IDE. This prevents anyone else from compiling it, even if they have the same DLLs in the same location, unless they've run the installer for that package.

This bit me once with CruiseControl when I installed the Unity Application Block straight to a TFS folder, then added the binaries to TFS. The .csproj file did not have a HintPath entry for the reference, so the build server couldn't find the DLL.

I ended up uninstalling the block with Add/Remove Programs, then getting the binaries again from TFS. Removing and re-adding the references fixed the problem.

This may not be relevant to your situation (I'd try jrummell's suggestion first), but thought I'd mention it.

Visual Studio has a tendency to assume that it knows better than the developer. Generally it doesn't.

TrueWill