I have created a .net assembly and am able to call and use the assembly at will from outside the PowerBuilder 12.1 IDE within my applications distribution (regasm).
However while I develop inside the IDE the assembly is not visible. How can I access the assembly from within the IDE so I can work with the assembly and my code together?
You need to make sure your .Net component is COM visible. Even then, the methods on the assembly will only be 'visible' in the PB IDE if they are given a DispID and such in .Net.
Related
I have just started a MAUI app project and for the Windows platform target, under Dependencies/net6.0-windows10.0.19041.0/Assemblies, I have added two DLLs. One of them is a c# managed assembly and it uses Interop services(DllImport) to import the other c++ native assembly. It seems like VS is having trouble finding that c++ native dll(The reference is invalid or unsupported), the native dll has a yellow triangle with an exclamation mark in it but the c# dll doesn't have it. Also when I try to run the MAUI app and call into the c# assembly, VS would complain by throwing a DLLNotFoundException for the native DLL.
What am I missing here?
I ran into the same problem. I do not have a solution, but maybe you can verify that you have the same issue:
If you provide a full absolute path for the DllImport() (exact location of the dll you would like to import), it finds it and can use it gracefuly.
Reason for this is because deployed MAUI application for windows Directory.GetCurrentDirectory() method return c:\windows\system32.
I have a problem with the MWArray.dll which is the original dll library from mathworks compiled from Matlab. This dll works under visual studio but not under unity. The goal was to compile under matlab a simple function mycos which calculates a cosinus and uses it under unity with the second dll MWArray mathworks library.
I made a test under Visual Studio and it works well. I have no problem to read the dll and make a call to the mycos.dll class. I made a typical c# project with two references on MWArray and mycos.
But when I try under unity, by putting the two dll under a plugins folder and configure unity 2018 on .NET 4.0 because the dll are compiled with the .NET framework 4.0.
Unity can read the dll but when running I get an error:
NotImplementedException: The requested feature is not implemented.
System.Security.Principal.WindowsIdentity.GetCurrent (Boolean ifImpersonating)
(at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Security.Principal/WindowsIdentity.cs:166)
If I want to use matlab for a research project which was coded in matlab with advanced high level math functions which going to be difficult to recode under unity with c#. So the easy way is to use compiled package from matlab compiler. So is there someone who did this already?
The solution consists in NOT using MWArray.dll in Unity project because of incompatibility with Mono. Create a Visual Studio project (when creating new select the type "console applicatiion"), it MUST be separated from unity project directory, and use it as an application server; in fact in that app you can use MWArray.dll, remember that you have to configure your project configuration to x64!!! In the Unity project create a client app to communicate with the other server project.
Description
I am trying to create a project that will create a DLL file (.COM managed DLL) using VS2010. This DLL will be loaded in VB. Also, I will be using STL in my dll.
Already Tried
1 - Created Visual C++ -> win32 -> Win32 project -> Next -> selected DLL -> ticked export Symbols -> Finish. Will this be a managed .COM DLL? How do I check? Will this DLL be working on 64-bit operating system as 64 bit dll or as x86 dll?
2 - Created Visual C++ -> MFC-> MFC DLL -> Regular DLL using shared MFC DLL
Will this be a managed .COM DLL? How do I check? Will this DLL be working on 64-bit operating system as 64 bit dll or as x86 dll?
Also, There are other two options Regular DLL With MFC statically linked and MFC extension DLL. I don't prefer the first one because it makes it harder to upgrade my dll in the future, And I don't know what the second one does?
Are there any other options I can use to create DLL?
If possible, you should eliminate the requirement to use STL and COM and just create a managed assembly. A managed assembly can be consumed by managed code and can publish events for use by managed code. In Visual Studio, this would be a CLR -> Class Library project.
If you must use STL and COM alongside managed code, then you'll need to create a mixed mode DLL. That's not simple to do, and I don't recommend that route if you have limited experience.
Alternatively, if you can eliminate the requirement for managed code, then you can create a native-only DLL that implements COM interfaces. COM interfaces can be consumed by native or managed code, but they require registration before use and a managed wrapper for use from managed code.
I have a project written for Silverlight 5, which references Silverlight's System.Windows assembly in version 5.0.5.
Now I want to create a unit test project for it using a usual .NET 4.5 library project. When I try to add a reference to the System.Windows assembly 5.0.5 from Silverlight (using the browse dialog), Visual Studio adds the version from .NET 4.5.
Hence the version number does not match.
Why does Visual Studio behave this way?
How do I fix this?
You can reference Silverlight assemblies from a .Net project, but once you have managed to add one, you will likely have problems with dependencies on other libraries.
It will be easier on you if you to try a different approach...
I would suggest using the Silverlight Unit Test Framework to deal with testing your Silverlight code.
If that doesn't fit your need, perhaps Portable Class Libraries will.
When I add a reference (Common properties, framework and references, add new reference) to Microsoft internet controls/SHDocVw.dll and compile the project, a new file is created in the release folder of the project. The file (Interop.SHDocVw.1.1.dll) needs to be in the same folder as the program for it to run.
How do I make my program use the SHDocVw.dll located in system32 instead of the Interop.SHDocVw.1.1.dll in my programs folder?
A primary interop assembly is not used instead of the native DLL, it's a .NET binding layer that loads the native DLL. The Windows DLL is still doing all the hard work.