Blazor WebAssembly and excluding CSLA data access code with conditional compilation

[TheCakeMonster]

I've been thinking about how I'd use Blazor WebAssembly. At the moment, we use encapsulated implementation in our CSLA objects; our server-side dataportal methods contain ADO.NET code. This works for us because it's a very quick development method, with fewer moving parts.

If we looked to use Blazor WASM then I'd be uncomfortable with the current architecture. I wouldn't want our data access code to end up on the client machine; it includes information about database objects that I do not want to be public. This leaves me a problem; to take our existing code and split it up to use encapsulated invocation or one of the other data access methods I'd have a lot of rework to do.

Then I wondered: is it possible to exclude the server-side methods completely using conditional compilation? Would it be possible to change our solution to build the Blazor website in such a way that the DLLs that get published and shipped to the client don't contain the data access code because they are within an #if conditional compilation section, but that the server-side version of the same DLL does contain them?

My guess is that this is possible, but that it may involve a fairly complex, probably custom, build process. What is unusual about what we are trying to do here is that we want 2 versions of the same DLL with the same name and the same compilation target - .NET Standard - but with different conditional compilation arguments applied.

Does anyone understand the default build process for a Blazor WASM site well enough to know how to do this? Has anyone already tried?

I think this would be a compelling use for CSLA applications built using Blazor WASM.

[rockfordlhotka]

I don't know the answer to this. My recommendation is to use encapsulated invocation, because that puts the data access code into an entirely different assembly. You can easily ensure that assembly doesn't deploy to the client device.