gnagabandi
asked on
VB COM compiling Issue
Why in earth do you have to compile a VB dll twice? And why the first compile is always no compatibility?
ASKER
Hi Crin,
You are right. But my question is Why we need to first compile with no compatability. What is the logic behind that?
Thanks,
Gang.
You are right. But my question is Why we need to first compile with no compatability. What is the logic behind that?
Thanks,
Gang.
I created a number of ActiveX dlls and EXEs and always used 'Project compatibility' option... Never had problems VB restrict me to select this option, do you have?
I'm sorry, english is not my native language... please describe your situation and why you compile your dll twice?
Sincerely yours,
Crin
I'm sorry, english is not my native language... please describe your situation and why you compile your dll twice?
Sincerely yours,
Crin
You don't have to compile twice. Compile ones. After that, set compatibility OF YOUR PROJECT to whatever you want.
Related links:
http://www.vb2themax.com/Item.asp?PageID=TipBank&ID=290
http://www.comdeveloper.com/articles/binarycomp.asp
Related links:
http://www.vb2themax.com/Item.asp?PageID=TipBank&ID=290
http://www.comdeveloper.com/articles/binarycomp.asp
You have to compile twice.
The first time you compile set 'No compatiblity', compile and copy your DLL to a directory like for instance CompDlls
Then set Project Compatibility or Binary Compatability and reference your first compiled DLL in CompDlls. Then compile and make sure your new DLL is NOT in CompDlls. Then compile again and again .......
This has to do with VB not cluttering up your registry with GUID's, UUID's etc. every time you compile
There is a good article on the subject in MSDN:
Building, Versioning, and Maintaining Visual Basic Components
The first time you compile set 'No compatiblity', compile and copy your DLL to a directory like for instance CompDlls
Then set Project Compatibility or Binary Compatability and reference your first compiled DLL in CompDlls. Then compile and make sure your new DLL is NOT in CompDlls. Then compile again and again .......
This has to do with VB not cluttering up your registry with GUID's, UUID's etc. every time you compile
There is a good article on the subject in MSDN:
Building, Versioning, and Maintaining Visual Basic Components
corvanderlinden,
You only need to compile your Dll once to use it.
Only if you want to recompile your dll at a later stage (ie after an update) do you need to make the copy and set the compatability.
Gordon
You only need to compile your Dll once to use it.
Only if you want to recompile your dll at a later stage (ie after an update) do you need to make the copy and set the compatability.
Gordon
And your first ever compile has to be with no compatability because there nothing for it to be compatable with.
gnagabandi,
Seems Gordonp phrases describes your problem very well. The only thing if compiler prohibit you to set 'Compatibility' option while first compiling. In fact sentence "And your first ever compile has to be with no compatability because there nothing for it to be compatable with." is the answer, I suppose :))
Sincerely yours,
Crin
Seems Gordonp phrases describes your problem very well. The only thing if compiler prohibit you to set 'Compatibility' option while first compiling. In fact sentence "And your first ever compile has to be with no compatability because there nothing for it to be compatable with." is the answer, I suppose :))
Sincerely yours,
Crin
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
corvanderlinden,
I always follow your method only. But my question is why can't we create Binary Compatable Dll first time itself (I mean without No compatable).
I always follow your method only. But my question is why can't we create Binary Compatable Dll first time itself (I mean without No compatable).
Binary Compatability cannot be set the first time because you first have to have a DLL to be compatable with. Binary Comp. means that the compiler checks the interfaces of the new DLL against the interfaces of the 'old' DLL (the one you specify in the components tab of Project properties).
If the interfaces change compatiblity is broken and the compiler has to assign new GUID's etc.
In a way the first DLL you compile (with No Comp.) is a blueprint for every new compile of your DLL.
(it is hard to describe in a few words but I hope this clarifies it a little)
If the interfaces change compatiblity is broken and the compiler has to assign new GUID's etc.
In a way the first DLL you compile (with No Comp.) is a blueprint for every new compile of your DLL.
(it is hard to describe in a few words but I hope this clarifies it a little)
As I understood, you mean that every compilation changes CLASSID for objects provided by your DLL, right?
Sincerely yours,
Crin