|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Help with Binary CompatibilityI have a DLL project that was compiled in December 2008. At that time a copy of the DLL was put into a "Reference Build" folder and binary compatibility was set in the project properties "components" tab. I needed to make a change that did not effect any publicly exposed methods or properties (changed a connection string). After making the change and compiling I am being told that all of the publicly exposed methods/properties have changed and prompts to break compatibility. However, the original and current definitions are identical. For example: Original definition: Property Get ID() As Long Current definition: Property Get ID() As Long I've been using binary compatibility for ages without any problems. Have I suddenly lost my mind (rhetorical question) or is there a logical explanation for what I'm experiencing? -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> wrote in message Maybe the compatibility copy is missing, or Read&Execute security was news:%23fBG8hApJHA.3876@TK2MSFTNGP02.phx.gbl... > Visual Basic 6 SP 5 > > I have a DLL project that was compiled in December 2008. At that time a > copy of the DLL was put into a "Reference Build" folder and binary > compatibility was set in the project properties "components" tab. I > needed to make a change that did not effect any publicly exposed methods > or properties (changed a connection string). After making the change and > compiling I am being told that all of the publicly exposed > methods/properties have changed and prompts to break compatibility. > However, the original and current definitions are identical. For example: > > Original definition: > Property Get ID() As Long > > Current definition: > Property Get ID() As Long > > I've been using binary compatibility for ages without any problems. Have > I suddenly lost my mind (rhetorical question) or is there a logical > explanation for what I'm experiencing? removed.
Show quote
Hide quote
"Nobody" <nob***@nobody.com> wrote in message I know the compatibility copy is there. I guess I can check the security news:uF77c0BpJHA.500@TK2MSFTNGP06.phx.gbl... > "Al Reid" <arei***@reidDASHhome.com> wrote in message > news:%23fBG8hApJHA.3876@TK2MSFTNGP02.phx.gbl... >> Visual Basic 6 SP 5 >> >> I have a DLL project that was compiled in December 2008. At that time a >> copy of the DLL was put into a "Reference Build" folder and binary >> compatibility was set in the project properties "components" tab. I >> needed to make a change that did not effect any publicly exposed methods >> or properties (changed a connection string). After making the change and >> compiling I am being told that all of the publicly exposed >> methods/properties have changed and prompts to break compatibility. >> However, the original and current definitions are identical. For >> example: >> >> Original definition: >> Property Get ID() As Long >> >> Current definition: >> Property Get ID() As Long >> >> I've been using binary compatibility for ages without any problems. Have >> I suddenly lost my mind (rhetorical question) or is there a logical >> explanation for what I'm experiencing? > > Maybe the compatibility copy is missing, or Read&Execute security was > removed. > settings on it as well. It really looks like it's finding it, but somehow it's confused. -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> wrote in message Anyone have any ideas or suggestions. I let it break compatibility and news:%23fBG8hApJHA.3876@TK2MSFTNGP02.phx.gbl... > Visual Basic 6 SP 5 > > I have a DLL project that was compiled in December 2008. At that time a > copy of the DLL was put into a "Reference Build" folder and binary > compatibility was set in the project properties "components" tab. I > needed to make a change that did not effect any publicly exposed methods > or properties (changed a connection string). After making the change and > compiling I am being told that all of the publicly exposed > methods/properties have changed and prompts to break compatibility. > However, the original and current definitions are identical. For example: > > Original definition: > Property Get ID() As Long > > Current definition: > Property Get ID() As Long > > I've been using binary compatibility for ages without any problems. Have > I suddenly lost my mind (rhetorical question) or is there a logical > explanation for what I'm experiencing? > -- > Al Reid > copied the newly compiled DLL as the reference DLL and still have the same problem. -- Al Reid > Anyone have any ideas or suggestions. I let it break compatibility and Just grabbing at straws here (so beware that I might> copied the newly compiled DLL as the reference DLL and still have the same > problem. > waste your time :), but I'd try making sure that the two class files have the functions in the same order. Or maybe try changing "ID", first, if that's actually the name of the property. VB does weird things when keywords are used as variables, but telling you that you can't use the word doesn't seem to be one of them. If ID is not a keyword then maybe it might be used somewhere in a referenced tlb or control?
Show quote
Hide quote
"mayayana" <mayayaX***@rcXXn.com> wrote in message Straws are better than nothing.news:Ocv4T$jpJHA.5980@TK2MSFTNGP06.phx.gbl... >> Anyone have any ideas or suggestions. I let it break compatibility and >> copied the newly compiled DLL as the reference DLL and still have the >> same >> problem. >> > > Just grabbing at straws here (so beware that I might > waste your time :), but I'd try making sure that the two > class files have the functions in the same order. > Or maybe try changing "ID", first, if that's > actually the name of the property. VB does weird > things when keywords are used as variables, but telling > you that you can't use the word doesn't seem to be > one of them. If ID is not a keyword then maybe it > might be used somewhere in a referenced tlb or control? > ID is not a reserved word and shouldn't cause a problem. The customer has been using the DLL since late 2005 and the binary compatibility has never been an issue before. Suddenly it tells me that every public method/property will break compatibility, even though the signatures are identical. Here's another example where VB claims there is a mismatch: Original definition: Property Get Item(InvID As String) As APInvoiceImageDll.Invoice Current definition: Property Get Item(InvID As String) As APInvoiceImageDll.Invoice They sure look the same to me. -- Al Reid "Al Reid" <arei***@reidDASHhome.com> schrieb im Newsbeitrag Just the "naming" of your method-Defs is only one thing.news:%23G8hTZkpJHA.4516@TK2MSFTNGP02.phx.gbl... > Here's another example where VB claims there is a mismatch: > > Original definition: > Property Get Item(InvID As String) As APInvoiceImageDll.Invoice > > Current definition: > Property Get Item(InvID As String) As APInvoiceImageDll.Invoice Also important is the order of your Public Interface- Members, which should remain exactly the same. And last but not least you'll have to make sure, that the enhanced Procedure-Attributes (Default-Procedure, Hidden-Attributes, or these magical -4 Attributes for Enumeration-members) are all the same. You can mess up these attributes very fast, e.g. if you've done a Copy'nPaste or something like that. So please take a look at your original Source-Code for the *.cls, where these Member-Attributes are contained (at the File-Level, not inside the VB-IDE-Editor). Olaf
Show quote
Hide quote
"Schmidt" <s**@online.de> wrote in message Thanks for the suggestions, Olaf.news:ueQ5wotpJHA.4540@TK2MSFTNGP04.phx.gbl... > > "Al Reid" <arei***@reidDASHhome.com> schrieb im Newsbeitrag > news:%23G8hTZkpJHA.4516@TK2MSFTNGP02.phx.gbl... > >> Here's another example where VB claims there is a mismatch: >> >> Original definition: >> Property Get Item(InvID As String) As APInvoiceImageDll.Invoice >> >> Current definition: >> Property Get Item(InvID As String) As APInvoiceImageDll.Invoice > > Just the "naming" of your method-Defs is only one thing. > Also important is the order of your Public Interface- > Members, which should remain exactly the same. > > And last but not least you'll have to make sure, that the > enhanced Procedure-Attributes (Default-Procedure, > Hidden-Attributes, or these magical -4 Attributes for > Enumeration-members) are all the same. > > You can mess up these attributes very fast, e.g. if you've > done a Copy'nPaste or something like that. > > So please take a look at your original Source-Code for > the *.cls, where these Member-Attributes are contained > (at the File-Level, not inside the VB-IDE-Editor). > > Olaf > The naming has not changed for 4 years and this is the first time I've encountered this problem. The order has not changed either. The DLL still functions as expected after recompiling and allowing it to break compatibility. Using the new DLL as the reference copy still results in the error on each publicly exposed method/property. I extracted the type lib from the DLL and reference copy and they are identical. I'm about to take Nobody's advice and rename the DLLs and run Regclean and see what happens. -- Al Reid -- Al Reid "Al Reid" <arei***@reidDASHhome.com> schrieb im Newsbeitrag Oh, must have missed that - did you changed the endingnews:OgTtO$upJHA.5832@TK2MSFTNGP06.phx.gbl... > Using the new DLL as the reference copy still results in the > error on each publicly exposed method/property. of your BinComp-reference from *.dll to something other? > I'm about to take Nobody's advice and rename the DLLs Olaf> and run Regclean and see what happens. Good idea. "Al Reid" <arei***@reidDASHhome.com> wrote in message One last suggestion, close the IDE, and delete the files in the Temp folder.news:OgTtO$upJHA.5832@TK2MSFTNGP06.phx.gbl... > I'm about to take Nobody's advice and rename the DLLs and run Regclean and > see what happens. One theory is that you are using a reference or type library in your
project, and using some of the types in them, but you are now using a new reference/typelib(not the same copy, not binary compatible). Also use WinMerge to see what changes were made between 2 projects, whether
by you or VB: http://en.wikipedia.org/wiki/WinMerge http://winmerge.org http://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools "Nobody" <nob***@nobody.com> wrote in message The only reference in the project is to Microsoft ActiveX Data Objects 2.7 news:uhfAOHlpJHA.5360@TK2MSFTNGP03.phx.gbl... > One theory is that you are using a reference or type library in your > project, and using some of the types in them, but you are now using a new > reference/typelib(not the same copy, not binary compatible). > Library and that has not changed. How does that mesh with the theory? This is frustrating! -- Al Reid "Al Reid" <arei***@reidDASHhome.com> wrote in message Use some typeinfo tool to dump out all the interfaces into a text file for news:OTDPSPlpJHA.5832@TK2MSFTNGP06.phx.gbl... > "Nobody" <nob***@nobody.com> wrote in message > news:uhfAOHlpJHA.5360@TK2MSFTNGP03.phx.gbl... >> One theory is that you are using a reference or type library in your >> project, and using some of the types in them, but you are now using a new >> reference/typelib(not the same copy, not binary compatible). >> > > The only reference in the project is to Microsoft ActiveX Data Objects 2.7 > Library and that has not changed. How does that mesh with the theory? > > This is frustrating! both DLL's, then compare the result. Another thing to check if you changed the project type temporarily to Standard EXE, or have the source files shared with another project, VB could set the Instancing property to Private, and this would break compatibility. WinMerge would detect this if you have the working version source code. SAMPLE: CLSNMMBR.EXE Programmatically Retrieves the Members of a DLL Class http://support.microsoft.com/kb/172988 FILE: Tlbinf32.exe : Help Files for Tlbinf32.dll http://support.microsoft.com/default.aspx?scid=kb;en-us;224331
Show quote
Hide quote
"Nobody" <nob***@nobody.com> wrote in message Ok, I used a tool to extract the type library from both the DLL and the news:u0vNjqlpJHA.3896@TK2MSFTNGP04.phx.gbl... > "Al Reid" <arei***@reidDASHhome.com> wrote in message > news:OTDPSPlpJHA.5832@TK2MSFTNGP06.phx.gbl... >> "Nobody" <nob***@nobody.com> wrote in message >> news:uhfAOHlpJHA.5360@TK2MSFTNGP03.phx.gbl... >>> One theory is that you are using a reference or type library in your >>> project, and using some of the types in them, but you are now using a >>> new reference/typelib(not the same copy, not binary compatible). >>> >> >> The only reference in the project is to Microsoft ActiveX Data Objects >> 2.7 Library and that has not changed. How does that mesh with the >> theory? >> >> This is frustrating! > > Use some typeinfo tool to dump out all the interfaces into a text file for > both DLL's, then compare the result. > > Another thing to check if you changed the project type temporarily to > Standard EXE, or have the source files shared with another project, VB > could set the Instancing property to Private, and this would break > compatibility. WinMerge would detect this if you have the working version > source code. > > SAMPLE: CLSNMMBR.EXE Programmatically Retrieves the Members of a DLL Class > http://support.microsoft.com/kb/172988 > > FILE: Tlbinf32.exe : Help Files for Tlbinf32.dll > http://support.microsoft.com/default.aspx?scid=kb;en-us;224331 > reference copy, pasted the info into text files and used WinDiff to compare them. The result is that they are identical, which I was already 99.9% sure they were. VB is telling me that the definitions are different, but then shows me that they are the same. Any more ideas? Please... -- Al Reid "Al Reid" <arei***@reidDASHhome.com> wrote in message Rename both DLL's, run a registry cleaner which will delete ActiveX entries news:eth7j6lpJHA.4372@TK2MSFTNGP02.phx.gbl... > Ok, I used a tool to extract the type library from both the DLL and the > reference copy, pasted the info into text files and used WinDiff to > compare them. The result is that they are identical, which I was already > 99.9% sure they were. > > VB is telling me that the definitions are different, but then shows me > that they are the same. > > Any more ideas? Please... since the files are "missing". Rename back and register the binary compatible copy. Here is one such free registry cleaning tool, download the "Slim" or "Portable" version because the standard version is the same, but includes a toolbar(Yahoo or Google) http://www.ccleaner.com/download/builds http://en.wikipedia.org/wiki/CCleaner
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> wrote in message Well here's an update on my progress with this issue. I'm now looking for a news:%23fBG8hApJHA.3876@TK2MSFTNGP02.phx.gbl... > Visual Basic 6 SP 5 > > I have a DLL project that was compiled in December 2008. At that time a > copy of the DLL was put into a "Reference Build" folder and binary > compatibility was set in the project properties "components" tab. I > needed to make a change that did not effect any publicly exposed methods > or properties (changed a connection string). After making the change and > compiling I am being told that all of the publicly exposed > methods/properties have changed and prompts to break compatibility. > However, the original and current definitions are identical. For example: > > Original definition: > Property Get ID() As Long > > Current definition: > Property Get ID() As Long > > I've been using binary compatibility for ages without any problems. Have > I suddenly lost my mind (rhetorical question) or is there a logical > explanation for what I'm experiencing? > -- > Al Reid > tall building to jump from. I unregistered the DLL and, with a combination or RegClean and manual removal, removed all remnants of the registry entries from my machine. I then recompiled the DLL without any compatibility, copied the DLL to the reference folder and re-enabled binary compatibility. I attempted to recompile and I am nor right back where I started from. All publicly exposed methods indicate a mismatch while simultaneously showing me that they are identical. Anyone have a net to catch me when I jump? -- Al Reid It seems that I have resolved the issue, but why? The first incompatibility
that was reported was: > Original definition: This property had a> Property Get ID() As Long > > Current definition: > Property Get ID() As Long > Friend Property Let ID (vData as Long) I changed it to Public Property Let ID (vData as Long) and it let me compile against the version compatible reference build. I then changed it back to a Friend Property and was again able to compile successfully. This makes absolutely no sense to me whatsoever. I just hope it doesn't jump up and bite me again at some point. Thanks to those that offered suggestions. -- Al Reid
Show quote
Hide quote
"Al Reid" <arei***@reidDASHhome.com> wrote in message It makes sense to me. "Friend" is as good as private, except other modules news:OK6QTvypJHA.504@TK2MSFTNGP06.phx.gbl... > It seems that I have resolved the issue, but why? The first > incompatibility that was reported was: > >> Original definition: >> Property Get ID() As Long >> >> Current definition: >> Property Get ID() As Long >> > > This property had a > > Friend Property Let ID (vData as Long) > > I changed it to > > Public Property Let ID (vData as Long) > > and it let me compile against the version compatible reference build. I > then changed it back to a Friend Property and was again able to compile > successfully. This makes absolutely no sense to me whatsoever. I just > hope it doesn't jump up and bite me again at some point. in the project can see it. You have "Friend" in the original binary compatible version, so when you changed it to "public", it's compatible, because you are adding something(You can't remove existing features), but when you changed it back, it's still compatible because you didn't replace the binary compatible file, so in the second case, you have "Friend" in the modified version, and "Friend" in the binary compatible version, so nothing changed in the public interface as far as VB is concerned. Here is how VB sees it: (BinCompVer) (NewVer) (Status) Friend Public OK Friend Friend OK
Show quote
Hide quote
"Nobody" <nob***@nobody.com> wrote in message Ok, that makes sense in terms of changes to the interface, but why the news:O5R0AjzpJHA.1252@TK2MSFTNGP03.phx.gbl... > "Al Reid" <arei***@reidDASHhome.com> wrote in message > news:OK6QTvypJHA.504@TK2MSFTNGP06.phx.gbl... >> It seems that I have resolved the issue, but why? The first >> incompatibility that was reported was: >> >>> Original definition: >>> Property Get ID() As Long >>> >>> Current definition: >>> Property Get ID() As Long >>> >> >> This property had a >> >> Friend Property Let ID (vData as Long) >> >> I changed it to >> >> Public Property Let ID (vData as Long) >> >> and it let me compile against the version compatible reference build. I >> then changed it back to a Friend Property and was again able to compile >> successfully. This makes absolutely no sense to me whatsoever. I just >> hope it doesn't jump up and bite me again at some point. > > It makes sense to me. "Friend" is as good as private, except other modules > in the project can see it. You have "Friend" in the original binary > compatible version, so when you changed it to "public", it's compatible, > because you are adding something(You can't remove existing features), but > when you changed it back, it's still compatible because you didn't replace > the binary compatible file, so in the second case, you have "Friend" in > the modified version, and "Friend" in the binary compatible version, so > nothing changed in the public interface as far as VB is concerned. Here is > how VB sees it: > > (BinCompVer) (NewVer) (Status) > Friend Public OK > Friend Friend OK > original problem, where both the current DLL and the Reference DLL are the same build? That makes absolutely no sense to me at all. I've been using binary compatibility with VB6 for 8 or 9 years and never saw anything like it before. -- Al Reid I had the same problem in an ActiveX UserControl and I think it's a VB bug.
After a compilation and setting binary compatibility, if you changed the interface adding something, you didn't break the compatibility, but it seems that VB generates another type library when the program runs on IDE and the Friend properties are not recognized any more. The problem occurs in the IDE, not compiled. Show quoteHide quote "Al Reid" <arei***@reidDASHhome.com> escribió en el mensaje news:OK6QTvypJHA.504@TK2MSFTNGP06.phx.gbl... > It seems that I have resolved the issue, but why? The first > incompatibility that was reported was: > >> Original definition: >> Property Get ID() As Long >> >> Current definition: >> Property Get ID() As Long >> > > This property had a > > Friend Property Let ID (vData as Long) > > I changed it to > > Public Property Let ID (vData as Long) > > and it let me compile against the version compatible reference build. I > then changed it back to a Friend Property and was again able to compile > successfully. This makes absolutely no sense to me whatsoever. I just > hope it doesn't jump up and bite me again at some point. > > Thanks to those that offered suggestions. > > -- > Al Reid > >  
Other interesting topics
Fonts
(OT) false positives on my files Copying array elements Can I loop through only SELECTED items in a multi-select FileListBox? converting from basic to vb6 Should I distribute Winsock? Convert statements from VB 2008 to 2003? Where to store database login information in VB6 Visual Basic Express 2008 Custom Error Message Dynamic function calls |
|||||||||||||||||||||||
