class library security & license technology

"Licensing technology" is basically the methods he goes into more detail about in the rest of the paragraph. A "license" is little more than proof of permission for an actor (either the user themselves, or other code being run on their behalf) to use your code. It doesn't have to be some universal standard like an SSL certificate. It just needs to be known to you, and difficult to fake by others.

As for resources, this is just something inherent in .Net. in VS Solution Explorer, go to the project you want to be able to access your restricted DLL from. The first item in its expanded contents will be a Properties folder; under that you should find an item Resources.resx. Open it up and you'll get a GUI that will allow you to reference strings, images, plain text files, etc. which can be compiled into or kept alongside the DLL when the solution is built. This is where you'd specify a string that is some encrypted, known value. Probably the most secure string to encrypt would be the strong name or GUID of the assembly, because then you could compare what you decrypt with the assembly information of the caller, preventing someone from getting the encrypted string out of one of your libraries and using it in theirs. In your restricted DLL, you can use the same feature to store the decryption key you will use to decode the string provided by calling DLLs.

There are numerous resources available for tutorials on how to use RSA encryption (the encryption method inferred here) in .NET. There is an RsaCryptoServiceProvider that will perform encryption/decryption, generate keys, etc; all you have to do is drop it in. Something that may be confusing is that in asymmetric-key algorithms like RSA, data is usually encrypted using the "public" key and decrypted using the "private" key. This is because assymmetric keys are usually used over public communication channels, and you need to give the remote party a key they can use to write messages that you will then decode. However, in this case, your restricted DLL must decrypt the data it needs to compare, and so it needs a fixed "private key". This makes the decryption key "public" to anyone with .NET Reflector or some similar disassembler. However, if you, the developer, are the only one that can provide encrypted strings to DLLs that are authorized to access your DLL, then you can keep the encryption key secret.