Strangely enough we run Infragistics controls too (not my choice) but we're Windows Forms. What I will say is make sure that the exact same version (year, release, and hotfix level) of the controls are installed everywhere, or change "Specific Version" to false in the reference properties. Infragistics name their controls with a major and minor version number in the assembly name, this will stop you getting too far "out of sync", version wise.
You could also diff the (working) web.config on your local PC against the one returned to your PC after you do an update from source control. That might lead you to a solution. Incidentally, you shouldn't need to open the solution on the build server at all - some seem to prefer not to have Visual Studio installed on there at all, relying instead on just the .NET compiler. I would also set Copy Local to True on the Infragistics references, and make sure the DLLs make it into the bin folder on your target web servers. This way you're not relying on what might be in the GAC on a third party box. HTH Tom 2008/10/10 David Carson <[EMAIL PROTECTED]> I thinks I have now bumped into one of the problems that the previous Devs > encounted. > > I have standardised the file structure and performed a checkout. Loading > the project resulted in a number of errors but I expected this. I updated > all the references (to allow for the new paths) and the project built fine. > I then checked everything back in and did an update on my PC (which has the > correct file structure) and the build failed :-( > > The problem can be traced a a set of Infragistics references which are > shown with a Type of 'BIN' on the build server but as 'GAC' on my PC! Adding > them on my PC causes the web.config file to be updated and the build now > runs fine. Doing the same on the build server does nothing to the web.config > file but updating it manually breaks the build! > > I know this is going a bit off topic but there must be a solution to this > but I can work it out. > > Any assistance appreciated. > > Cheers > Dave > > 2008/10/10 Tom Fanning <[EMAIL PROTECTED]> > > In general, the more of your code base you have under source control the >> better. With a VS-based project, your project and solution files are a >> given. If the application has a database, get the schema (or scripts to >> generate one) checked in too. Some go so far as to put even the tools >> required to build the source into source control along with the source >> itself. >> >> .sln and .csproj files are just text-based, nothing too crazy. My source >> control (Sourcegear Vault) doesn't like merging them though, so it requires >> exclusive locks. This may be the key part that have caused issues for your >> predecessors - just make sure that anything referred to in the .sln and >> .csproj files also exists in your source tree. >> >> Feel free to come back if you have further questions :-) >> >> Tom >> >> 2008/10/9 DilbertDave <[EMAIL PROTECTED]> >> >>> >>> I think that the introduction of CCnet is going to throw up a few >>> 'flaky practices' which have only worked in the past because 'so and >>> so know how to do that!'. >>> >>> First step here - standardise project file system structure. >>> >>> Thanks for the input >>> Dave >>> >>> On Oct 9, 3:00 pm, "Ross Patterson" <[EMAIL PROTECTED]> wrote: >>> > On Thu, Oct 9, 2008 at 08:56, DilbertDave <[EMAIL PROTECTED]> >>> wrote: >>> > > I think that part of the problem is that we do not check-in >>> > > the .csproj or .sln files >>> > >>> > That sounds like a serious omission. If you don't check them in, you >>> can't >>> > build from the source as checked in. >>> > >>> > Ross >>> >> >> > > > -- > ====================== > Dave Carson BEng (hons) > > There are 10 types of people.. > Those who understand Binary, > and those who don't..... > ====================== > What am I doing now? > Find out at Twitter : http://twitter.com/DilbertDave >
