Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Interop / June 2004

Tip: Looking for answers? Try searching our database.

Binary compatability?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Kai Hietala - 31 May 2004 06:51 GMT
Hi,

I've made a C# dll that I'm accessing with VB6 clients. My problem is
that when I make changes to the C# dll the clients stop working. This
makes bug fixes quite an ordeal.

I've read that for versioning purposes it is best to make a separate
interface that is exposed to the COM world. Comments about this approach
are also welcome.

--------------------------------------------------------------
[Guid("<My GUID from the tool>")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface IClass_A
{
    [DispId(1)]
    string EchoString(string a);
}

[ClassInterface(ClassInterfaceType.None)]
public class Class_A : IClass_A
{
    public string EchoString(string a)
    {
        return a;
    }
}
--------------------------------------------------------------

When I recompile my project the clients lose their reference to the dll.
In VB I have the project option to make binary compatibable compilations
so how do I do it in .Net world?

I guess I have to give a GUID to the type library but I haven't found
any samples of this. Can anyone shed some light into this?

Cheers,

    Kai Hietala
Mattias Sj?gren - 01 Jun 2004 08:38 GMT
Kai,

>I guess I have to give a GUID to the type library but I haven't found
>any samples of this. Can anyone shed some light into this?

You use the Guid attribute at the assembly level:

[assembly: Guid("Your LIBID here")]

Mattias

Signature

Mattias Sjögren [MVP]  mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Phil Wilson - 02 Jun 2004 00:16 GMT
It also wouldn't hurt to have an explicit assembly version just in case it's
the default of 1.0.*, otherwise your clients won't find your recompiled
version because it will change at every build.
Signature

Phil Wilson [MVP Windows Installer]
----

> Kai,
>
[quoted text clipped - 6 lines]
>
> Mattias
Kai Hietala - 02 Jun 2004 06:30 GMT
Mattias and Phil, thank you. I had completely forgotten the assembly
directives. It seems that the version really has to be explicitly stated
e.g. 1.0.0.0. I tried 1.0.0.* but it didn't seem to work.

Cheers,

    Kai Hietala

> It also wouldn't hurt to have an explicit assembly version just in case it's
> the default of 1.0.*, otherwise your clients won't find your recompiled
> version because it will change at every build.
Sascha Fueller - 04 Jun 2004 07:23 GMT
Have you tried to apply a Guid to your class as you did it wiht the
interface ?

It is also possible to have different versions visible to .NET and COM:
---
[assembly: AssemblyVersion("1.0.1.0")]
[assembly: ComCompatibleVersion(1,0,0,0)]
---

Sascha

> Mattias and Phil, thank you. I had completely forgotten the assembly
> directives. It seems that the version really has to be explicitly stated
[quoted text clipped - 7 lines]
> > the default of 1.0.*, otherwise your clients won't find your recompiled
> > version because it will change at every build.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.