How can this be done?
At the moment I'm writing the dll out to the parent dir in a wrapper class then calling the Main method from the Main Class I would like however to keep it 'clean' and have nothing written to the disk.
Thanks Ger.
Printable View
How can this be done?
At the moment I'm writing the dll out to the parent dir in a wrapper class then calling the Main method from the Main Class I would like however to keep it 'clean' and have nothing written to the disk.
Thanks Ger.
Storing the dll as a resource(as RT_RCDATA) would not be a problem. But loading it will be. I actually believe it is not possible.
Unless you temporarily save the resource to disk and use LoadLibrary(Ex) to load it, I don't see another way.
Would you have a csharp example of how to load the library?
You want to load a native DLL (not a managed assembly) into a C# program that is contained in a resource????Quote:
Originally Posted by gleesonger
You will have to write some native code to do it - basically a COM interop class that leverages the code in the previous link.
I've refrenced a COM dll and the compiler has created "Interop.SYNCTRLLib.dll" in the source directory of the executable.I would like the application as a stand alone exe.
That is a MANAGED DLL....this makes life simple...you just download ILMerre from Microsoft, and make a multi-assembly executable.Quote:
Originally Posted by gleesonger
you can use ILMerge to merge the CCW into your exe so you don't end up w/ multiple dll's w/ your exe.
http://www.microsoft.com/downloads/d...displaylang=en
Maybe I'm not up to date with the new trends, but what exactly is the purpose of having a DLL embedded in the executable? Doesn't this contradict with the whole concept of Dynamic-Linked Libraries?
Unless you want to hide something (such as a DLL you weren't suppose to use for free, or an open source DLL that's not under LGPL :) )...
There are many good reasons.Quote:
Originally Posted by marceln
You still get the benefits of a DLL, but you now have "copy deployment" of a single file.
You can also update individual components without a re-compile or re-link (this applies to both the native and manages conditions).
I use this quite regularly to provide single file executables. They are very handy in situations such as carring/distributing applications on "tumb-drives".
unlike C++ dll's are the only way to link in external code.
Also, unless you ngen the assembly, it only compiles and loads in memory what is needed. Other portions not used are stubbed out, and JITted as needed, so having everything in one image doesn't mean you're loading everything from the DLL into memory at runtime. so you get the benefit of a typical dll inside a single image.
if you're using COM you have to generate a com callable wrapper, which is what he's wanting to hide or merge into the main executable.
I hate to be a killjoy here, but since it appears an interop assembly is being generated for a COM dll, the COM dll needs to be present and registered on the target machine regardless of whether the interop assembly is included in the resources of the app or not.
And Synctrllib doesn't seem to be in a standard windows dll (what is synctrl.dll) so it'll need installing.
As far as I'm aware COM dlls cannot be loaded into memory and called by the interop assembly. The interop assembly will use the standard COM mechanism for instansiation of objects(CoCreateInstance etc) and therefore requires that the COM dll is present on the hard drive and the necessary registry keys have been created.
Darwen.
Brilliant couldn't be easier.
Thanks very much.
Not sure what you indend by this, can you please elaborate...Quote:
Originally Posted by MadHatter
The MSIL is ALWAYS loaded in its entirity into memory for a given assembly, regardless of how much is actually used. You are correct about how much will be compiled (by JIT) into native code, regardless of the way in which the assembly is loaded.Quote:
Also, unless you ngen the assembly, it only compiles and loads in memory what is needed. Other portions not used are stubbed out, and JITted as needed, so having everything in one image doesn't mean you're loading everything from the DLL into memory at runtime. so you get the benefit of a typical dll inside a single image.
And that is easily done with ILMerge.Quote:
if you're using COM you have to generate a com callable wrapper, which is what he's wanting to hide or merge into the main executable.
Yes, ut that is (or at leads can be) handled by using the appropriate merge module, or chaining an MSI. In either case, it will not be part of the file set that ends up in the application directory (and may in fact be already loaded on the client machines)Quote:
Originally Posted by darwen
no static libraries. the effect of ILMerge is the same as a static library, tough implementation is different (so I think).Quote:
Originally Posted by TheCPUWizard
true, but the native image (in its entirety) is not. that's all I meant.Quote:
Originally Posted by TheCPUWizard
Another method is:
From: http://www.gamedev.net/community/for...opic_id=328884Code:class CoffLoader {
private static void OnAssemblyLoad(object o, AssemblyLoadEventArgs args) {
Console.WriteLine("Loaded assembly {0}", args.LoadedAssembly);
}
public static void Main() {
Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("CoffAssembly.dll");
byte[] coffImage = new byte[stream.Length];
stream.Read(coffImage, 0, coffImage.Length);
AppDomain.CurrentDomain.AssemblyLoad += new AssemblyLoadEventHandler(OnAssemblyLoad);
Assembly coffAssembly = Assembly.Load(coffImage);
}
}
In properties, of a .dll you included in your project, if you set "Isolated = true" you can avoid registration, of that .dll, on the target system.Quote:
Originally Posted by darwen