Actually VB.NET only increments an AssemblyVersionAttribute ("1.0.*")
the first compile after loading Visual Studio. Repeating compiles during
the same Visual Studio session do not subsequently change the version,
unlike C# compiles. To get the version to change in a VB.NET
application, you must exit Visual Studio and reload.I couldn't believe this behavior when I heard it but I tested it and that's how it works. -- Brent Rector, .NET Wise Owl Demeanor for .NET - an obfuscation utility http://www.wiseowl.com/Products/Products.aspx -----Original Message----- From: Adam Nathan [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:37 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6 Right, recompiling with no changes does not change the auto-generated GUIDs. Note that auto-generated LIBIDs and CLSIDs are based off of the assembly's version number, and by default, Visual Studio .NET projects are marked with a version of "1.0.*" (inside AssemblyVersionAttribute). This will cause your GUIDs to change on re-compile unless you change it to be a fixed version. Adam -----Original Message----- From: Brent E. Rector [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 10:57 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] COM Interop calling a C# DLL from VB6 The best technique is setting the GUID/IID/CLSID's using the GuidAttribute. However, a recompile with no changes does not cause the guids to change. In fact, I just tested that to make sure the docs were correct. I recompiled your code below numerous times without making any changes to the source and the generated GUIDs were always the same. -- Brent Rector, .NET Wise Owl Demeanor for .NET - an obfuscation utility http://www.wiseowl.com/Products/Products.aspx You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
