After searching and applying all solutions for below problem, are not working.
What I have done-
1. I created a .dll in C#, made its com visible ture.
2. I creadted the .tlb using regasm.
3. Created a Delphi 7 project where I imported this type library (.tlb) and calling the function of this dll.
4. All is running fine on my PC.
Now when I copied these all files (including .dll, even .dcu too) to another PC (.Net framework 4.5 installed) and tried to run the .exe, it gives me error "Class not registered", when I tried registering it with RegSvr32 then it shows error -"Entry point not found".
What else am I missing? Is there any other prerequisite to run Delphi 7 exe with dll on another PC?
To register a .net assembly you must use regasm and not regsvr32.
Making the entire assembly COM visible is probably a mistake. Do you really want to make all public type COM visible? It would be more usual to apply the ComVisible attribute to specific types.
You don't need to copy dcu files. These are used as intermediate files for the Delphi compiler. Assuming you aren't using runtime packages, just the executable, and the registered assembly should suffice.
Related
I have a .Net add-in and within this I have referenced a DLL I have made in C++/CLI. The DLL was designed against the OpenCV API - so now my .Net application can take advantage of the cool graphics capabilities offered by OpenCV.
The problem occurs when I deploy my add-in to other computers. When the user enacts a part of the program that specifically calls upon my C++ DLL it complains about missing the reference:
I suspect the code does not actually know where the DLLs are located but within my dev environment everything (obviously) works as I will have my environment set up different to your standard build PC.
What am I missing here ?
How can I successfully call DLLs created in C++ from a C# add-in? Bearing in mind add-ins are supposed to simplify the customisation of software like Office etc. This is very important - I have to be able to roll in non-.Net DLLs into my project and my code be able to find them.
My dll is just a plain dll, not a COM compatible dll (maybe it should be?) or should I be decorating my C++ code with __declspec(dllexport) a la https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport?view=vs-2017
So 2 things
Use Dependancy Walker to identify any dependancies on your dll and the dlls it uses further down the 'tree' hieracrchy. I found 2 that were missing and it wasn't obvious without this useful tool. Don't be overwhelmed with the results it gives you, just take notice of the missing dlls it's complaining about.
Make sure your dll is referenced within your project and not outside of it in some other folder where you built it.
This fixed my problem - in general just make sure your dlls are on the same path as your executable.
I need to modify my existing DLL in c# to interface between PowerBuilder 2017 (PB) and an external DLL developed by vendor. external.DLL is using .net 4.6.1
PB Target <-> my.DLL <-> external.DLL
I have set my.DLL up to be COM Interop enabled (Make assembly COM-Visible + Register for COM interop) and have previously set this to work in PB IDE without 'external.DLL' just fine by applying following commands:
regasm my.DLL
gacutil my.DLL (this is used only so PowerBuilder can access the DLL from within it's IDE)
Now, I try and reference external.DLL through my.DLL from PowerBuilder IDE I receive an error -3 code (Object could not be created).
How am I best to setup and also distribute both DLL files?
I think my issue is in setting up the References within Visual Studio 2017.
The COM interop is needed between PB and my.DLL.
I tried to add a follow Debug option as this would be helpful, but cannot trigger it.
Thank you for help.
I managed to get my.DLL working inside PowerBuilder IDE by using regasm on the external.dll and adding it also into the GAC.
For deployment of the PowerBuilder Application I expect to apply regasm to both DLL's and place them in same distribution folder.
I have a legacy project that uses a OCX. I had to register said OCX on my system using regsvr32.
Now, I want for Jenkins to compile the project. Unfortunately, in the Jenkins Server there is no OCX and I don't want to register it.
Is there a way to distribute the OCX so the project can compile on Jenkins? I read about registration-free components, but there seems to target runtime requeriments, and my issues are at compile time.
Yes - the way to do it is as Reza Aghaei says.
Call tlbimp to generate an interop assembly (it doesn't have to be a primary interop assembly). Then instead of referencing the ocx in the project, you reference the interop dll.
Note that if you want to run the project or use the control in the winforms designer you'll still need to register the ocx. Build for Building from Jenkins, this will work fine we use this technique to build our legacy code.
PROBLEM
I created a C# project that implements the System.Management.Automation reference (allowing me to write powershell commands in my project).
I compiled the project and copied the dll to the plugins folder of my Rainmeter application so that I could leverage it along with the other dll 's Rainmeter comes with.
This works perfectly on my machine (64 bit); however, I want to load this same configuration on another server (also 64 bit). Both machines are using the same installation of the .NET framework (4.5).
According to this source, I should be able to simply copy the Rainmeter folder with the included dll and it should run without any problems (I'm using the portable installation of Rainmeter).
I receive the error "System.IO.FileNotFoundException" unless I remove the "SystemVersion.dll" that I created, when running Rainmeter on another server.
QUESTION
Since the issue is clearly the dll I have added, I'm assuming the reference is not being added to the dll?
=========================================================================
EDIT
As per #Hackerman 's answer, the issue was that the dll was unable to find my reference. The path for System.Management.Automation required powershell version 3.0 to be installed on the machine in order to load the reference.
My server was running powershell version 2.0, but after installing version 3.0 the dll was able to load the reference and Rainmeter would display my results as expected.
When you build your class library, the references don't get embedded on your final dll. The System.IO.FileNotFoundException that you are getting is because your dll can't load the System.Management.Automation.dll reference on the destination server. Installing PowerShell 3.0 on the server should resolve the issue.
I have a python project that calls a c++ wrapper dll that calls a c# com interop dll.
In my computer, with all frameworks and programs installed, my project runs very well.
But in a computer that just got formatted it doesn't.
I allready installed c++ 2008 redistribute and the c++ part is working but when I call a function from it (that will call the c# correspondent one), it gives an error.
I want to know what are the dll dependencies from both c++ and c# dll's to see what is missing :)
Looks like you need Dependency Walker.
Dependency Walker (a.k.a. depends.exe) works for both native DLLs and managed DLLs.
It is included in some Visual Studio versions, and can also be downloaded here.