locked
Checking in Enterprise Library RRS feed

  • Question

  • I've searched on this for a while and I'm not seeing anything, so maybe it's just me.

    My team uses the January '06 release of Enterprise Library, and we'd like that library (src and all) to live in VSTS. It is a big, big solution, but it does cooperate with being checked in until it gets to the ObjectBuilder project. Then is just sits there. I have no idea what is going on under the hood and can't tell if it's hung or if it is just taking a really long time to check in the project. The project doesn't seem any bigger than any of the others, so it doesn't make sense that it would be taking any longer based on that.

    This is a new VSTS install and our team is just learning how to use it. Is there some place I can look to see what is happening from the VSTS side?

    Has anyone else had this same problem?

    Any suggestions or pointers would be appreciated.

    Thanks,

    Matt

     

    Thursday, August 17, 2006 5:33 PM

Answers

  • We had a problem getting the Enterprise Library working from TF Source Control as well.  Although our problems centered around 1. the bin directory being converted to read only and 2. "too many characters in path / file name".

    Our solution was to create a new Project Solution named EntLib.  Then we just copied in the Common, Data, and ObjectBuilder projects and the GlobalAssemblyInfo.cs file. 

    After copying those in we deleted all of the Bin and Obj folders. 

    Finally, we added the project to TFS Source Control.  Note: When initially creating the new solution do NOT check Add to Source Control.  That screwed it up for us a couple times.

    I think the trick is to first trim down the main project name.  It is way too long and apparently the source control system doesn't like names / paths that exceed 260 characters...
    Friday, August 18, 2006 3:44 PM
  • Hi Chris. Thanks for sharing what worked for you.

    Late yesterday we finally got this working. Another developer on another workstation was able to get Enterprise Library to checkin in the normal way that you'd expect (without renaming folders or anything). Why it worked for him and not for me, I can't say. AFAIK he did nothing different than I did.

    Another half hour of tinkering was required to get Ent Lib to build because initially VSTS didn't copy the content of some of the lowest level folders. No idea why. So we checked those in by hand. Finally we got down to one compile error, where the build process expected to see a certain folder that didn't exist in VSTS. We checked-in that folder and its contents by hand and the build finally succeeded. Everything has worked well since.

    Matt

     

    Friday, August 18, 2006 3:58 PM

All replies

  • We had a problem getting the Enterprise Library working from TF Source Control as well.  Although our problems centered around 1. the bin directory being converted to read only and 2. "too many characters in path / file name".

    Our solution was to create a new Project Solution named EntLib.  Then we just copied in the Common, Data, and ObjectBuilder projects and the GlobalAssemblyInfo.cs file. 

    After copying those in we deleted all of the Bin and Obj folders. 

    Finally, we added the project to TFS Source Control.  Note: When initially creating the new solution do NOT check Add to Source Control.  That screwed it up for us a couple times.

    I think the trick is to first trim down the main project name.  It is way too long and apparently the source control system doesn't like names / paths that exceed 260 characters...
    Friday, August 18, 2006 3:44 PM
  • Hi Chris. Thanks for sharing what worked for you.

    Late yesterday we finally got this working. Another developer on another workstation was able to get Enterprise Library to checkin in the normal way that you'd expect (without renaming folders or anything). Why it worked for him and not for me, I can't say. AFAIK he did nothing different than I did.

    Another half hour of tinkering was required to get Ent Lib to build because initially VSTS didn't copy the content of some of the lowest level folders. No idea why. So we checked those in by hand. Finally we got down to one compile error, where the build process expected to see a certain folder that didn't exist in VSTS. We checked-in that folder and its contents by hand and the build finally succeeded. Everything has worked well since.

    Matt

     

    Friday, August 18, 2006 3:58 PM