I have a VB.NET assembly that I have registered for Interop. I am using a class in this assembly in my VB6 projects.
In an existing VB6 project I added a reference to the type library and run the following code:
Dim vizDataSingleton As Vizual_Data.Singleton
Set vizDataSingleton = New Vizual_Data.Singleton
The second line errors "Run-time error 430: Class does not support Automation or does not support expected interface"
However if I start a blank VB6 project and add the reference, the exact same code works fine.
I checked the reference to the tlb in the vbp file and they are both identical.
Reference=*\G{BDB20DDF-D3B7-4484-8950-35D67DED45EC}#4.2#0#..\Vizual.Data\Vizual.Data\bin\Debug\Vizual.Data.tlb#VMS Data Structure Library
I tried using late binding as well:
Set vizDataSingleton = CreateObject("Vizual.Data.Singleton")
This errors in the existing project with "Type mismatch" but again works in the new project
Any ideas why this fails in one project but works in another?
I found the cause of this error in the end.
I had another .NET Interop assembly (Vizual_Lib) that was dependant on the original .NET assembly (Vizual_Data).
In the VB6 application that failed it was referencing both of these, but my new application only referenced Vizual_Data. Recompiling Vizual_Lib solved the issue.
This was a strange error was the failure happened when using the Vizual_Data class not the other Vizual_Lib class.
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 an old project made in Visual studio 2015 and I want to reopen it in Visual studio 2017. The project contains several forms but none of them will open without giving the following error:
C++ CodeDOM parser error: Line: 104, Column: 21 --- Unknown type ''. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built.
The mentioned line is: this->components = (gcnew System::ComponentModel::Container());
As far as I can remember I never changed a thing in the InitializeComponent part.
If needed I can copy a full header file, into the question.
How can I solve this issue?
I once and still see this issue often where it says Unknown Type: '' with a blank type.
After a lot of hits and tries, I finally deleted everything inside .vs folder and it started working back.
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.
Hope you could assist me with this problem. I am maintaining an existing application. The problem is it using a dll CGZip.dll for unzipping archive folders. I downloaded the dll from the net and tried to add it as reference but got this error:
A Reference to '../CGZip.dll' could not be added. Please make sure
that file is accessible and that it is a valid assembly or COM
component.
Can anyone please help me in the right direction? Thank you.
UPDATE:
Ok So i found out that this problem is because you have to register the dll first in System32. So I registered both dll and no longer getting the error problem on run time.
But when it hits this code block:
Dim oUnZip As New CGZipLibrary.CGUnzipFiles
It displays this error:
Retrieving the COM class factory for component with CLSID
{293364AE-43F8-11D3-BC2D-4000000A2806} failed due to the following
error: 80040154.
made comment to answer -
Ok, then my assumptions were wrong. Next Question: Are you working with VB6 or VB.NET. VB6 ist strict 32bit, while VB.NET allows 32 and 64 bit. And then you have to register the correct OCX. When you are on 64 bit Windows, and you registered the 32 bit OCX, it will not work, unless you set the cpu type to 'x86'
As part of our migration from .net 1.1 to .net 3.5, we had to change out a few vender DLLs.
One of them is giving us trouble in only 1 spot out of the 4 spots we use it at:
The trouble spot is a windows form project that uses reflection to dynamically load some DLLs that run long running processes. One of these long running processes is an agent that relies on one of our vender DLLs
We're getting the missing assembly exception at the point where we first enter a function that references the library. I already checked the silly things such as if we had forgotten to move a reference from the old version to the new version, but that's not the case. I also checked the bin directory of the project and the assembly is there.
Has anyone encountered a situation in which .net 2.0 runtime refuses to load an assembly like that? And if so, how could we fix the issue.
Additional Information:
The specific vendor in this case is dtSearch and this is the boundry where the error gets thrown:
Private Sub BuildIndex()
SetIndexOptions()
ExecuteIndexJob()
End Sub
Private Sub SetIndexOptions()
'Body removed for brevity
End Sub
The library is referenced in SetIndexOptions. BuildIndex() gets entered, but the exception happens when SetIndexOptions gets called. The function is never actually entered.
If you are still having problems you can use the Assembly Binding Log Viewer (Fuslogvw.exe) to identify which assemblies are loaded by your application. This tool is part of the .NET Framework. This will provide you with details on all dependent assemblies.
I have used this in the past when working with third party assemblies, very usefull
The FileNotFoundException can be raised even when the assembly does exist if one of the dependent assemblies couldn't be loaded.
Try using Dependency Walker to check and see that all dependent assemblies are also present.
Turns out the default compile option changed from VS2003 to VS2008 and it was compiling in the wrong bitness :\ Now I feel a bit silly!