assembly replacement and class inheritance

A WCF service named Portal.WebServices.TaskListService uses a codebehind file TaskListService.svc.cs. In this file declare a type named TaskListService that inherits from the type TaskListServiceBase. and implements an interface named ITaskListService. So:

TaskListService: TaskListServiceBase, ITaskListService

   ^                     ^                  ^   
   |                     |                  |
 application               separate assembly 

I want to deploy the TaskListService once on the webserver and put TaskListServiceBase and the interface into a separate assembly that is referenced by the application that hosts TaskListService. So when I want to add, remove or update functionality in the web service I only have to copy the new assembly into the application's bin folder.

Since this happens during runtime I wonder if there are any penalties or caveats for this practice (besides of the use of compile time constants etc), or if this scenario is even possible, or if there are better practices for doing this.

So basically, my question is: I want to update functionality to a WCF service without redeploying the whole application, only the assembly that is updated

^{(yes I feel a bit stupid here)}

The separation of interface and base class in another assembly is possible and correct (Separated Interface is a pattern describing this for just interfaces, and the same pattern applies for base classes).

Regarding the deployment, you can do that as the assemblies are shadow-copied by IIS. However, once the new assembly is copied, I assume you have to recycle the application so the new assembly is loaded.

I did this manually for a Windows Service, that launched a separated AppDomain with shadow copy enabled, so I could remotely update an assembly and force a restart of the service.

This is a practice I follow, there are no downsides that I know of, only benefits. I take it one step further, in that I do not use the code behind. So in your example above, TaskListService.cs would live in a ServiceImplementations assembly, separate from the ServiceContracts assembly.

This allows you to break down your contracts/implementations into multiple assemblies if needed (perhaps separated by domain) and update them independently.