I've got the hex code of a DLL (which was added as an assembly in my SQL DB).
Is there a way to use this hex code to rebuild my dll?
The DLL is a .net dll, written in VB.
I've solved my own problem in the question below:
Retrieve CLR DLL from SQL Server
Related
I have a DLL and its TLB which works in VB6. I added a reference to the DLL and code to use it. The program builds without an error but gives me a runtime error:
The type initializer for "the dll name" threw an exception.
I am guessing I need to register the DLL or something but do not know how to proceed. BTW, both the DLL and TLB are in my project directory.
Any advice is greatly appreciated.
TIA,
John
Thanks for your response Hans. I may not have been clear. I am not programming in VB6. I inherited the DLL (and do not have the source code) and the client wants me to use it in my VB.Net application. I do not have a way to debug the DLL unless I can do that in VS2008.
Thanks,
John
You're going to need to create an Interop layer between your.Net app and the VB DLL.
Take a look at:
http://msdn.microsoft.com/en-us/library/z6tx9dw3(v=vs.85).aspx
My program requires some function in a dll at runtime. How do I tell where the dll is? I can copy the dll into the program directory or system 32. Is there other neat way of doing this? Thank you. Also I am working in C++.
Are you using native code (C/C++/Delphi) or .NET? You should see my answer to Call Function from Dynamic Library for an example of how to do this with a native (not .NET) DLL.
I'm facing problem while reference vb6 dll in .net project. When ever i refer a vb6 dll in .net project the interop dll is created with same version(1.2.0.0). Its creating problem for me as the setup used to deploy the application at client side does not replace the dll if the version is same as before. I want to change the version of the interop dll (created using vb6 dll). I read it cam done using tlbIMP but how to create tlb file for vb6 dll. Or is there is any other way to achieve this.
Thanks
Saurabh
Here's a small batch file we use to create our interop dll so it's strongly named:
sn.exe -i MichiganLTAP.pfx MagicContainerName
tlbimp.exe ourVb6.dll /out:Our.Strongnamed.Interop.dll /asmversion:7.1.0.0 /keycontainer:MagicContainerName /machine:X86 /namespace:Our.Strongnamed /verbose /sysarray
sn.exe -d MagicContainerName
The important switch from your perspective is: /asmversion:7.1.0.0
You should be able to set that to whatever you want. Check out the MSDN Library page for more info on the switches available.
It makes very little sense to make the version number of the interop library different from the version number of the type library that was created by VB6. There is a one-to-one mapping between what's in the interop library vs the code you wrote in VB6. The interop library simply contains IL declarations for the VB6 COM interfaces, there is no actual code. The CLR uses it to quickly generate the RCW for the interface.
Change the type library version number in VB6 with Project + Properties, Make tab, Version number. Major and minor is what counts. Do this only when you make a change in the publicly visible VB6 classes. Doing so is required btw, it avoids DLL Hell.
When I was reading about DLLs on StackOverflow I came accross the word "Native DLLs" a lot of times. I found questions regarding them but I couldn't understand what a "Native DLL" actually is.
What is a native DLL?
Native DLL's are usually DLL's containing raw processor directly-executable code (such as that found in the Win32 API's) as opposed to, for example, managed (MSIL) which contain code that is consumed and JIT compiled to native processor instructions by a runtime such as the .NET CLR.
In .NET it is also possible to create mixed-mode DLL's that contain both native binary code and managed code.
this term came out when managed code that comes from .net assemblies was invented, to distinguish between managed and unmanaged =native code.
every .net assembly gets "nativied" by the JIT-compiler during execution. this means it gets translated to asm code that is "natively" understandable to the CPU.
The term native DLL was originally used before managed code existed. It was originally intended to refer to DLLs that are not COM DLLs. It is intended to refer to DLLs like the ones in Windows originally.
Note that Kev said "In .NET it is also possible to create mixed-mode DLL's that contain both native binary code and managed code." but that is not relevant; such a DLL is not a native DLL because it has CLI (.Net) metadata. Also, mixed-mode DLL's can only be developed using C++/CLI; no other language supports it.
See my article Native Windows Dynamic Link Libraries (DLLs) for more.
From what I understand a "Native DLL" will be a basic Win32 dll for example. A DLL that contains non managed code.
With .NET you write Managed assemblies. These will call the base level Windows code which is the same that a non-managed application will call.
A quick look through these MSDN search results will answer your question:
http://social.msdn.microsoft.com/Search/en-US?query=define:%20native%20dll&ac=8
It's simple a DLL that contains machine code, rather than MSIL.
I made a program using VB and I lost the source code but I have the exe file. How can I extract the code from the exe file?
Assuming your exe is a .NET assembly (you tagged the question as VB.NET), you can reverse engineer your exe using tools such as Reflector.
If it's VB.NET you can use the RedGate Reflector tool and the FileDisassemler plugin to generate the source code. That is if the exe was not obfuscated
Since you tagged your question vb.net you might be able to retrieve quite some portions of your code using a .NET disassembler. For example try Lutz Roeder's .Net Reflector or MS ildasm which comes with the .NET compiler.
Use Reflector (assuming .NET) to dissassemble the exe back into code. You will need to create your own class structure, but you can recover the code as any of the supported CLR languages.
Have you tried Salamander, or one of the many other .net decompilers?
Trey VB Decompiler and see if that works.