VisBuild.Pro - Application Error too

[mteutsch]

I used VisualBuildPro to create some user-defined actions using VB.NET. After some simple operations:
- creating a MACRO
- removing the MACRO
- logging some TEXT
VisualBuildPro crashes constantly at process shutdown:
The instruction at 0x... references memory at 0x00000027. The memory could not be "read".

I'm using the most recent version of VisualBuildPro (5.5), but I had the same problem with version 5.4. It is officially licenced and I've got it directly from your site.
Whats most intriguing, the VC++ 7.0 version of the ud-action doesn't show the same problem. The application terminates normally.
I've used the VBNETAction-sample included within the software package to test this behavior and built my own COM-Server in VC++ 7.0 to recheck.

Attachments:
- the zipped VC++ project with the .action-file: Test2.zip
- the image of the crash message: crash.jpg
- the modified source from VBNETAction: Test.vb

[kinook]

I'm not able to reproduce that behavior here, but something that might help:

Try

Builder.App.Macros(VisBuildSvr.MacroTypeEnum.vbldM acroTemporary).Add("TestMACRO", "", "", "", False)
Builder.App.Macros(VisBuildSvr.MacroTypeEnum.vbldM acroTemporary).Remove("TestMACRO")
Builder.LogMessage("TestTEXT", True)

BuildStep = VisBuildSvr.StepStatusEnum.vbldStepStatSucceeded

Catch e As Exception

BuildStep = VisBuildSvr.StepStatusEnum.vbldStepStatFailed
Builder.LogMessage(e.Message)

Finally

' release our references to COM objects passed in
System.Runtime.InteropServices.Marshal.ReleaseComO bject(Builder)
System.Runtime.InteropServices.Marshal.ReleaseComO bject([step])

End Try

[mteutsch]

That's not the point. There is no exception triggered at run time. The aforementioned crash occurs when I try to close Visual Build Pro after finishing the script.

[kinook]

I understand. But since this is occurring for you only from a managed plug-in, I suspect it has to do with proper lifetime management of COM resources in the .NET runtime, and the code sample shows how to ensure proper cleanup of these resources.

[mteutsch]

I see. Well, i tried the code sample, but it doesn't help. I noticed that only Win2000 seems to be affected. I couldn't reproduce the error in WinXP.

[kinook]

I was testing on Win XP, which explains why I couldn't reproduce it. I was able to reproduce this behavior on Win2K. Here's the fix:

Dim macro As VisBuildSvr.IMacro = Nothing

Try

macro = Builder.App.Macros(VisBuildSvr.MacroTypeEnum.vbldM acroTemporary).Add("TestMACRO", "", "", "", False)
Builder.App.Macros(VisBuildSvr.MacroTypeEnum.vbldM acroTemporary).Remove("TestMACRO")
Builder.LogMessage("TestTEXT", True)

Builder.LogMessage("Hello from VB.NET custom action in project ")
Builder.LogMessage([step].ExpProperty(Builder, "Msg"))
BuildStep = VisBuildSvr.StepStatusEnum.vbldStepStatSucceeded

Catch e As Exception

BuildStep = VisBuildSvr.StepStatusEnum.vbldStepStatFailed
Builder.LogMessage(e.Message)

Finally

' release our references to COM objects we use
System.Runtime.InteropServices.Marshal.ReleaseComO bject(Builder)
System.Runtime.InteropServices.Marshal.ReleaseComO bject([step])
If Not macro Is Nothing Then System.Runtime.InteropServices.Marshal.ReleaseComO bject(macro)

End Try

[mteutsch]

Yes, this DID solve the problem.
Could you give me some background why the automatical release of the COM-objects fails here?

Thanks for the help
Michael

[kinook]

VBP itself doesn't hold any references to that macro after it has been removed. But its implementation does require that child objects (the macro in this case) not outlive their parent (application). I guess the reference that the .NET runtime is holding is not cleaned up soon enough without explicitly releasing it.