I have a VB.NET 2010 program that works perfectly with MS Office XP. Because of security concerns attributed to Office XP, I recently upgraded to MS Office 2007. I made no changes to the VB program.
A single Build Error, Type Excel.Global is not defined. is preventing the program from running. The ErrorList points to the UpgradeSupport module as the location of the error.
The entire UpgradeSupport module is as follows:
Module UpgradeSupport
Friend DAODBEngine_definst As New DAO.DBEngine
Friend ExcelGlobal_definst As New Excel.[Global]
End Module
The instance of Excel.[Global] above is the only visible instance of it in the entire program, and there are no instances of Excel.Global at all, anywhere. The variable name, Excel.Global (or Excel.[Global]) suggests a structure. Moreover, I believe Global (or [Global]) is a property, not a type, and I believe Excel.Global and Excel.[Global] are not equivalent expressions. I can successfully define structure Excel.[Global] as follows:
Public Structure Excel
Shared Property [Global] As Object
End Structure
Note: The above will not define successfully without the square brackets around Global, which supports my assertion that the two expressions are not equivalent. I question whether any instance of Type Excel.Global exists in the program. Nevertheless, the Build Error continues to prevent the program from running. How can I eliminate the Build Error?
Related
I've an old VB6 program which I have haven't used for several months. The program references numerous C# assemblies (.NetFramework 4.8). Running the programs as binaries, it all works fine.
I have opened the VB6 ide to step some of my code and I am now encountering an automation error "The system cannot find the file specified." (Err 80070002) when trying to instantiate one of the COM Interop classes. This didn't used to happen.
Private Sub InitMessageStore()
Dim l_oBusFactory As IfxBusService.BusFactory <= COM Interop reference
Set l_oBusFactory = New IfxBusService.BusFactory <= ERROR here
l_oBusFactory.InitialiseMessageStore GetConnection(m_oIfxsys.Dbase.Database.Definition)
End Sub
The COM Interop decls
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[ComDefaultInterface(typeof(IBusFactory))]
[Guid("200C6C26-6881-4CB5-A8E7-E0E5532D6D5F")]
public class BusFactory : IBusFactory
[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
[Guid("5531BD20-2C7B-452B-A7D7-2D05E39EB83E")]
public interface IBusFactory
I have rechecked the registry registrations for the above ... the salient one being
and the file is in the folder location as specified in the registry.
I'm using Win10 Version 10.0.19044 Build 19044. I'm running everything as administrator. I have DEP switched to essential Windows programs and services only.
As I said above, everything works fine when run as binaries, but, to me, it looks like the OS is stopping the VB6 ide from loading a COM Interop assembly.
Any suggestions as to how I can get stepping through (but not necessarily into) my COM Interop code working again.
In the end, I missed that there were 2 entries under the InprocServer32, one of which pointed to the correct file (1.0.0.0), but the other one (5.80.0.111 - which is actually the version no of our com binaries) didn't point to a file:///, but rather the pure .net assembly. Once I deleted the incorrect one, it all started working ok.
Still not sure where the wrong one came from!
I have the below code to create an instance of Visio from Excel. It works on machines where I have a single version of Visio installed, but on some machines I have 2 versions (2010 and 2016) installed. On these machines it fails to run with the error "Method 'Visible' of object 'IVApplication' failed". When I check AppVisio its empty, and I am guessing it is because both applications are visio.exe. Is there a way to create the object from a specific path, or any way to createobject when 2 versions are installed?
Set AppVisio = CreateObject("visio.application")
AppVisio.Visible = False
Set docsObj = AppVisio.Documents
There are some options I believe.
Solution 1 (I would recommend this one). Install only Visio 2010 on your development machine (and uninstall 2016). It's safest to have the lowest version you want your app to run with on your dev machine anyways. Add a reference to Visio 2010's type library in Excel. Remove the reference to Visio 21016 type library. Visio versions are upward-compatible, so the code should run properly even on the machine with Visio 2016.
Solution 2. Use late binding. Remove the reference to the Visio from your excel project altogether and use only script-like access. In this case, you will lose auto-completion though. If your app is not a big one, that should not be an issue.
Solution 3. (if you want to run a specific version). You can start the Visio application from the program files (like any other executable), and then connect to it using "GetObject(...)" instead of "CreateObject(...)"
BTW, there is a better way to run Visio as invisible app (without flashing):
Set appVisio = CreateObject("Visio.InvisibleApp")
If you early-bind it by adding a reference (Tools | References) to the desired version then Diming your object as that type, you'll be guaranteed which version you're using.
Dim visioApplication as Visio.Application
Set visioApplication = new Visio.Application
However, that may not be the full solution if your company is mid-upgrade and some folks have the new version and some the older version. You'd get run-time issues on the machines that don't have your chosen version.
To solve that issue, you could create MyApp2010 and MyApp2016, each linking to the appropriate version of Visio, but that becomes a bit of a maintenance nightmare for you...
Early-binding does add loads of benefits like IntelliSense and turning most run-time errors into compile-time errors, so it's probably still worth it.
I manage an application that allows the users to automate tasks by writing their own VB code. The user code is compiled using the VBCodeProvider and invoked against the running instance of the application. We've been doing this for a few years now starting with .NET 2.
Traditionally, we have imported the System namespace in the compiler settings so users wouldn't have to write System. all the time. When we went to .NET 4, however, we found that statements like Windows.Forms.Form wouldn't compile anymore. The error was "Type 'Windows.Forms.Form' is not defined." This is odd because other namespaces work. IO.Stream and Reflection.Assembly do not have an error without the System at the beginning.
I've created a simple example. I've put the below code into a file. Then I compiled this file with vbc.exe from both the .NET2 and .NET4 directories. The 2 version works fine. The 4 version will not compile unless you comment out the variable f2.
Imports System
Public Class MyClassName
Public Shared Sub Main
'this works in v2 and v4
Dim f As New System.Windows.Forms.Form
f.ShowDialog
'this does not work in v4
Dim f2 As New Windows.Forms.Form
f2.ShowDialog
End Sub
End Class
Does anyone know how to get this to compile in vbc.exe version 4? And before you say "Just tell the users to type System.Windows.Forms" I will agree that it would be great if they would do that, but users do what users do and I have to work it out.
UPDATE:
I've found that the Windows.Foundation.Diagnostics namespace is causing a collision with the abbreviated use of Window.Forms. Is there any way to hide this namespace from my compilation? Visual Studio 2010 does not have the same conflict, so it must be getting around it somehow.
I'm running into a weird issue with a VB.Net project using the MySql ADO.Net connector. I have the following code:
Dim param As New MySqlParameter("#val29", MySqlDbType.DateTime)
And I'm getting the following error message:
Ambiguous invocation:
Public Enum member Datetime As MySqlDbType (in Enum MySqlDbType)
Public Enum member DateTime As MySqlDbType (in Enum MySqlDbType)
match
The difference between them, if you notice, is that DateTime is in a different case then Datetime. Since this is VB.Net and VB is case-insensitive, I'm not sure why I'm getting this error.
Interestingly enough, I opened Object Browser in Visual Studio 2013 and, as you can see from the image below, there does seem to be two definitions of DateTime:
.
Thinking maybe there was an issue with the DLL, I went to their website and downloaded the source code and rolled my own DLL. Same issue. I couldn't seem to find anything on the Internet about it, except for this page, which describes my issue exactly, except it seems to be due to a specific bug in Visual Studio 2015. I'm using Visual Studio 2013. That almost makes me think a Windows Update came along that changed the way the VB.Net compiler works. That doesn't make any sense though because updates are specific to Windows, not Visual Studio. Anyone have any ideas?
'In VBA one disadvantage of calling a class procedure with CallByName ist that when an custom error was raised in the called object procedure, the caller always gets error 440 regardless of the original error number being raised.
Microsoft gives a workaround in this article http://support.microsoft.com/kb/194418/en-us.
It suggests instead of CallByName the use of InvokeHook. Therefore the library "TypeLib Information" (TLBINF32.DLL) must be added as a reference.
My question is: is this library available by default on every Windows PC, where only MS Office is installed (no Visual Studio etc.)?
Thanks in advance for your answers