If you haven't finished this yet, you can save yourself from a big mistake by not starting.
A class library is designed to be a class library. A service is designed to be a service. They are two different things with different goals.
For example, you may have defined an enum, and an EventArgs-derived class that has a property of that enum type, and an event handler delegate that takes that EventArgs type, and you may have one or more classes that expose events that use that delegate type.
None of those things make any sense to expose in a service!
Instead, what you should do is to design your service to expose the functionality you want exposed. In order to do that, the service will, of course, use your class library.
One thing different between a class library and a service is that a service should be designed to be usable across platforms. Consider what happens when a Java client consumes your service: it will have a proxy class that corresponds ot the operations exposed by your service. Those proxy methods will have parameters of primitive types, and of proxy types that match the structure of the data passed to and from your service.
The Java client will obviously not use the same .NET types that your server-side operations use!
The default way to build a .NET client works the exact same way - through proxy classes. Your question suggests that you expect that exposing the class library will export the actual classes to the client. That is not the case. If you decide to couple the client to the exact .NET classes used by the server, then the clients will need to have the server-side assembly, just as though the clients were using a normal class library.