VB6 in Access adp (copied from VBA forum - thanks Skip)

[DaveCSS]

Hi All
We have an Access VB6 program (developed over many years) that gets installed by us on customers machines.
I have now added a VB.Net program to the mix that gets run (ShellExecute'ed)from the VB6 program under certain circumstances.
Is there any way that I can prevent customers machines (running W7/8/10) popping up the UAC dialog box?
The VB.Net prog has a Manifest that contains all the stuff that others have suggested and make no difference:
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
<applicationRequestMinimum>
<defaultAssemblyRequest permissionSetreference="FullTrust" permissionSetReference="FullTrust" />"
<PermissionSet version="1" ID="FullTrust" unrestricted="true" SameSite="site" Unrestricted="true">
<IPermission class="System.Security.Permissions.FileDialogPermission, mscorlib, Version=1.2.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
</PermissionSet></applicationRequestMinimum>
Any help gratefully received
Cheers
Dave

 

[strongm]

>Access VB6

Do you mean VBA 6? Or do you mean a VB6 program that automates Access?

 

[DaveCSS]

Its Access VB6 which ends up as either a prog.ade or prog.adp
Dave

 

[strongm]

OK, Access "VB6" is not VB6, it is VBA (and suggests that you are using a version of Access prior to Access 2010). Skip has misadvised you, I'm afraid.

Also, whilst VB6 can indeed use manifests, this particular manifest is for the VB.NET package (again, VB.NET is not VB6), so you might be better off asking in forum796

Who wrote the VB.NET program? Is it a 3rd party?

 

[DaveCSS]

Ah OK Access VBA.
The Access program was originally written a long time ago by a (long gone) programmer in the company I joined 3 years ago.
It is currently being rewritten in .net but that version is a way off atm, so I wrote this .net program (to utilise ActualMaps from VDS Technologies - works a treat!!) that will interface with the new version when that arrives.
In the meantime we just need it to work seamlessly from the Access VBA!
I have moved the 3 files that the .Net prog reads, into ProgramData (made no difference) but it does do a lot of (MS) SQL - could that cause the UAC?

 

[strongm]

>so I wrote this .net program

Excellent - so you should be able to embed the correct manifest info in the program itself, rather than as a seperate file. Or are you saying that that is what you have already done?

 

[DaveCSS]

Yep, the manifest code in my first post is embedded in the .Net prog

 

[strongm]

Can you provide the entire manifest?

 

[DaveCSS]

Here it is:
<code>
<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity version="1.0.0.0" name="BACASMap.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.

<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />

Specifying requestedExecutionLevel element will disable file and registry virtualization.
Remove this element if your application requires this virtualization for backwards
compatibility.
-->
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
<applicationRequestMinimum>
<defaultAssemblyRequest permissionSetreference="FullTrust" permissionSetReference="FullTrust" />"
<PermissionSet version="1" ID="FullTrust" unrestricted="true" SameSite="site" Unrestricted="true">
<IPermission class="System.Security.Permissions.FileDialogPermission, mscorlib, Version=1.2.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
</PermissionSet>
</applicationRequestMinimum>
</security>
</trustInfo>

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- A list of the Windows versions that this application has been tested on and is
is designed to work with. Uncomment the appropriate elements and Windows will
automatically selected the most compatible environment. -->

<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />

<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />

<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />

<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />

<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

</application>
</compatibility>
</assembly>

</code>

 

[strongm]

OK, so try the following:

<code>
<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity version="1.0.0.0" name="BACASMap.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.

<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />

Specifying requestedExecutionLevel element will disable file and registry virtualization.
Remove this element if your application requires this virtualization for backwards
compatibility.
-->
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
[b][COLOR=#3465A4]<applicationRequestMinimum>
<PermissionSet ID="FullTrust" Unrestricted="true" />
<defaultAssemblyRequest permissionSetReference="FullTrust" />
</applicationRequestMinimum>[/color][/b]
</security>
</trustInfo>

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- A list of the Windows versions that this application has been tested on and is
is designed to work with. Uncomment the appropriate elements and Windows will
automatically selected the most compatible environment. -->

<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />

<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />

<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />

<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />

<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

</application>
</compatibility>
</assembly>

</code>

and, if that doesn't work, try

<code>
<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity version="1.0.0.0" name="BACASMap.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.

<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />

Specifying requestedExecutionLevel element will disable file and registry virtualization.
Remove this element if your application requires this virtualization for backwards
compatibility.
-->
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
[b][COLOR=#204A87]<applicationRequestMinimum>
<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true" ID="Custom" SameSite="site" />
<defaultAssemblyRequest permissionSetReference="Custom" />
</applicationRequestMinimum>[/color][/b]
</security>
</trustInfo>

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- A list of the Windows versions that this application has been tested on and is
is designed to work with. Uncomment the appropriate elements and Windows will
automatically selected the most compatible environment. -->

<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />

<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />

<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />

<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />

<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

</application>
</compatibility>
</assembly>

</code>

 

[DaveCSS]

Hi Strongm
Thanks for all the help, but neither made any difference!
If you have any more thoughts I would be grateful - its driving me nuts!!
Cheers
Dave

 

[strongm]

Right - probably best to take your question to the VB.NET forum, as previously linked.

 

[strongm]

But, just in case - what is your code for ShellExecute?

 

[DaveCSS]

Hi Strongm
Thanks - but I've solved it - I needed to change the Shellexecute to a simple Shell command!
I had tried that when I first started but for some reason it failed and I put it out of my mind.
Anyway, thanks for your help
Cheers
Dave

 

[strongm]

Hence my question about ShellExecute - glad you got ahead of me and solved the problem.