Compiled Dll's Exe's and references 
Author Message
 Compiled Dll's Exe's and references

Hi,
       I'm confused and in need of some enlightenment, or perhaps, whiskey!
Anyways, I currently believe that when I'm working on a project Group (.vbp)
with one project being a dll and the other being an exe that once the dll is
compiled that the reference for that .dll in the .exe should be changed to
the location of the compiled .dll (say Windows\System) BEFORE the .exe is
compiled.
Question #1 is this right or wrong?
I currently believe the .dll HAS to be registered before the .exe can access
it.
Question #2 Doesn't the .exe *ask* the registry where the dll is? If this is
true then I should be able to put the dll in any file or directory
regardless of where it is referenced in the exe(vbp) but experimentation has
proven otherwise.
Question #3 If I make changes to said .dll and make it Binary Compatible to
the previous version can I simply "switch out" the dll's or do I have to
unregister the old and register the new and (hopefully) NOT recompile the
.exe?
Question #4 Why oh why are the runtime files (oleaut32, etc) that are in
Windows/System on 98/ME machines placed in Windows/System32 on NT/XP
machines?
Thanks for any assistance,
                                      Scott


Sat, 25 Sep 2004 11:42:03 GMT  
 Compiled Dll's Exe's and references

--
--

Quote:
> Hi,
>        I'm confused and in need of some enlightenment, or perhaps,
whiskey!
> Anyways, I currently believe that when I'm working on a project Group
(.vbp)
> with one project being a dll and the other being an exe that once the dll
is
> compiled that the reference for that .dll in the .exe should be changed to
> the location of the compiled .dll (say Windows\System) BEFORE the .exe is
> compiled.
> Question #1 is this right or wrong?

If you're making a DLL in VB it's an ActiveX DLL called through
CreateObject.
You don't need the path, just the ProgID, which is probably
DLLName.DLLClassName

Quote:
> I currently believe the .dll HAS to be registered before the .exe can
access
> it.
> Question #2 Doesn't the .exe *ask* the registry where the dll is? If this
is
> true then I should be able to put the dll in any file or directory
> regardless of where it is referenced in the exe(vbp) but experimentation
has
> proven otherwise.

   VB registers it without asking and uses the project folder as path. You
can confirm that by looking it up under HKCR\CLSID key. Since the object
is identified through that key it won't be found unless it's at the path
listed there.
   HKCR\DLLName.ClassName will list the DLL's GUID.
  HKCR\CLSID\[GUID] will show the path.

Quote:
> Question #3 If I make changes to said .dll and make it Binary Compatible
to
> the previous version can I simply "switch out" the dll's or do I have to
> unregister the old and register the new and (hopefully) NOT recompile the
> .exe?

I think that's true but if you set binary compatibility you should make sure
that the interface is backward compatible. (i.e. don't change arguments
in existing functions).

Quote:
> Question #4 Why oh why are the runtime files (oleaut32, etc) that are in
> Windows/System on 98/ME machines placed in Windows/System32 on NT/XP
> machines?

It's still %System%
Quote:
> Thanks for any assistance,
>                                       Scott



Sat, 25 Sep 2004 14:17:17 GMT  
 Compiled Dll's Exe's and references
Just to confuse matters, sometimes DLLs 'self register'

This is AFAIK an undocumented 'feature' and it would be unwise to rely
on it.

On Tue, 9 Apr 2002 02:17:17 -0400, "mayayana"

Quote:

>--
>--


>> Hi,
>>        I'm confused and in need of some enlightenment, or perhaps,
>whiskey!
>> Anyways, I currently believe that when I'm working on a project Group
>(.vbp)
>> with one project being a dll and the other being an exe that once the dll
>is
>> compiled that the reference for that .dll in the .exe should be changed to
>> the location of the compiled .dll (say Windows\System) BEFORE the .exe is
>> compiled.
>> Question #1 is this right or wrong?

>If you're making a DLL in VB it's an ActiveX DLL called through
>CreateObject.
>You don't need the path, just the ProgID, which is probably
>DLLName.DLLClassName

>> I currently believe the .dll HAS to be registered before the .exe can
>access
>> it.
>> Question #2 Doesn't the .exe *ask* the registry where the dll is? If this
>is
>> true then I should be able to put the dll in any file or directory
>> regardless of where it is referenced in the exe(vbp) but experimentation
>has
>> proven otherwise.

>   VB registers it without asking and uses the project folder as path. You
>can confirm that by looking it up under HKCR\CLSID key. Since the object
>is identified through that key it won't be found unless it's at the path
>listed there.
>   HKCR\DLLName.ClassName will list the DLL's GUID.
>  HKCR\CLSID\[GUID] will show the path.

>> Question #3 If I make changes to said .dll and make it Binary Compatible
>to
>> the previous version can I simply "switch out" the dll's or do I have to
>> unregister the old and register the new and (hopefully) NOT recompile the
>> .exe?

>I think that's true but if you set binary compatibility you should make sure
>that the interface is backward compatible. (i.e. don't change arguments
>in existing functions).

>> Question #4 Why oh why are the runtime files (oleaut32, etc) that are in
>> Windows/System on 98/ME machines placed in Windows/System32 on NT/XP
>> machines?

>It's still %System%

>> Thanks for any assistance,
>>                                       Scott



Sat, 25 Sep 2004 16:57:22 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Can't compile EXE or DLL

2. Compiled vb exe's won't run

3. Extracting Icons from Exe's Dll's Ico's into a ListImage Control

4. Help:Using VB Funtions In Access With DLL's, EXE's

5. Help:Using VB Funtions In Access With DLL's, EXE's

6. Including dll's and ocx's in VB exe file

7. Help:Using VB Funtions In Access With DLL's, EXE's

8. Visual Basic 5.0 .EXE's and the various DLL's it needs

9. EXE's Vs DLL's Naming Problem

10. ActiveX dll's and EXE's

11. Licensing for ActiveX DLL's and EXE's

12. Visual Basic 5.0 .EXE's and the various DLL's it needs

 

 
Powered by phpBB® Forum Software