I'm building an n-tier application with data access, application and UI layers in separate projects and hence separate assemblies. MyProjectUI.dll MyProjectApp.dll MyProjectDataAccess.dll etc... The application will eventually be publicly available for download and installed on end-users machines. How can I protect my middle tier and DAL assemblies from unauthorised access so that a 'clever' user cannot add a reference to one of my separate assemblies and start calling it's public members. Marking members as Internal only works for classes that are 'inside' the same assembly. Any tips or suggestions would be greatly appreciated.
"Anthony Bouch" wrote: You've crossposted! > I'm building an n-tier application with data access, application and UI > The application will eventually be publicly available for download and > installed on end-users machines. > > How can I protect my middle tier and DAL assemblies from unauthorised access > so that a 'clever' user cannot add a reference to one of my separate > assemblies and start calling it's public members. Marking members as > Internal only works for classes that are 'inside' the same assembly. Fundamentally, you can't trust anything running on a client machine. Normally, a middle tier runs on a remote machine (i.e. a middle tier machine between the client and the database) for just this reason. So, the "correct" answer is not to install the DAL assembly with the client at all, and communicate via some mechanism (such as .NET remoting or web services) with your middle tier. -- Barry
