Well, what i want to do is Injecting a C# DLL into another C# process,
then from outside (lets call it "the injector") call a method of that dll, all of this from c#.
Is it possible?
How to do it?
Thanks
EasyHook is your friend.
You can use the remote hooking functionality it provides to load a managed dll into target process, and invoke methods with .NET remoting.
I think that you mean .net libraries' dlls. Because c# is programming language not a process. In .net projects, dll's comes from .net runtime libraries. In order to load dll's in runtime you can use:
Assembly.LoadFrom("example.dll");
Related
I'm writing a C/C++ application which uses a luajit runtime. In this runtime I want to load .NET DLLs and call functions/create objects exposed by it.
After a lot of research I've found some libraries which can achieve this, luainterface for example. But the problem with all these libraries is that they require a Lua runtime running in .NET itself.
Is there a library which I can preferably require as a module from which I can use .NET DLLs?
I have a Classic ASP website with vb6 dll's and all is ok with the world, but now I have some extra functionality that has been completed using c# into a COM DLL. In the dev environment this is working, but now I wish to move this DLL onto another machine.
My question is what is the best way to do this?
I have seen answers such as "add it to the GAC" or, "in needs a strong name", etc.
What happened to the good old regsvr32?
Regsvr32 is still relevant today but you can't use it with .NET, only native DLLs. .NET has a special way to register COM-types as we shall soon see.
Regsvr32 works by invoking the DllRegisterServer export. DllRegisterServer gives the library a chance to register COM classes; type libraries; interfaces etc. This export is not present in .dlls created by .NET which makes sense because they are not COM by default. You can easily see these differences if you open up a .NET or non-.NET .dll in Dependency Walker/Viewer.
Here's a native c++ ActiveX dll I made earlier (Note the DllRegisterServer export on the right):
And here is a managed .dll. (Note there are no exports let alone DllRegisterServer):
If you have marked your c# class as COM-visible then you can complete the COM-registration by invoking:
regasm assemblyFile[options]
Tell me more
This will place the necessary entries into the Windows Registry.
There is no need for the GAC because native COM clients (VB6) do not use the GAC
I am developing a managed lib (using Microsoft Web Services) and I am
including it into a c++ project. The project doesn't use /clr option,
so when I include my library's header file VS2005 show me an error
saying I have to use /clr option. Doing this I have a incompatibility
with /EHs command line option (error D8016), but changing from EHs to
no exception handling not solving problem and keep showing me same error .
Any suggestion is welcome.
Thank you in advance.
If you have unmanaged C++ code and want to use managed code, you have a few options:
Change your unmanaged code to C++/CLI, by use of the /clr switch.
Write a C++/CLI wrapper library. It could DLL-export unmanaged functions which you call in your unmanaged code.
Skip the wrapper library and directly DLL-export unmanaged functions via this library.
You can't use a managed lib from an unmanaged c++ application. Since you add the /clr option, your c++ application becomes managed too (just for the record :) )
Here's what might help you: http://msdn.microsoft.com/en-us/library/ffkc918h.aspx - the restrictions of the /clr option.
It is possible to write managed c++ adapter, that will call the C# library, and call this adapter from unmanaged c++ program as you would usually call a normal c++ library. You will compile your adapter library with /clr and your main c++ program without /clr if for whatever reason you want to keep it unmanaged.
You can embed a mono environment and start an AppDomain. mono's runtime API will allow you to instantiate classes and call members on them. It will be clumsy, but is will work
http://www.mono-project.com/Embedding_Mono
Note that Mono is a full .Net 4.0 compliant CLR and it can work with the Microsoft core libraries on Windows.
On windows and Unix it can work with the Mono corlib/class libraries. There are areas not covered in Mono, but they seem to get sparse. You can use the MoMa tool to spot whether your application uses incompatible/incomplete APIs.
Or you can just use the Microsoft .NET framework, assuming you're on windows anyway!
I have an application written in .NET 4.0 that i compile into a DLL file. I want to be able to use this DLL file in a Windows Forms .NET 2.0 application. I don't need the application to really interact much, except just passing a couple string values to the 4.0 DLL. The DLL is pretty much a bunch of Windows which i converted to UserControls and i just need to be able to reference them to display the UserControls from the 2.0 application without having to use a different exe and having to package them separately. What is the best way to do this? Because when i try to add the reference to the DLL to the 2.0 application, it gives me and error saying the DLL is built in a newer version of .NET so i can't do it that way. Is this where a COM object would come in? Any information and links i would really appreciate, thanks.
If the application can really and truly be called from a 2.0 application then the best approach is to compile it as a 2.0 application. Visual Studio 2010 (and 2008) support the notion of multi-targetted solutions. That is you can use it to compile a project for various versions of the CLR.
I would take the approach of compiling my application twice
Once for 4.0
Once for 2.0
This way you can use the DLL directly in your 2.0 application. No messy COM tricks needed
Calling a .ne 4.0 from a .net 2.0 is indeed possible. The problem is not that, but i dont think you can send the usercontrols across!
Im doing this in a couple of soultions where im passing simple classes from 4.0 to my 2.0 assemblies. The trick is to register the 4.0 assembly as a ServicedComponent (COM+), then share an interface (.net 20) betwewen these assemblies. Then in your .net 2.0 assembly instantiate the ServicedComponent and retrieve an instance of your interface from the "middleware" assembly.
As stated, you can only transfer interfaces through this, and marshalling a complex type as a UserControl i think will be very difficult.
I know it's possible to run a .NET application using a portable Mono executable without having .NET framework installed but is it possible to load and use an assembly is this situation?
thanks in advance.
If you're trying to load an assembly without the Microsoft .NET framework, the only possibility I know of would be to embed Mono into your Win32 application, and use it to host the assembly. The Mono embedding API could potentially be used to open and execute your .NET assembly (using the mono runtime and libraries).
I'm unclear as to what you're asking but it appears to be ...
Is it possible to use a normal .Net Assembly from a Win32 process if the CLR is not installed?
If so the answer is a resounding no. All .Net apps require the CLR to be installed in order to run.
it is possible to create and distribute an application without needing to install the .net framework, for example Vmware Thinapp (or Xenapp) can do that, putting the framework and the executable in a single container.