Using VB DLL in .NET 3.5 Windows application ERROR - vb.net

I have a Visual Basic DLL, I used it in a Windows User Control Application. It works fine, but when I HOST this Windows User Control in another Windows Forms application, it gives me the following error.
An error occurred creating the form. See Exception.InnerException for details. The error is: Creating an instance of the COM component with CLSID {66DF4F1A-E3E2-43D3-92BC-D56E9DDCB8AC} from the IClassFactory failed due to the following error: 800a005b.
When I run the User Control it works fine with me, ONLY when I host it in another Windows application this error occurs.
I'm using Visual Studio 2008 & Windows Server 2003
when I add the User Control, the DLL path is "C:\Documents and Settings\USERNAME\My Documents\Visual Studio 2008\Projects\HMS_WF4\HMS_WF4\obj\Release\Interop.DLLNAME.dll"
Notes. it's in Release, but when I compile the application it puts the output in the Debug folder. Even if I select the Release folder for debugging and compilation, when the application is run, it searches for the DLL in the Release folder, but it's in the Debug folder.

I get it....
When I host the User Control in a Windows Forms application, it initialize objects from the User Control objects in Form1.Designer.vb. Like Me.FrmTransactions31.TransHdr = CTransHdrClass2.
I just replaced CTransHdrClass2 with Nothing
Thanks for all.

Related

Using an ActiveX DLL in Visual Studio 2022 causes System.Runtime.InteropServices.COMException

I am trying to build a VB.NET Windows Forms application in VS 2022 using an ActiveX DLL named CP4DLL that I built many years ago in VB6.
I have included a reference to the DLL in the project and the code recognises the objects, methods and properties from the DLL but when I run the VB.NET code it generates the following message:
"System.Runtime.InteropServices.COMException: 'Creating an instance of
the COM component with CLSID {59CA4977-912A-47C6-BAB7-D1B26C0D6ACC}
from the IClassFactory failed due to the following error: 800a0beb
0x800A0BEB.'"
I have a VB6 .EXE application which uses that DLL and when I install it on my computer it and it runs fine.
What else do I need to add to the VB.NET project to solve this problem ?

Uncaught error from thread shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem

I am running an assembly jar file in command prompt and getting the exception below. And resulting in termination.
Uncaught error from thread [ccp-akka.persistence.dispatchers.default-plugin-dispatcher-23] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[ccp]
There is nothing else running in my windows machine while this.
No code access is there except a jar file.
What might be the issue, i tried restarting the machine a couple of times.
Looks like the issue is only with my machine since it is running fine in all other machines. Even i cross checked all the environmental variables.
Attached the screenshot.
What it says that there is a missing binary dependency, leveldbjni, which interfaces with native/platform specific version of leveldb.
Adding leveldbjni-all to your dependencies as described in the docs (http://doc.akka.io/docs/akka/2.5.0/scala/persistence.html#id8) should solve that, if it doesn't then maybe the platform is unsupported (which seems weird, the leveldbjni homepage lists both win32 and win64 as supported - https://github.com/fusesource/leveldbjni)
Step1: Go To "C:\Users\asaini75" and Delete already existing folder ".datastax_studio"
Step2: Go To "C:\Users\asaini75\Downloads\datastax-studio-6.0.0\bin" and click on "server" windows batch file and Wait until you see the below message on your command prompt.
Step3: Go To browser and hit the URL "http://localhost:9091". You will below the home page.
Step4: Add connection and Notebook. it will work perfectly fine.
I installed the Microsoft Visual C++ 2010 Redistributable for my windows machine, that solved my issue. Reference.
The Microsoft Visual C++ 2010 Redistributable Package installs runtime components of Visual C++ Libraries required to run applications developed with Visual C++ on a computer that does not have Visual C++ 2010 installed.
Download link here (x64).

Troubles Migrating VB script (reliant on vendor API) from 32-bit Windows Server 2008 to a 64-bit Windows Server 2012 R2

I'm trying to migrate an script written in Visual Basic from 32-bit Windows Server 2008 to a 64-bit Windows Server 2012 R2. The script connects to SQL Servers, performs some queries and executes calls to a vendor/third-party API.
The dll file with the vendor's API code was not included in the new server installation, so I copied it from the old server. In order for me to be able to add the dll (via Add Reference option) to the project, I had to run the dll through Tlbimp.exe.
When I try to run the executable for my script on the new Windows server, I get the infamous error:
Unhandled Exception: System.Runtime.InteropServices.COMException:
Retrieving the COM class factory for component with CLSID {...} failed
due to the following error: 80040154 Class not registered (Exception
from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
I assume this is a complaint about the third party dll not being registered, so I have tried...
...setting the platform to x86
As per:
Retrieving the COM class factory for component with CLSID {XXXX} failed due to the following error: 80040154. In the MS Visual Basic 2010 Express IDE, I have set the platform to Active (x86) which is the only option I have.
...placing the dll in the System32 folder
...registering the dll
Using regsvr32.exe. But I gett he error:
The module "C:\Windows\SysWOW64\vendor.dll" was loaded but the
entry-point DllRegisterServer was not found...
Admittedly, I don't know the basics when it comes to programming for Windows and I feel like I may be missing something simple or fundamental here.
How do I get my VB application to run on the new server with the vendor API (dll)?
This was indeed a silly error on my part...
When attempting to register the dll, I tried to register the dll that was converted by Tlbimp.exe (the one that I could add as a reference to the project), instead of the original dll file that I copied from the old server.
The original dll file registers successfully and the executable can now run.

Running .EXE file made in visual studio 2005 failure

I would like to run a .exe file made with visual studio 2003 but I get an error every time I run it on a windows 7 machine, vista machine, and xp machine. The error on Windows 7 and vista says "application has stopped working" and then makes me close the error box.
In windows xp it's a little different error, "the application failed to operate (0xc0000135) Click on OK to terminate the application."
That error code seems to indicate the application failed to initialize correctly.
It is possible that the anticipated .NET version is not present.
As far as I know, VS 2003 by default compiles against the .NET 1.1 library. There is no straightforward way of installing this on a Windows 7 or Vista box. Do you need to compile it against the .NET 1.1 library, or can you load it in VS2005, change the output .net version to 2.0 or higher, and recompile the application?
If you have the source code to the application, try running the application in debug mode and stepping through line by line until you find the exception. If you do not have the source code, possibly try running the application in a couple different compatibility modes. Another option to try is to check the windows event log for anything more specific.
If you want to get really deep into it, you can use SysInternals ProcMon.exe and filter on the failing exe to view the WinAPI calls that are happening during the failure.
Also, a basic search of forums shows that error is usually accompanied with framework issues. Either recompile the application or check out what your required framework is in the VS2003 project settings.

My VSTO 3.0 Outlook addin doesn't load

I'm trying to diagnose why my Outlook plugin written in C#/VSTO 3.0/VS 2008 doesn't load after being installed.
The plugin works awesomely on my development machine, which has Visual Studio 2008 installed. I can't expect all my users to have all the prerequisites though so I went through these steps to write an installer:
http://msdn.microsoft.com/en-us/library/cc563937(loband).aspx
I installed the add-in on a fresh Windows XP SP 2 machine with a fresh install of Outlook 2007. It installs all the prereqs ok (.NET 3.5, VSTO 3.0 runtime, Windows Installer 3.1, 2007 PIAs). Outlook starts but the add-in isn't run. If I go to the Add-ins tab in the Trust Center, I see my add-in in the "Inactive Application Add-ins" section with the message "Not loaded. A runtime error occurred during the loading of the COM Add-in.".
Not sure how to find the specific error so I can fix it.
The reg keys look ok. Under HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\BlahAddin I see Description, FriendlyName, LoadBehavior (set to 3 until it fails after which if becomes set to 2), and Manifest.
Tried the VSTO_SUPPRESSDISPLAYALERTS environment variable trick and then launched Outlook from the command line but no output came out.
I have remote debugging more or less working but I'm not sure what to look for. I don't see my DLL loaded when I attach to Outlook, but then again maybe managed DLLs don't show up the same way in VS.
Any other ideas on next steps I could follow to produce a specific error I can diagnose?
Solved my problem after weeks of pain. The "Manifest" reg key was getting corrupted to some junk value during the setup build. It was a known Visual Studio bug that supposedly got fixed in Visual Studio 2008 SP 1, but apparently wasn't for me. Renaming the project name to be different from the plugin name fixed the problem. Random, huh?
Make sure you have try-catch handlers at the top level of all methods called by Outlook and log any exceptions you are unable to handle in some way. Focus your troubleshooting on methods like the Startup method and other methods called during initialization.
You probably want to debug this using the remote debugger. Share out the MSVCMON.EXE folder from your developer machine (in your Visual Studio folders in Program Files) on your test machine (share it with a UNC path), and launch Outlook under the debugger trapping (.NET) exceptions in your modules and putting breakpoints in your methods.
If you need to clean your test computer each time before you install your solution, you should probably run XP under a Virtual PC 2007 VM (free download) and switch to a differencing HD after setting up everything but your plugin to snapshot your pre-installed state once so you don't have to keep uninstalling/reinstalling as you make changes to your program to fix bugs.
Are you installing Debug builds or Release builds? Perhaps one flavor has different requirements. Just guessing.
-Mike [MSFT Office Dev]
On your machine, when you run the addin from Visual Studio, it should create a registry key in HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion{SomeGuid}. Make sure that these registry settings are also being deployed with your addin. They are the ones that allow your code to be trusted.