Unable to create new code review response

Oct 4, 2009 at 9:02 AM

I'm trying out TeamReview on VS2005 over XP-SP3, against TFS 2005. I imported the WIT to my test project and installed the 2005 TeamReview client addin. I'm now able to add a code review response from the team explorer menu, but whenever I try to create one from the context menu within the code, the following message pops up:

"TeamReview is the most complete solution for Team System Code Reviews: a specific work item type and a Visual Studio add-in for a completely in IDE code review experience.
To use TeamReview a solution must be open and bound to a Team System project that contains Team Review's Code Review Response work item type.... "

The TeamReview log contains the following stack:

 

10/4/2009 10:53:11 AM System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.VisualStudio.TeamFoundation.PowerToys.WorkItemDocumentTracker.ProcessDocument(IVsWindowFrame frameWindow)
   at Microsoft.VisualStudio.TeamFoundation.PowerToys.WorkItemDocumentTracker.OnElementValueChanged(UInt32 elementid, Object varValueOld, Object varValueNew)
   at Microsoft.VisualStudio.CommandBars._CommandBars.get_Item(Object Index)
   at TeamReview.VSNetAddIn.Connect.BuildMenu()
   at TeamReview.VSNetAddIn.Connect.OnConnection(Object application, ext_ConnectMode connectMode, Object addInInst, Array& custom)

Any idea what's going on?

Thanks,
-Ofek

 

Oct 5, 2009 at 8:53 AM

Update:

repair-installing the VSTS-powertoys pack solved the issue, BUT it repeats upon first attempted usage. (and repairing powertoys fixes it again...)

Coordinator
Oct 5, 2009 at 10:37 PM

Can you remove the powertoys completely and repeat.

The stack trace, to me, indicates a problem within powertoys.

Oct 6, 2009 at 11:06 AM

Clean reinstall of PowerToys didn't make a noticeable difference.

TeamReview loaded and created a review properly. I suspect trying to replay the review frakked something up, as the 2nd replay attempt failed. Subsequent IDE loads showed the same exception in the TeamViewer log.

Coordinator
Oct 6, 2009 at 10:19 PM

What version of PowerToys are you using ? Please provide the Url to download.

Sorry I previously meant, remove powertoys and do not use/do not re-install. Attempt code review and replays without powertoys installed.

Oct 7, 2009 at 8:29 AM

Ok. I'm using PowerTools 1.2.  Since TeamReview installation included reference to Process Editor, I thought it depends on PowerTools.

Anyway, it's removed now, and there is a certain advancement. I'm now able to repeatedly select Replay, and the log seems clean. However when i select a core review item in the replay grid, the relevant code is *not* selected. When I double-click the item, it is *not* opened. I am able to open the review items from the Team Explorer.

Maybe this can somehow be relevant? Upon IDE start, the TeamReview window shows the following:

startup:
TeamReview: 1.1.1.0
Visit: http://TeamReview.codeplex.com
Menu 'Sql Editor Context Menu' does not exist in this Visual Studio installation.
Menu 'Web Item' does not exist in this Visual Studio installation.
Visual Studio Solution is not open

Thanks,

-Ofek

Oct 7, 2009 at 8:51 AM

Minor extra detail:  I did use the latest existing TFPT download for VS2005. The web page says v1.3, but upon installation it's marked v1.2.

Coordinator
Oct 8, 2009 at 3:15 AM

Just to add, TeamReview has no dependency on PowerTools/Powertoys.

To Replay a code review, you will need the solution open at the time.

Oct 8, 2009 at 4:38 AM

Of course - the solution is open. Tried on 3 different solutions.

Oct 10, 2009 at 9:37 PM

Me again. I decided to take on the opportunity and try on some C# (first time for me, let alone VSX, so please bear with me - I'm just trying to help).  I compiled a debug version and got to debugging it. The direct culprit seems to be CodeReviewReplayWindow.documentService being null. It is set in SetTfsServer(), that as far as I can tell is never called.

I tried trapping what I perceive to be the flow leading to SetTfsServer: GetVersionControl isn't called, neither is solutionEvents_Opened. Not sure what event this handles, and where it is assigned to it . I can say that TFSService.Configure() is called.

Another 2c (that certainly may be due to my utter c# ignorance): when stepping through various CodeReviewReplayWindow methods, trying to set a watch over documentService typically shows "Could not evaluate expression" under 'Value' column, whereas I can easily enough set watch to its sibling CodeReviewReplayWindow.shellDTE.  (who is likewise null, say around the constructor). Don't understand it and can't say if it's relevant - just thought I'd through it in.

Any ideas?  (Debugging tips would be much appreciated too).

Coordinator
Oct 12, 2009 at 1:24 AM

I'll investigate further, solutionEvents_Opened may be some redundant code , I'll have to check.

In CodeReviewReplayWindow.cs, GetVersionControl() is called within the property Shell - setter, when there is a solution name. shellDTE should have a value here.

        public DTE2 Shell
        {
            get { return shellDTE; }
            set
            {
                shellDTE = value;
              
                if (shellDTE.Solution == null)
                    return;

                if (shellDTE.Solution.FullName.Length > 0)
                {
                    GetVersionControl();
                }

                ReBind();
            }
        }

ShowReplayWindowCommand.cs sets the Shell property after the CodeReviewReplayWindow is instantiated.

Set Breakpoints in TFSService.cs method SetTeamProject(). Confirm that variables tfs, tfsExt, versionControlServer all get values,

Debugging these Addins are a pain, I'm working on switching it to a VS package for better VS integration/ Test / Debug / Deploy since it can run in the VS experimental hive.

Oct 12, 2009 at 7:36 PM
Edited Oct 12, 2009 at 7:53 PM

bluess57, thanks.  I had already set breakpoints around. I tried some printf-debugging, figuring maybe the action somehow happens before I get to attach to the debugee VS. E.g., the code you quoted was instrumented to read:

 

                if (shellDTE.Solution.FullName.Length > 0)
                {
                    Instrumentation.Trace("Shell");
                    GetVersionControl();
                }

 

- all unsuccessful.   

However, your other pointer gives a good lead! turns out, in ActivateToolWindow() the line

                CodeReviewReplayWindow replayWindow = programmableObject as CodeReviewReplayWindow;

 

returns replayWindow as null, thereby not calling the shell setter. Any idea what can cause this? How can I debug my way into such an instantiation?

[Edit:]  Maybe I'm going the wrong way about debugging here.  I installed the latest TeamReview public release, and ever since I'm debug-compiling the source and replacing the installed dll with mine.  Now the said CreateToolWindow2 returns a null into programmableObject.  Perhaps the control GUID has changed since the public build, so the compiled version isn't visible to the COM runtime?  How do you recommend debugging addons?

 

Coordinator
Oct 12, 2009 at 10:07 PM

As you found in ActivateToolwindow() , the programmableObject is returning null. This is the cause of the issue.

I have some code modifications which I will send to you to try out, which work around this.

For debugging, right click on the TeamReview project in solution explorer, goto the Debug page.

Fill out these:-

Start external program -> C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe

Start options command line arguments -> /resetaddin TeamReview.VSNetAddIn.Connect

Working directory -> C:\Program Files\Microsoft Visual Studio 8\Common7\IDE

Once you compile the project, usually manually copy the binary to the Team review directory (default is C:\Program Files\TeamReview\TeamReview (2005) )

Then right click project, select from menus -> Debug start new instance

 

Coordinator
Oct 12, 2009 at 10:33 PM

Aaaarrrgghh,

In the TeamReview project, under the properties folder, open AssemblyInfo.cs and change the following ComVisible from false to true. All should be ok after that.

[assembly: ComVisible(true)]

Oct 13, 2009 at 11:29 AM

This issue seems solved - thanks!  I'm now able to select & replay reviews.  BTW, not sure what the ComVisible attribute fixed - it doesn't eliminate the need for your onLoad workaround.

Anyway, the front moved now to a new issue: now I'm unable to change review items created from the editor context menu (say, change the status to 'closed').  When I do, the error 'TF26194: The value for this field cannot be changed' pops up. I cannot modify such items from the team explorer as well.   I *can* successfully modify review items created from the team explorer.   All in all, it seems something is now amiss in the creation process.  Any directions, as to how I can debug that?

Thanks again!

 

 

Coordinator
Oct 13, 2009 at 10:55 PM

Setting the ComVisible Attribute to true in the TeamReview assembly, means in Command\ShowReplayWindowCommand.cs, the programmableObject should now be not null at this line:-

<font size="2">

toolWindow = (

</font>

Window2)windows2.CreateToolWindow2(addIn, asm.Location,"TeamReview.UI.CodeReviewReplayWindow", "Code Review Replay", GuidString, ref programmableObject);

I've reproduced the same error 'TF26194' and looking into it...

 

Coordinator
Oct 14, 2009 at 2:12 AM
Edited Oct 14, 2009 at 2:12 AM

The problem arises as we are trying to coordinate changes between the open work item and the code view replay grid. (The documentservice is holding an edit lock)

The following will resolve the situation, but you will have to live without synchronisation between an open work item and the replay grid.

In method SetTfsServer() in CodeReviewReplayWindow.cs you can comment out these two lines...

//documentService.DocumentAdded -= new DocumentService.DocumentServiceEventHandler(documentService_DocumentAdded);

//documentService.DocumentAdded += new DocumentService.DocumentServiceEventHandler(documentService_DocumentAdded);

Oct 14, 2009 at 7:51 AM

Thanks! - that does the trick.

CreateToolwindow2 now also returns a non-null programmableObject.  I already changed ComVisible to true, but only now does it take effect. Weird.  Anyway, I'm now able to get by without the onLoad workaround too.

Thanks again!

-Ofek