Remoting issue

maknoxmaknox Posts: 10
edited February 15, 2005 11:24AM in SQL Toolkit Previous Versions
I have developed a tool to allow our users to migrate data with little or no assistance from the dba group. But I have run into a small (read "large") problem with licensing. The problem apparently is related to the fact that the application is written as several parts to be used as a dot net remoting solution.

These are the projects:
- Migration.Remote - which actually calls the SQL Toolkit items to create the scripts and to move the data
- Migration.Local - which only passes the commands through to the remote components
- Migration.UI - the user interface

Everything appears to work fine on my development machine, but if I deploy it to another machine, I am prompted for the licensing info. I have backed out the remoting part for now in an effort to get the product out the door. Technically, this was to be released to the users 36 minutes ago, but has now been delayed.

Any assistance would be greatly appreciated.

I tried putting a UI on the Migration.Remote component, to force the licensing, but have been unsuccessful. The remoting piece is rather critical because there are several separate application that will do the migration.

Thanks in advance



  • Brian DonahueBrian Donahue Posts: 6,590 New member
    Hi Michael,

    Toolkit project licensing can be a tricky prospect. It involves a few steps: first, invoking the licensing provider, then producing a licence file, then calling the licence compiler (lc.exe) to embed the licence in the assembly.

    With Toolkit applications, every .net assembly needs to have the licence information embedded in it, and the way that is triggered is by linking a text file called licenses.licx into the project. This file contains the object that is part of the dll that you want to licence (RedGate.SQLCompare.Engine.Database, for instance).

    So I think that the first step is to make sure that every project that is part of your solution has the appropriate licenses.licx file linked to it, then rebuild the solution.

    To make sure that the licence was compiled into the assembly successfully without finding out 'the hard way', you can try opening the assembly in a text editor. You should see some of your licence information inside.
This discussion has been closed.