views:

100

answers:

4

Hi, Currently developing a connector DLL to HP's Quality Center. I'm using their (insert expelative) COM API to connect to the server. An Interop wrapper gets created automatically by VStudio.

My solution has 2 projects: the DLL and a tester application - essentially a form with buttons that call functions in the DLL. Everything works well - I can create defects, update them and delete them. When I close the main form, the application stops nicely.

But when I call a function that returns a list of all available projects (to fill a combo box), if I close the main form, VStudio still shows the solution as running and I have to stop it.

I've managed to pinpoint a single function in my code that when I call, the solution remains "hung" and if I don't, it closes well. It's a call to a property in the TDC object get_VisibleProjects that returns a List (not the .Net one, but a type in the COM library) - I just iterate over it and return a proper list (that I later use to fill the combo box):

    public List<string> GetAvailableProjects()
    {
        List<string> projects = new List<string>();
        foreach (string project in this.tdc.get_VisibleProjects(qcDomain))
        {
            projects.Add(project);
        }
        return projects;
    }

My assumption is that something gets retained in memory. If I run the EXE outside of VStudio it closes - but who knows what gets left behind in memory?

My question is - how do I get rid of whatever calling this property returns? Shouldn't the GC handle this? Do I need to delve into pointers?

Things I've tried:

  1. getting the list into a variable and setting it to null at the end of the function
  2. Adding a destructor to the class and nulling the tdc object
  3. Stepping through the tester function application all the way out, whne the form closes and the Main function ends - it closes, but VStudio still shows I'm running.

Thanks for your assistance!

A: 

Have you tried manually releasing the List object using System.Runtime.InteropServices.Marshal.ReleaseComObject when you are finished with it ?

Alex Shnayder
Good suggestion. Will try and report.
Traveling Tech Guy
Didn't work - project still hung :(
Traveling Tech Guy
A: 

I suspect some dangling threads.

When this happens, pause the process in the debugger and see what threads are still around.

leppie
Tried that - there are some threads, but not the main one. How would you suggest I proceed?
Traveling Tech Guy
I am not a threading guy. From what I know, it could be a couple of things. Best will be to use the debugger to poke around, and see who made/owns the threads.
leppie
A: 

May be try to iterate the list manually using it's count and Item properties instead of using it's iterator, some thing like:

for (int i=1; i <= lst.Count ; ++i)
{
 string projectName = lst.Item(i);
}

It might be the Iterator that keeps it alive and not the list object itself, if not using an iterator might not have a problem.

Alex Shnayder
Thanks for the offer - it was the first thing I tried. Didn't work.
Traveling Tech Guy
A: 

Try to add these 2 lines to post-build event:

call "$(DevEnvDir)..\Tools\vsvars32.bat"
editbin.exe /NXCOMPAT:NO "$(TargetPath)"
GExGE
what does that do, if I may ask?
Traveling Tech Guy
Please read here: http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/06d76a1f-b7a5-489b-b937-755cd9bfa90a/
GExGE