Printable View
In VB6 if I compile I get a nice simple something.exe which I can move around at will.
With vb.net I got several files
things like
Interop.VBScript_RegExp_55.dll
Interop.SHDocVw.dll (for automating internet explorer rather than webbrowser control)
Interop.Scripting.dll
So is there a way to just "register" those DLL so I can copy just the exe files around and the computer knows where to find the corresponding dll.
Thanks.
you can merge dll with exe and create an single exe.
google "merge exe and dll" you will get the solution..
The size of the .exe will be too large.
Can we register dll?
That being said it's still a good solution. Why can't I rate you?
What happens when you try?Quote:
Originally Posted by teguh123
The reason you get those DLLs is because you are referencing COM components. .NET apps cannot talk to COM components directly, so they need those DLLs to INTEROPerate with them. VB6 is COM-based so it doesn't need a bridge. If you avoid using COM components in your .NET app then you won't need the interop libraries.
What's the problem with deploying a few DLLs with your EXE anyway? Is it really so hard to move four files around rather than one? You've heard of ZIP files, right? People use them all the time. If you want one file, that's how you do it. You can even make a self-extracting ZIP file if you want.
To answer your specific question, no you cannot "register" those DLLs. There's nothing to register. Onlu COM components need to be registered and those are not COM components. Chalk one up for .NET: no registration, no DLL hell.
So where do microsfot look for dll?
In the same folder with exe
then where else?
By the way I managed to rate the guy. The first time I tried the rate this post button don't show up. I can't rate jmcilhinney as usual because he helped me too many times and I was told to spread some love first :)
It's going to look in two places... first place is the folder where the exe is... the second place is the GAC, the Global Assembly Cache.... BUT... it's not the kind of appropriate place for the files you are looking at. What's the aversion to copying 4 files instead of 1?
-tg
As tg says, you can install common components in the GAC. You'd still need to put them there in the first place though, plus you'd need to sign the assemblies, which is not trivial for Interop libraries. All this energy to avoid copying a few files?
Well, because if I copy a few files I may miss some of the files
I think before we have registration or something. We register a dll and then microsoft know, oh the location of that dll is somewhere.
Okay, merge exe and dll seems like a good idea. Any free program to do so? Is this something vb.net can do?
Size of the file doesn't really matter if I think about it.
I suggest that you give up software development right now if you really think that's a problem. Who's to say that you won't forget a file when you merge the EXE and the DLLs? What's the difference?Quote:
Originally Posted by teguh123
if the dll file is in your bin/release directory.... copy it... it's that simple. Other than the framework, which should already be on your target machines, that's all you need to do. I deploy an app that has 30+ dlls and supporting files... never missed one yet. (side note, you can skip any of the *.vshost.* files).... and also don't forget to copy your .config file. Truly, it is that simple.
-tg
Files like Interop.WinHttp.dll
Is that part of the frame work?
Oh hell it does. So I don't have to copy dll along. The other computer seems to know where to find interop.winhttp.dll somehow. Yap just copying the .exe is fine. Somehow even though the .dll is not in the .exe directory, the computer knows where to find it anyway.
How can the computer do that? Registry.
You might try reading what's already been posted, like post #6.Quote:
Originally Posted by teguh123
Yea you're right. The program still ask for dll.
However, I've heard that the proper place of all dll files are in system32 directories. That sort of thing. Also I think I've heard that windows will find dll files outside the .exe files. Somewhere.
Go to your root drive and look in the program folders installed on your computer (c:/program files/...) , you will find lots of dll files. I think what you "heard" is not true.Quote:
Originally Posted by teguh123
Hmmm....
Okay okay okay. I am a noob here. Good rep for everyone.
Actually I found a way to do it. I run iexpress.exe
Works perfectly with one small flaw
If I run the .exe files in c:\work I want the working directory to be c:\work
Well, the working directory is some temp directory which seems to be the place where the files are extracted. How do I change that? How do I make iexpress.exe to set the working directory to be the directory it's called.
You guys said we cannot register DLL.
Then what's this?
http://support.microsoft.com/kb/249873
That article is about registering COM components. Interop DLLs are not COM components, therefore they don't get registered.Quote:
Originally Posted by teguh123
Even if that weren't the case, what good would it do? It seems like your aim is to be able to deploy just the EXE file. How does being able to register an Interop DLL help you do that? Even if you register it on one machine, that doesn't magically register it on every other machine. If you wanted to run the EXE on another machine you'd have to register the DLL(s) on that machine too.
that iexpress.exe solution is almost perfect. if only I can specify the working directories of the file it'll be great. Anyone knows how I can do that?
The way it works is if I run combined.exe from c:\work I want the working directory (curdir) to be c:\work
WHat happened is combined.exe will get extracted to c:\sometempdirectory and then will run the program from there. So the working directory ended up to be c:\sometempdirectory which is not what I want.