a bit late, but I just wanted to say Thanks for the help.
It was exactly what i was looking for.
Cheers!
dave
----- Original Message -----
From: "J. Merrill" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 9:22 AM
Subject: Re: [ADVANCED-DOTNET] checking for COM
> A solution that won't require your .NET clients to do things differently
than you've planned would be to provide your COM clients with a separate
LicenseLoader COM class. They will instantiate an instance of that class
(without any parameters because COM can't pass them), then call one of its
LoadLicenseXxx methods. Those methods should be declared to return a value
of type IMyComponent, an interface that matches the interface of MyComponent
(which you'll need to create). (You do that because it's a bit easier for a
COM caller to use an Interface result than a .NET object, because COM is
interface-based.) Those LoadLicenseXxx methods will each call the
appropriate static MyComponent.LoadLicenseXxx method; if it fails
(presumably an exception is raised), return Null; otherwise return the
result of casting the result of "new MyComponent()" to an IMyComponent
interface. Those routines then become the equivalent of the default
constructor the .NET clients use.
>
> If you want to do more work for your COM clients (and you should if the
inability to use your non-default constructors reduces the functionality
they get), you can have variants of the LicenseLoader methods that accept
other parameters and end up (when the license key gets loaded correctly)
returning an IMyComponent that was constructed using one of the non-default
constructors. You don't want to use overloading (routines with the same
name) for those, because COM users see them as being different names that
are distinguished by 2, 3, 4 etc at the end. You'd give them names that
match the kind of parameters they take. You could even name the "normal"
ones (the ones that return a default-constructed MyComponent) something
other than LoadLicenseXxx, if you want.
>
> I haven't built anything like this myself, or necessarily thought it
through all the way, but this seems to me to be a good way to do it. It
will feel natural to your COM users, and your .NET users won't see anything
in your API that makes it "smell like" it's been polluted with support for
COM.
>
> (Also, don't forget to define the assembly that defines your LicenseLoader
class as being a Primary Interop Assembly.) Good luck...
>
> At 05:30 PM 6/9/2004, dave wanta wrote
> >Hi,
> >Thanks for the great feedback.
> >
> >
> >well, the issue is licensing.
> >
> >I was using some static methods to set licenses like:
> >
> >MyComponent.LoadLicenseKey( string key );
> >or
> >MyComponent.LoadLicenseFile( string path );
> >
> >to globally load the license file.
> >
> >Then, if they didn't load the license (before component initialization)I
> >could throw an exception when they call
> >
> >MyComponent mc = new MyComponent();
> >
> >
> >
> >and becasue I have multiple ctors (with parameters), internally, I would
> >always call
> >
> >MyComponent( [some parameters here] ) :this()
> >{
> > //code here
> >}
> >
> >where the 'default' ctor looks like:
> >
> >MyComponent()
> >{
> > //do license check
> > if( licenseFailed )
> > throw new LicenseException( "you can initizlie the license by
> >calling MyComponent.LoadLicense()" ); //or any other helpful information
> >
> > //initialize some stuff
> >}
> >
> >
> >I didn't want to do a license check from all the methods (or a subset of
> >them), so I was keeping it nice and simple in the default ctor, but then
> >this issue arises when people want to use the components from com.
> >
> >Any thoughts?
> >
> >Cheers!
> >Dave
> >----- Original Message -----
> >From: "J. Merrill" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Wednesday, June 09, 2004 1:46 PM
> >Subject: Re: [ADVANCED-DOTNET] checking for COM
> >
> >
> >> The COM environments cannot call a constructor with parameters, so you
can
> >know it's a .NET routine calling if they call a constructor that takes
> >parameters. (But of course a .NET program could call your
not-parameterized
> >constructor, unless you document that if they do so they will get
whatever
> >reduced or modified functionality that's inflicted on COM clients.)
> >>
> >> You probably should add a (private) boolean field to keep track of
this,
> >as there's no easy (cheap) way to know if the method that wants to know
> >isn't a constructor.
> >>
> >> Also, AFAIK, a COM call can't call your class's static methods.
> >>
> >> I too am curious about why you want this. If it's really really
> >important, you might possibly be able to figure it out (in the
> >non-parameterized constructor) using a stack-walk (but then I think your
> >callers will need Reflection privileges when that would possibly not be
the
> >case otherwise).
> >>
> >> Good luck...
> >>
> >> At 07:32 AM 6/9/2004, dave wanta wrote
> >> >hi all,
> >> >>From a .NET component (class library), is it possible to check if the
> >ctor
> >> >is being called from a .NET environment, or a COM environment? (like
VB
> >or
> >> >classic ASP) ?
> >> >
> >> >Thanks,
> >> >Dave
> >>
> >>
> >> J. Merrill / Analytical Software Corp
>
>
> J. Merrill / Analytical Software Corp
>
> ===================================
> This list is hosted by DevelopMentorŪ http://www.develop.com
> Some .NET courses you may be interested in:
>
> NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
> http://www.develop.com/courses/gaspdotnetls
>
> View archives and manage your subscription(s) at
http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
