McAfee problem

[RB Smissaert]

Have a problem with one particular user of my software where McAfee takes
out all the code from the ThisWorkbook module of a .xla add-in.
I know this somehow has to do with the Extensibility library (that let's you
program the VBE) and I have moved all code to do with this from the
ThisWorkbook module to a normal module. This didn't solve it.
I then removed the reference to the Extensibility library and used late
binding. Didn't solve it either.

I know that the solution should be to setup McAfee properly and ignore this
file, but the user has some problem with
this and it would be nice if I could solve it from my end.
Any suggestions what I could do next?
Could there be something else to blame, other than the Extensibility
library.
Just to make clear, I know the .xla has no virus!

RBS

 

[papou]

Hello
If helpful at all:
Same behaviour with FSecure (unknown virus found) for one of my workbooks
where code exports modules and imports them into a new workbook (no
references to the Extensibility Library).
And eventually I could find no solution apart from setting FSecure to ignore
such issues.

Cordially
Pascal

 

[RB Smissaert]

Thanks, that is useful to know.
Could you tell me what you think is the trouble-some code in your case?
I think it will have to be solved by setting up McAfee properly.

RBS

 

[papou]

Sure, here it is:
Sub ExportAndImport()
Dim InitialPath$
InitialPath = ThisWorkbook.Path & Application.PathSeparator
ThisWorkbook.VBProject.VBComponents("ModParo").Export "modParo.bas"
Workbooks("AUTO_CEBN_07.xls").VBProject.VBComponents.Import InitialPath &
"modParo.bas"
End Sub

Cordially
Pascal

 

[RB Smissaert]

Is/was the Sub ExportAndImport in the ThisWorkbook module or in a normal
module?

RBS

 

[papou]

Normal module.

Cordially
Pascal

Is/was the Sub ExportAndImport in the ThisWorkbook module or in a normal
module?

RBS

 

[RB Smissaert]

OK, thanks, so moving code away from the ThisWorkbook module doesn't help.
I wonder if I could solve this by moving code to a VB6 ActiveX dll or maybe
by
putting a password on the .xla VBE.
I can't see a way to avoid using VBProject and I think that is what McAfee
doesn't like.

RBS

 

[papou]

so moving code away from the ThisWorkbook module doesn't help

I can't say if McAfee is behaving like FSecure.
By the way FSecure For WorkStations 7.0

HTH
Cordially
Pascal

 

[Lorne]

Have a problem with one particular user of my software where McAfee takes
out all the code from the ThisWorkbook module of a .xla add-in.
I know this somehow has to do with the Extensibility library (that let's
you program the VBE) and I have moved all code to do with this from the
ThisWorkbook module to a normal module. This didn't solve it.
I then removed the reference to the Extensibility library and used late
binding. Didn't solve it either.

I am no expert so appologies if this is the wrong track, but can you create
a personal digital certificate and sign the code and then get the user to
accept all code signed by you?

My version of office has a menu option to create the certificate which
allows me to avoid the annoying "enable macros" warning for my own code and
I was wondering if the virus checkers are set up to ignore gigned code in
which case it should work.

 

[RB Smissaert]

Yes, that might be a solution.
I had a look at this a long time ago, but found the documentation very
unclear and left it. Will have a
look again.

RBS

 

[papou]

Hi Lorne
Nope, not with FSecure anyway.

Cordially
Pascal

 

[RB Smissaert]

That doesn't look very promising then.

RBS

Hi Lorne
Nope, not with FSecure anyway.

Cordially
Pascal

 

[RB Smissaert]

It will need confirmation as I can't reproduce this myself, but I may have
solved this
by moving the suspicious code to a VB6 ActiveX dll. I take it that McAfee
can't read
that. Quite simple:

In VB6 have a class with this code, I have compiled with Global Multiuse, so
I don't
have to Dim as Set the class:

Option Explicit
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

Public Function AddLines(oCodeModule As Object, _
lLineNumber As Long, _
strString As String) As Boolean

On Error GoTo ERROROUT

With oCodeModule
.InsertLines lLineNumber, strString
End With

Sleep 100
DoEvents

AddLines = True 'line added successfully

Exit Function
ERROROUT:

End Function


Then in VBA I run it like this:

Sub test()

Dim VBProj As Object
Dim VBComp As Object
Dim VBCodeMod As Object
Dim lLineOptionExplicit As Long

Set VBProj = ActiveWorkbook.VBProject
Set VBComp = VBProj.VBComponents("ThisWorkbook")
Set VBCodeMod = VBComp.CodeModule

lLineOptionExplicit = GetLineNumberString(VBComp, "Option Explicit")

With VBCodeMod
addlines VBCodeMod, lLineOptionExplicit + 1, "Private Sub
Workbook_Open()"

addlines VBCodeMod, lLineOptionExplicit + 2, _
vbTab & "Workbooks.Open " & """" & ThisWorkbook.FullName & """"

addlines VBCodeMod, lLineOptionExplicit + 3, _
vbTab & "Application.Run " & Chr(34) & _
"SynergyReporting.xla!AutoRunReport" & Chr(34)

addlines VBCodeMod, lLineOptionExplicit + 4, "End Sub"

End With

End Sub


Note the late binding, which didn't help with this problem, but is fine in
any case.
This all runs perfect and hopefully this will fool McAfee.
Great thing this VB6!


RBS