Team Build - Website under Team System Source control
I have the Team Build Configured and I am also able to start the build from any of the client machines. The library, console, windows services and application are all compiling with out any errors but when it comes to compiling websites I am running into issues. All of these projects are under Team System source control.
The website has Project references to other library projects within the same solution but the team build does not seem to be copying these referenced assemblies into the website's bin directory after compiling those libraries, because of this the website compilation is failing, is there any thing that i need to do to make sure the assemblies all are copied over to the right place?
Thanks,
Krishna
Hi,
The link in that post was related to Mapping of paths which is fine and there are no such issues with my configuration.
Mine is related to copying over the binary outputs from the other library projects in the same solution as that of the website when using Project Reference, if I use assembly reference instead of Project reference the compilation is not giving errors. Even the log shows the error as missing assembly reference in the former case [compiling within the IDE on the client machine works fine] Example from Compilationlog.txt :-
d:\Development\yyyy\Complete Build [Debug]\sources\website\App_Code\UIBaseClasses\PageHelper.cs(8,0): error CS0234: The type or namespace name 'xxx' does not exist in the namespace 'xxx' (are you missing an assembly reference?)
Thanks
This sounds very much related to bugs in beta 2 regarding source control, web projects, and Project references. There have been quite a few bugs posted about this in the product feedback center, here is one of them:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=ddc06744-622d-474e-a9b0-d74a4617b589
VS shouldn't be placing the contents of the /bin directory under source control, but it does. So when you build your web site that has project references, it builds those referenced projects and sticks their dlls in the /bin directory. Since the /bin directory and its contents are under source control, VS tries to check out those older binaries, but if they are checked out by someone else that operation will fail (only one person can check out a binary file).
Hope that helps, and I hope that gets taken care of in the future.
