Greetings
I am developing a licensed component. The license is a design-time license.
However, I want to do some checks at runtime as well. Therefor, I rely on an
embedded license key at runtime.
I am using a license file, which I signed with my private key and since the
assembly is strongly named, the public key is embedded in this assembly. At
design time the license provider is then verifying the file with this public
key. Sofar so good, nothing fancy about it (except for the time I spent on
this because of the total lack of consistent documentation).
However:
The next roadblock I stumbling upon is the behavior of LC.exe, or rather
VS.2003:
When an assembly is built that is using a licensed control, the licensed key
is supposed to be embedded in that assembly.
This doesn't work with me, at least not most of the time and I don't find
the logic behind it.
When I create the [assemblyname].exe.licenses resource directly with the
License Compiler I can see that the license key is embedded in the resource.
The use of LC on its own is already a daunting exercise, because if you
follow the scant MSDN documentation, you'll get a LC0003 error (unresolved
.....), the only way I got it working is by throwing everything in one folder
(lc.exe, licensed control, licenses.licx, ...).
When I rebuild the assembly in VS, the LC is called by VS (I learned that in
one of the news groups, is this documented somewhere?) and the
[assemblyname].exe.licenses resource is re-created, but mostly empty, i.e.
without the license key.
From my trials with LC.exe, I found out that, when you get an LC0003 error,
the resource is still created and then it is identical to the resource
created by VS (empty). So it looks like that when LC is called by VS, some
error happens, this error is trapped by VS, the whole build process
continues and you end up with no embedded license key.
The other roadblock I encountered is the behaviour of the GetSavedLicenseKey
method of the LicenseContext class.
The MSDN documentation states that this method only does what it should do
if it is overridden. But it looks like that the truth is much more complex:
my experience is that it sometimes does work and sometimes not, and again I
don't find the logic in it.
In some cases the calling assembly has actually the license key embedded in
its resources (easily verifyable with Reflector) and then it happpens from
time to time that the saved license key is actually retrieved by this
method, without being overridden!
The Microsft news groups are full of questions about licensing and most end
up with no answer, or in the best case, an adhoc reply from helpful support
people. What we need is a comprehensive, consistent documentation on
licensing. After all, how can we expect that our customers can use our
products in a seamless way if we are struggling ourselves with the
basics????
Awaiting your comments (and hopefully some answers to my questions!)
Thanks in advance,
Roland
|
Similar Threads
