I developed a DLL, let's call it DomainLogic.dll, with some public methods through [DllExport] annotation. Some of those methods make calls to another DLL, let's call it Utils.dll. I developed a demo WinForm application with some buttons that call methods of DomainLogic.dll and everything works as expected.
Currently we have a partner which wants to call our DomainLogic.dll from their existing Visual FoxPro application.
They were able to successfully call dll methods that receive and return strings and open forms. However when they try to call a method that internally makes a call to another DLL (Utils.dll), a FoxPro error is displayed saying "Declare DLL call caused an exception".
SET DEFAULT TO C:\Folder\Containing\DLLs
DECLARE ExampleMethod IN DomainLogic.dll
? ExampleMethod()
Any idea how to solve/debug this?
More info:
Our DLLs require .NET 4.0, they have 4.5.2 installed.
Utils.dll is correct, I successfully called the same methods using my demo app.
We already executed the regasm /codebase command for both DLLs.
We are running the FoxPro app on the same folder as the DLLs using FoxPro's SET PATH command.
Related
I found that:
the dll was detached(process) when I close the window(opend shell namespace externsion), but sometime didn't.
There are some global object in my dll. so, I want to find out when the dll be detached(process).
If you export the DllCanUnload function from your DLL you will be called when Explorer wants to unload your DLL. You can block it if you want, or perform some clean-up before allowing the unload.
i have a problem regarding InternalsVisibleTo.
I have an Assembly named A with an internal test class
I have a Wcf Service (WcfService1) hosted on iis that is referencing this assembly via static linking (add reference on visual studio).
i have the A - AssemblyInfo.cs file with:
[assembly: InternalsVisibleTo("WcfService1")]
I build and add the A.dll to the WcfService1.
Obviously, on WcfService1 class, i call the internal method of the A.dll, and the intellisense signal me correctly the name of the method, the variables etc.
It compile smoothly and no problem is shown.
however, when i build and run on his, the server give me a compilation error:
CS0122 'method called' is inaccessible due to its protection level
so i'm confused: in the Visual Studio IDE i got correctly the autocompletion and no build errors. When run, it cannot use the internal methods?!
Other info: i tried with Strong naming and without(public key calculated via command prompt), with the same result (on IDE is ok, when run it crash).
Found the solution.
I was calling the internal method from the method initialize() of the IIS.
This method is used to do inizialization, and the class with initialize() must be placed in App_Code folder.
I moved the offending call to another class, in my friend assembly, et voilà, problem solved :) hope it will help someone!
I'm converting a VB6 dll to VB.Net using Visual Studio 2008 Express. I want to use the same .dll to integrate with Excel via Excel-DNA, but also to be available via COM (I need to be able to call it from VBScript and VBA).
If I leave the assembly unsigned, I have access to all of the ExcelDNA functionality but no COM access.
If I sign the assembly with a strong name, then when I try to build the .dll I get the following error:
Unable to emit assembly: Referenced assembly 'ExcelDna.Integration' does not have a strong name
What are my options?
You don't have to strong-name a [ComVisible] assembly. It is only required when you want to install it in the GAC. Not strictly necessary although not a bad idea to fight DLL Hell. You need to register it with Regasm.exe using the /codebase option. Visual Studio already does that automatically, although the option might be missing in the Express edition.
Fixing the second problem shouldn't be hard either. Just rebuild the Excel-DNA solution from the source code you can download from Codeplex.
Excel-DNA has an option to expose your .NET classes to COM directly, so you can use them directly from VBA as regular COM classes.
To do this your class must be ComVisible (or the whole assembly must be ComVisible), and you must mark the ExternalLibrary as ComServer='true' in the .dna file, something like:
<DnaLibrary RuntimeVersion='v4.0' />
<ExternalLibrary Path='MyAddIn.dll' ComServer='true' />
</DnaLibrary>
Then you have some options for registration:
either call "Regsvr32.exe MyAddInDna.xll"
or in the AutoOpen of your add-in, call ExcelDna.Integration.ComServer.RegisterServer()
Both of these set the registry entries so that the .xll file becomes the COM server for your classes. You can then access them late-bound from VBA, with CreateObject("MyNameSpace.MyClass").
You need another step to set up a type library (to give you intellisense in VBA). For this you generate the type library with tlbexp.exe. The regsvr32 / ComServer.RegisterServer call will find the type library and register it too.
You can also pack the .dll into your .xll file (adding a pack='true' attribute to the ExternalLibrary tag) and the type library will also be packed if present, and registered from the resource in the .xll file when you call Regsvr32.exe
So the end result could be a single file .xll add-in that is both an Excel Add-In with UDFs, ribbons, RTD servers and also a COM server that you can access from VBA.
More info in the discussions here: http://exceldna.codeplex.com/discussions/252721 and here: http://groups.google.com/group/exceldna/browse_frm/thread/4c5a71efbe96d885.
I have a C# class library which calls a native code DLL. I am trying to call this code from VBA.
I configured MSVC to register the generated DL and it works fine. I can access objects in DLL and work with them without any problem.
I want to register them in another computer and I am using the following command:
%windir%\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /tlb /v MyNetAssembly.DLL
The command return successfully but when I am trying to use the dll objects in VBA, I am getting error file not found (80070002). I tried to add path to the place that dll resides, copy the dlls to windows directory, using /codebase option, without any success.
What is the problem and how can I solve it?
I'm really struggling with WiX. I have .NET assemblies to install that require registration for COM Interop, AND they must be registered with another framework that requires calling a Register() method in a .NET assembly that's in the GAC. This registration method is a 'black box' with a hidden storage mechanism so I can't perform this operation declaratively.
I get that the declaritive approach is best for COM registration, but I have two problems with using heat.exe:
RegAsm works, but Heat.exe chokes on my assembly with the message:
heat.exe : warning HEAT5151 : Could
not harvest data from a file that was
expected to be an assembly:
C:[...].dll.
If this file is not an assembly you
can ignore this warning. Otherwise,
this error detail may be helpful to
diagnose the failure: Exception has
been thrown by the t arget of an
invocation.
The secondary registration that I need to do relies on the [ComRegisterFunction] attribute, which normally triggers further actions at the time the assembly is registered for COM Interop. This normally happens when the assembly is registered by RegAsm.exe or by calling System.Runtime.InteropServices.RegistrationServices. So, I need that ComRegisterFunction in my assembly to execute during the installation.
I don't mind taking the declarative approach to COM registration (or I wouldn't mind if heat worked on my assembly) but I need to call that ComRegisterFunction as part of the install. Ideally, I'd like to look at all of the executables I'm installing, reflect on them for any methods with the [ComRegisterFunction] attribute and call those methods, this would be done after all files are installed.
How can I achieve this in WiX? Or, is there another approach? If it makes any difference, I am using the 'Votive' Visual Studio integration with project references.
These are opposing goals. The point of using the declarative approach is to not use Regasm.exe or Regsvr32.exe to call the registration function. In other words, your [ComRegisterFunction] attributed method won't be called. You can't have both.
The exception that heat.exe dies on isn't healthy, it indicates that there's something wrong with your registration function or class contructor. Debug this by making your DLL the startup project. Project + Properties, Debug tab and make heat.exe the startup program. Set the command line to your DLL. Debug + Exceptions and tick the Thrown box for CLR exceptions, the debugger will stop when the exception is thrown.
Oh, and don't forget to call RegistrationServices.RegisterAssembly in your register function. Regasm.exe won't do it automatically anymore since you used the attribute.
I'll caveat my answer by stating that the correct way to do this is as Hans states - via heat.
An alternative however is to use the SelfRegCost attribute of the File element under a Component element.
Below is an example from one of our older setup kits that's thus far been working with no issues.
<File Source="..\..\External References\MSCAL.OCX" SelfRegCost="1"/>
As with any SO answer, best to check this works in your situation and test thoroughly.