End Goal
I have an x86 dll built in c++. I need to be able to use the dll from a portable class library. This can be directly or indirectly, but I want to keep the entire application local on the users computer.
What I have tried
I have designed a c++/cli wrapper to allow access to the dll. I confirmed it works through an x86 console C# project.
I tried using the wrapper directly from a portable class library but it would not allow the reference.
I tried using the wrapper from a wcf library but the library is having problems with the cross platform dll.
I think I'm making this way too complicated but I am unfamiliar with a way to do what I want. I can't rebuild the dll in 64-bit and do side by side loading - I only have the option of using the x86 dll.
Thank you for the help.
Why do you need to reference a C++ DLL from a Portable Class Library? A C++ DLL isn't going to be usable from multiple platforms. The point of PCLs is that they can run on more than one platform, but that means everything they reference needs to also be a PCL.
Probably what I'd recommend is to use the abstraction pattern, as described here.
Related
Since I first heard about the introduction of Native AOT feature in .NET 7 and that it was usable on console executables and class libraries, I wanted to try out on some library projects I already had. Then, rised a problem I can't seem to workaround no matter the amount of research made. In fact after compiling successfully into a native dll, I don't know how to use it inside other .Net projects as it is no longer recognized as a .Net library type to be added as reference.
If anyone could enlighten me on how to access the methods compiled in that native dll from any other project in .Net, this could really mean a lot to me.
I have tried using the export attribute on public methods in the original library code to make them visible to external call. And then using import attribute on the caller project but nothing seem to work I can't see any public method from the generated dll.
I am using C# to create a game using MonoGame which I wish to use on multiple platforms (which I know MonoGame can do).
Is there a way to create a .dll in C# and load it from other operating systems (preferably iOS, Android and MacOS) without recompiling the library? I am prepared to write a "loader" application for each platform, but would not like to rewrite the entire project.
I'm hoping there is a way to load functions from a .net dll (i.e. load the game) on these platforms without using paid products such as MonoTouch.
Basically the .NET/Mono Assemblies all get compiled to CIL Code which is an ECMA Standard.
However, you still have to program your game in a way that it do not depend on OS specifics.
Don't refer to certain .NET Assemblies (i.e. No WCF, cause it has only limited WCF support, no WPF at all, no WWF)
Don't refer to OS specific DLLs (i.e. no P/Invokes to kernel32.dll etc.
Don't use OS specific pathes or use preprocessor directives to make OS Specific code (yes, this will require recompile and you probably won't get around this easily)
Threading on Mono has some catches, so you will probably have to make platform specific code using preprocessor directives.
Honestly, I don't see a problem with having to recompile your code, if it's clearly written it's just a matter of adding a new project to your solution file and setting the preprocessor flags. Then all you have to do is compile the solution and have multiple DLLs in your bin folder. No one ever said you have to rewrite the complete project (unless the project is already finished and has any of the dependency mentioned up there), which in this case... it's your own fault for not having to think about it before starting development.
You'll just have to deploy your Apps (on iOS etc.) with the required Mono Runtime. And for this you will probably need something like Xamarin or wire up your own Mono runtime
Reference links:
http://www.mono-project.com/Compatibility
http://www.mono-project.com/MoMA
You can look at the Xamarin-Framework. But you always have to recompile your project.
Xamarin
on these platforms without using paid products such as MonoTouch.
This will be difficult.
Premise:
Wrote a COM-callable wrapper (CCW) written in C# to be called by VB6 code.
The C# code has .NET libraries (third party) that it must utilize.
The wrapped C# class instantiates fine, raises events properly, takes method calls properly.
Problem:
The VB6 code, when running the C# code, gets an error when the C# code attempts to access the additional .NET libraries mentioned above.
Process tested:
C# wrapped code completed.
VB6 code written, references the COM dll created.
"File not found..." error received when the C# code tries to access the .NET libraries from inside itself.
Copied the third party .NET libraries into the main folder of the VB6 code (also into system32 folder).
Still "File not found..." error.
Wrote a C# Windows Form test project. Referenced the C# wrapped code.
Received the same error as the VB6 code.
In C# Windows Form test project, referenced the .NET libraries used by the C# wrapped code.
The program ran just fine.
Conclusion/Question:
Can VB6 call/use a com-callable wrapped C# program that references other third party .NET libraries?
I've done this with tons of third party libraries and as long as the third party library DLL's are in the same directory as your C# DLL's there shouldn't be a problem.
Copying them into the same directory as your VB6 code will do nothing, the effective directory of VB6 code when running the in VB6 debugger is %ProgramFiles%\Microsoft Visual Studio\VB98, so the code running will have no visibility of that.
The system32 directory has nothing to do with DotNet dll's (the only DLL's they would affect is PInvoke'd dll's and you say you add a reference so that isn't the case).
Adding the third party library to the GAC should fix things, however that is not necessarily possible/easy due to the need to sign the DLL. So just make sure the Libraries you are referencing are in the directory of YOUR library and that VB6 is actually referencing that version of your library (Debug/Release whatever what last compiled). You may want to hand RegAsm the library to make sure the correct library is Com Registered.
So to sumerize, suppose your source code looks like this:
c:\projects\vb6project
c:\projects\c#project
And your project is set to Debug, the third party libraries should be in:
c:\projects\c#project\bin\Debug
When you actually want to distribute the application, make sure that ALL the libraries are in the same directory as your VB6 exe.
This will mirror somewhat the answer by Kris Erickson.
First, for my usage which solves these problems, I did not use the GAC. Assuming that my VB6 application is in c:\program files\mycompany\vb6app.exe, I placed the COM-friendly .NET dll (lets call it net4vb.dll) in the folder with the executable. I then regsiter that dll there with RegAsm using the /codebase option. Finally, I place the .NET assembly that I'm wrapping or using (lets call it purenet.dll) in that folder as well.
At this point, vb6app.exe should run with no errors.
It is important to note that if you select the "Register for COM Interop" in Visual Studio then it will overwrite the registration you did above. So do not use this option. Stick with the command-line tools only for this.
All of my cross-platform libraries are created with solutions that have two projects: one that builds on the Silverlight CLR and one on the regular CLR. Hence, every library I make has two DLLs: name.dll and nameSilverlight.dll.
This is, as far as I know today, the only way to do it.
However, I recently tried Mike Talbot's "Silverlight Serializer" DLL, and I could include the same DLL in a C# desktop and in a Silverlight application. It's the exact same file.
How did he do that? And how can I do that?
(I really need to do it, because I'm trying to serialize in a desktop app and deserialize in a Silverlight app, and the assemblies are not matching up because they're different.)
It may be that they are using the Portable Library CTP.
Silverlight 3 is a "lowest common denominator" and if you just use base/core classes, you can compile a DLL there and reference it directly from .NET. You cannot, without the portable library, do the converse however.
I want to use c++ library in a c# project. Is there any wrapper tool to import all classes automatically?
SWIG can help create a wrapper consisting of two parts, one C++ sided, and one C# sided.
It needs a bit of work to set up the correct generation files though.
An alternative that requires more manual coding is C++/CLI.
For pure c apis I prefer p/invoke over either of them. There is a program to automate conversion of c headers. If I recall correctly it's called something like "P/Invoke Interop Assistant" or "Interop Signature Toolkit".
There is also mono/cxxi which looks pretty cool.
The procedure of using native .dll's in .Net is called P/Invoke. Look at http://pinvoke.net/ for some examples.
Note that you must match the build target with the version of the .dll. So for x86 .dll's you need to lock your project to x86, same with x64.
Note2 that you only need to lock the executing project (.EXE), not any additional projects loaded from the .EXE. .Net will automatically match .Net .dll's to CPU target type if they are set to ANY.
From http://social.msdn.microsoft.com/forums/en-US/clr/thread/c957959e-0f0c-422e-a5be-4ccfdd12e63d: You can use "dumpbin /exports <name_of_your_dll>" or dependency walker (depends.exe) to look at the exported symbols. They are both included in Visual Studio.
Additional comment on C++: While it is relatively simple to use native .dll's written in C from .Net, using C++ binaries that make use of objects is not as trivial. One way to solve that is to use a C++ CLI project a binding between managed .Net code and unmanaged C++ library.
If this is unmanaged code then you could use P/Invoke. Another possibility is to use the C++/CLI extensions to compile the code into a managed assembly that you could directly use.