none
Error 500 check-in file

    Question

  • Hi,

    I'm getting this error while modifying an existing file to the source control explorer. This error only occurs in one folder, but I can check-in code to other folders:

    - I get this error checkin code from VS2010:

    There was an error contacting the server.
    Technical information (for administator):
    HTTP code 500: Internal Server Error

    - From VS2012: 

    Unexpected end of file. Following elements are not closed: value, property, ExceptionProperties, detail, Fault, Body, Envelope. Line 1, position 478.

    Any ideas to solve it ?

    Thanks in advance

    Monday, July 01, 2013 2:38 PM

Answers

All replies

  • Hi Eforn,

    Thanks for your post.

    What’s the version of your TFS?

    On other clients, other users can check-in on that same folder successfully using VS 2010 or VS 2012?

    Only occurred this issue on your client?


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, July 02, 2013 3:09 AM
    Moderator
  • Hi Eforn, 

    If misunderstood anything, please describe your question in more detail and we will try to provide the better responses.


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, July 03, 2013 10:51 AM
    Moderator
  • Hi John,

    TFS is on version 2010. I can't commit either from VS2010 nor VS2012. At first post describe which message return TFS at check-in file. And this error occurs from any client, it not a workspace problem.

    I'll try to describe my issue:

    - I've my team project with "foo" folder created in my source control explorer.

    - After check-in code many times in this folder, I can't check in file anymore.

    - When I try to check-in code from VS2010 I'm this error:

    - I get this error checkin code from VS2010:

    There was an error contacting the server.
    Technical information (for administator):
    HTTP code 500: Internal Server Error

    - And from VS2012: 

    Unexpected end of file. Following elements are not closed: value, property, ExceptionProperties, detail, Fault, Body, Envelope. Line 1, position 478.

    I'm thinking about destroying this folder and recreate again, but I'll lose folder history.  Any other ideas to solve it ?

    Thank you for you support



    • Edited by eforn Wednesday, July 03, 2013 11:28 AM improve message
    Wednesday, July 03, 2013 11:07 AM
  • Hi Eforn, 

    Thanks for your reply.

    First, I suggest you upgrade your VS 2010 and TFS 2010 both to VS 2010 SP1 and TFS 2010 SP1 separately.

    Try to clean the TFS cache on your TFS 2010 Server, then restart Server:

    1.        Clean the Cache folder on Server machine. The folder path is: C:\ProgramData\Microsoft\Team Foundation\Web Access\Cache_v10.0. (os: Windows Server 2008 R2)
    2.        After cleaned, on Server machine, click Start and select Run… to open the dialog box, then input iisreset.exe and click OK, wait it run completely.

    If clean Cache and restart TFS Server still can’t resolve this issue, it seems that  you need to destroy that folder.


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Thursday, July 04, 2013 9:36 AM
    Moderator
  • Hi John,

    I've test first option and it doesn't work. I'm afraid with your second option. Are you completely sure I'll be able to add this folder to source control again, and the only pain will be history lost ?

    Thanks in advance

    Thursday, July 04, 2013 2:42 PM
  • Hi Eforn, 

    Thanks for your reply.

    Yes, if that folder can be destroyed from TFS Source Control, you can add that folder to TFS Source Control again.


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, July 05, 2013 2:05 AM
    Moderator
  • Hi John,

    Unfortunately folder destroy does not work. I've been refactoring al projects referring to corrupted folder. I guess we have some source control database part wrong.

    Is there any way to delete all references to this corrupted folder from an sql script ?

    Regards

    Monday, July 08, 2013 7:27 AM
  • Hi Eforn,

    Thanks for your reply.

    We don’t recommend to edit TFS databases directly, that will cause the unknown issues.

    For this scenario, I suggest you to contact a Professional Support Service at http://support.microsoft.com/common/international.aspx?RDPATH=gp;en-us;offerprophone to gain more support on this case.   


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by eforn Monday, July 08, 2013 4:09 PM
    Monday, July 08, 2013 7:40 AM
    Moderator
  • I appreciate that this thread is over 4 years old, but we encountered the same problem recently and have managed to identify our problem that may help others.

    Our problem was when trying to check-in a file that was referenced by multiple gated builds and once the number of builds that referenced this file/parent folder got too large, the error appeared.

    The reason for this was that TFS was trying to respond listing all the affected gated builds that could be run to allow the check-in, but this response had increased to more than 64KB causing the response to be truncated and the xml to be invalid. 

    This is obviously a bug in the TFS code, but also a fault in our process.

    Our quick fix was to "remove" some of the builds to allow the process to work and the longer term fix was to move some of the shared code to NuGet packages.

    • Proposed as answer by 10.9 Wednesday, May 10, 2017 11:36 AM
    Wednesday, May 10, 2017 11:36 AM