Ask a questionAsk a question
 

Answerautomated check in

  • Thursday, February 15, 2007 7:04 PMThisBytes5 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    How would one automate the check in for a project with in the solution?

    I have the Project instance in a ProjectItem var. We are using TFS for our source control, not sure if it matters or not.

    Thanks
    Wayne

Answers

  • Friday, February 16, 2007 11:00 AMCarlos Quintero - MVPMVP, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    There are three ways to automate SCC operations:

    - Use the EnvDTE.SourceControl and EnvDTE80.SourceControl2 interfaces. You can get them from DTE.SourceControl

    - DTE.ExecuteCommand(commandName) where commandName can be "File.CheckXXX". You can get the list of commands in Tools, Options menu, Environment, Keyboard section.

    - Use some services from the VS 2005 SDK, they can be used from an add-in. Read the SDK help.

     

  • Friday, February 16, 2007 7:37 PMCraig Skibo - MSFT Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    You can use some ExecuteCommand methods to do this, as Carlos stated, but the SourceCodeControl object on the DTE interface deliberately does not have a CheckIn method for one very good reason - automated checkin can be dangerous. When checking out files, if there is a merge conflict you can only cause problems on your computer and your enlistment of that source code. However, when trying to check in, then one of four things can happen - 1) No conflicts and everything works OK. 2) No conflicts so it checks in, but while the merged code does not have any problems, the code may not work as expected. 3) Conflicts, so it does not check in - which would cause the automation to fail. 4) Conflicts, and it forces a checkin - which will definately cause the build to break.

    Because of this, we did not implement a CheckIn method. Checking in code is something that should be watched very carefully by the developer, and we did not want to allow something this dangerous to happen without the user's intervention.

    Craig

  • Tuesday, March 06, 2007 4:06 PMThisBytes5 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    I was able to achieve what I needed with the following:

    vs.ExecuteCommand("ClassViewContextMenus.ClassViewProject.TfsContextCheckIn", "");

    My add in updates our internal framework files that are stored with the solution to the newest version, since TFS requires you to check in deletes before you can add back files of the same name I needed to do the auto check.

    Give the danger of checking in automatically that you pointed out I will be modifying my add-in to fail if anything in the solution is checked out before proceeding. This will ensure that the only thing being checked in is the framework changes.

    Thanks
    Wayne

All Replies

  • Friday, February 16, 2007 11:00 AMCarlos Quintero - MVPMVP, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    There are three ways to automate SCC operations:

    - Use the EnvDTE.SourceControl and EnvDTE80.SourceControl2 interfaces. You can get them from DTE.SourceControl

    - DTE.ExecuteCommand(commandName) where commandName can be "File.CheckXXX". You can get the list of commands in Tools, Options menu, Environment, Keyboard section.

    - Use some services from the VS 2005 SDK, they can be used from an add-in. Read the SDK help.

     

  • Friday, February 16, 2007 7:37 PMCraig Skibo - MSFT Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    You can use some ExecuteCommand methods to do this, as Carlos stated, but the SourceCodeControl object on the DTE interface deliberately does not have a CheckIn method for one very good reason - automated checkin can be dangerous. When checking out files, if there is a merge conflict you can only cause problems on your computer and your enlistment of that source code. However, when trying to check in, then one of four things can happen - 1) No conflicts and everything works OK. 2) No conflicts so it checks in, but while the merged code does not have any problems, the code may not work as expected. 3) Conflicts, so it does not check in - which would cause the automation to fail. 4) Conflicts, and it forces a checkin - which will definately cause the build to break.

    Because of this, we did not implement a CheckIn method. Checking in code is something that should be watched very carefully by the developer, and we did not want to allow something this dangerous to happen without the user's intervention.

    Craig

  • Tuesday, March 06, 2007 4:06 PMThisBytes5 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    I was able to achieve what I needed with the following:

    vs.ExecuteCommand("ClassViewContextMenus.ClassViewProject.TfsContextCheckIn", "");

    My add in updates our internal framework files that are stored with the solution to the newest version, since TFS requires you to check in deletes before you can add back files of the same name I needed to do the auto check.

    Give the danger of checking in automatically that you pointed out I will be modifying my add-in to fail if anything in the solution is checked out before proceeding. This will ensure that the only thing being checked in is the framework changes.

    Thanks
    Wayne