locked
Trouble Generating a Build in TFS 2013 / Can't find DLL RRS feed

  • Question

  • I have a solution that contains nine windows form projects, one web application, and one common DLL that all of the projects reference. I can build locally in VS-2013 with no problems. TFS is running on a separate machine to include the build server. I am a one man developer team. I have my build definition set to Any CPU | Release. A am getting an error related to each place within the Web App I have the AjaxControlToolkit referenced. That DLL is located under the BIN directory within the web app. Been Googling till I am cross-eyed. Any help would be appreciated. Thank you.

    Monday, January 18, 2016 3:33 PM

Answers

  • Here is what Sinjith from Microsoft worked out for me - The Ajax Toolkit should be moved out of the BIN directory within the Web App to a new folder hanging off the Solution root. I moved the DLL to a new folder named CommonDLL. Go into the properties for the Web App and update the reference to the DLL. Next you will want to go to Builds under the Team Explorer and click on Actions and select Manage Build Controllers. Highlight the Controller then click on Properties. In the box that pops up set the path to the new common DLL folder off the root of the solution. (Version control path to custom assemblies) Click Ok and back out. Then check in. All the credit goes to Sinjith from Microsoft getting me up and running.

    One of the wrong turns I was taking was in the Solution Explorer I did not download the latest version. I am fairly sure that was causing the Ajax DLL to keep reappearing in the BIN directory of the web app. My confusion, I think comes from being a one man band with the full source always residing on my local workstation. I never thought I needed to download something I already had. But thinking of it in a Team environment that makes perfect sense.

    Hope this helps someone…

    Thursday, January 21, 2016 2:11 AM

All replies

  • Hi Jeff,  

    Thanks for your post.

    As we know that TFS 2013 Build invoke 12.0 MSBuild command to build solution on build agent machine. Before build solution using TFS 2013 Build, we should ensure the following steps:

    1. The solution can be built completely on Build machine using VS 2013.
    2. Ensure the your TFS Build Service account have the permission to build this solution on the Build machine.
    3. Ensure the solution can be built on Build machine using 12.0 MSBuild command manually.

    And we usually using the following two way to reference dlls when using TFS Build:

    1. Create a Assemblies folder under Solution, and add all your dlls in this folder. After we check in the solution into TFS, the Team Build Service will get the solution from TFS to build on the Build machine, in this case, the Assemblies folder under solution will be get together. The structure like this:

          TeamProject

                  /Solution1

                          /Assemblies

                          /Poject1

                          /Poject2

                          /…

                   /Solution2

                   

    1. Create the same common folder on the Build machine as you created on your client, and the folder path is same. So when the Team Build to build the solution on build machine, it will try to find the dlls on the Build machine follow the relative path which your set in your project.

    Additionally, check and ensure the projects build order is correct when during TFS Build.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.




    Tuesday, January 19, 2016 7:40 AM
    Moderator
  • Thanks John for the feedback. The build compiles locally in VS. I been at this about a week with not much luck. I saw a post earlier speaking to moving the DLLs to their own folder. I tried that and for some reason the DLL kept getting copied back into the original folder every time I did a build. Further posts said to remove all the old references which I did. That turned into a pretty big mess where I had to delete the entire solution and bring it back from backup. Being a one man team with nobody around to draw on and being new to TFS I am sure the problem has to do with how I have things set up. I went ahead and opened a support request.
    Tuesday, January 19, 2016 3:23 PM
  • Hi Jeff,  

    Thanks for your  reply.

    When this issue be resolved from MS support, please share your experience here.

    We look forward to your updates.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, January 20, 2016 2:06 AM
    Moderator
  • Here is what Sinjith from Microsoft worked out for me - The Ajax Toolkit should be moved out of the BIN directory within the Web App to a new folder hanging off the Solution root. I moved the DLL to a new folder named CommonDLL. Go into the properties for the Web App and update the reference to the DLL. Next you will want to go to Builds under the Team Explorer and click on Actions and select Manage Build Controllers. Highlight the Controller then click on Properties. In the box that pops up set the path to the new common DLL folder off the root of the solution. (Version control path to custom assemblies) Click Ok and back out. Then check in. All the credit goes to Sinjith from Microsoft getting me up and running.

    One of the wrong turns I was taking was in the Solution Explorer I did not download the latest version. I am fairly sure that was causing the Ajax DLL to keep reappearing in the BIN directory of the web app. My confusion, I think comes from being a one man band with the full source always residing on my local workstation. I never thought I needed to download something I already had. But thinking of it in a Team environment that makes perfect sense.

    Hope this helps someone…

    Thursday, January 21, 2016 2:11 AM
  • Hi Jeff,

    Thanks for your reply.  

    And thanks for share the experience here.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, January 21, 2016 4:48 AM
    Moderator