Upgrade vb.net windows forms application to utilise WCF service with netTcpBinding

I've an existing multi tier application. I would like to add additional
functionality to allow the client to interact with the database through
an installed service created in WCF.
OK, sounds good so far and my initial experiments work. However, the
issue I have is that I do not want to constrain the application into a
client for WCF only. i.e. Currently the client application is
responsible for creating a connection and interacting with the database
(MSSQL) directly. I would like to ensure that the client could either,
connect to a windows service in order to interact with the database (get
instances of datasets), or otherwise, in the case of a small company or
single user, manage its own interaction with the database through its
own kernel as is currently the case. This could be down to the
discretion of system administrators.

So, for large organisations, there would be an installed server service
to which the client application will connect, receive updates and manage
activation. For smaller companies or individuals, the client would be
able to connect directly to the database using its own kernel to
interact with the database.

Right, so my plan originally was to separate the current kernel (returns
datasets and updates DB) into a separate .dll. This could then be
referenced, instantiated and hosted both in the service, where the
service is used or simply within the client application where the
organisation doesn't justify a service and associated overheads.
A configuration section for the client application would allow for the
choice of either service or, alternatively, provide direct database
connectivity.

This should allow me to leave my existing forms alone (of which there's
loads) apart from changing dataset namespaces and simply modify the
existing Kernel to interact with a service or direct to DB depending on
client settings.
The idea is that the service would reference this new kernel, lets call
it MyAppsDAO, and the client application would also. When the client
asks for a dataset the returned dataset would be something like
MyAppsDAO.mydataset1. However, this isn't what happens, if you work it
this way WCF decides to change the namespace to [name of WCF
service].mydataset1 so I get compile issues about invalid casts even
though they are of the same type MyAppsDAO.mydataset1!!!

i.e. dataset of type MyAppsDAO.mydataset1 cannot be converted to [name
of WCF service].mydataset1

So, if I wanted to support interaction with the DB via both WCF and a
client side kernel, I would need to have 2 instances of each dataset, 1
referenced through the Service with a strange namespace and another
correctly referenced. This would mean huge amounts of extra work.

I guess, that if I had to I could make it a WCF only client appo but I need to support people who are on a domain and also those who aren't. From the examples I've seen it indicated that this wasn't supported. Maybe I'm wrong on that though.

If anyone has any ideas, please try and point me in the right direction,
as you can tell I'm new to WCF.