Hi Paul, Your code looks pretty similar to what I have in a test app I wrote to verify the problem (although my code is C#, FWIW). I load the assembly (I use LoadFrom instead of Load), I get the type and then Activator.CreateInstance. Mine fails on the creation _unless_ in the EXE project I add a licenses.licx file as an embedded resource. The licx file contains the license information for the control I am using (it's the ChartFX.Net control from Softwarefx).
Perhaps you can verify a few things to make sure I am not just making this up... - the third party controls you are using are actually run-time licensed, and if so then - no licenses.licx file in your EXE project - the third party controls are not installed on any non-developer machines .Net licensing is explained in [1]. The way I would check if the controls you are using are run-time licensed is to create a simple form base app and add the control via the designer. Then see if your project folder has a licenses.licx file. Once you build the exe, use ildasm to look at the manifest and check if there is a licenses resource (an even better way to look at the exe is with Lutz Roeder's Reflector if you have that). I'd be curious what you find. [1] - <http://www.gotdotnet.com/team/windowsforms/Licensing.aspx> > -----Original Message----- > From: Paul Ballard [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 31, 2002 2:43 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] embedding resources > > > I think there may be a problem with the way they are using > the licensed > component or how it is installed. A third party control's > licensing is > handled by that control. If it is included as part of > another assembly it > should be able to take it's license info along for the ride > via dependency. > > At my client we are using third party components from Infragistics, > Developer Express, and ComponentOne. I have created custom > controls using > these third party controls in my own class library called > AOPCCtrls.dll. I > am then using those controls in forms that are also compiled > into class > libraries to be loaded dynamically via reflection by the main > exe file. I > have had no licensing issues, even on the production server. > > Here is a code snippet that shows how I am loading the assemblies > Imports System.Reflection > Public Class Form1 > Inherits System.Windows.Forms.Form > > #Region " Windows Form Designer generated code " - Just a > form with a button > > Private Sub Button1_Click(ByVal sender As System.Object, > ByVal e As > System.EventArgs) Handles Button1.Click > Dim asm As [Assembly] = [Assembly].Load("AOPCCtrls") > Dim objType As Type = asm.GetType("AOPCCtrls.DatePicker") > Dim obj As System.Windows.Forms.Control = > CType(Activator.CreateInstance(objType, True), > System.Windows.Forms.Control) > obj.Location = New Point(50, 50) > obj.Size = New Size(66, 21) > Me.Controls.Add(obj) > End Sub > End Class > > Is there a specific licensed control that is having a problem? > > Paul Ballard > [EMAIL PROTECTED] > > > >From: Peter Zaborski <[EMAIL PROTECTED]> > >Reply-To: "Moderated discussion of advanced .NET topics." > ><[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: [ADVANCED-DOTNET] embedding resources > >Date: Fri, 31 May 2002 12:00:36 -0600 > > > >Unfortunately I don't think this will work. The add-ins > already have the > >required resources. Here is the more detailed description of > what I want to > >do. I fear I won't be able to do what I want due to .Net > licensing policy > >:-(... > > > >We have a generic container which runs our application. The > application > >uses > >pluggable modules (add-ins) which are discovered at run time > and loaded as > >needed from satellite assemblies. The app is designed to be > extended by > >clients who can write their own add-ins. As long as they > follow our rules, > >their add-ins will appear seamlessly in our app. The add-ins > may have a UI > >component, usually they do, although the UI aspect is not necessarily > >relevant. And as I mentioned originally, the add-ins get loaded via > >reflection at run time. The problem occurs when the add-ins > use a licensed > >component. It seems .Net requires the _executing assembly_ > (the generic > >container in our case) to have the licensing information > embedded in it > >when > >it tries to create an object which uses a licensed > component. Otherwise the > >creation fails. Even if the license info is embedded in the add-in > >assembly, > >that's not enough. It must also be embedded in the executing > assembly. > > > >My theory is that if I could modify the container (at run > time, obviously > >we > >don't know all the licensed controls clients' add-ins might > use at compile > >time) to some how dynamically load a license resource and > make it appear > >like it's embedded in the container EXE, perhaps I could enable the > >clients' > >add-ins to use licensed controls. All they'd have to provide > is the license > >resource in some format the container would use to load and embed the > >resource in its assembly (at run time). If this is not > possible, then the > >concept of using run time add-ins which wrap licensed > components will not > >be > >possible in a .Net app AFAIK. > > > >Any comments or suggestions welcome. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
