Home/ Questions/Q 580755
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T14:30:23+00:00

I’m architecting a WPF application using the PnP Composite Application Guidance. The application will

  • 0

I’m architecting a WPF application using the PnP Composite Application Guidance. The application will be run locally, within our intranet.

Modules will be loaded dynamically based on user roles. The modules must therefore be accessible to the application through a network share, thus accessible from the client machines.

What I’d like to do is keep all the module .dlls in a location not accessible to staff, but still be able to provide them to the composite application when demanded and when the current user is authenticated to use that module.

My thought is to load the .dlls by streaming them down from a WCF service, where the WCF service (on the server) can access the .dll repository, but none of the client machines can access it. Authentication would also be handled by the service.

I suspect that I might be overcomplicating things somehow.

Is this something that can be done with a simple filesystem configuration and programmatically passing credentials when accessing the shared folder? If I do this, would access only be granted to the calling application, or would the logged-on user now be able to navigate to the shared folder?

Is this, in any way, a solved problem with MEF or any other project of which you’re aware? (I hope this isn’t LMGTFY-worthy — I haven’t been able to come up with anything.)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    when loading modules you need to keep in mind that:

    • Once loaded, an assembly can’t be unloaded (unless you unload the entire application domain) – so if users can log in and out using the same instance, you may have a problem.

    • “the load context” matters (see http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx) – this may cause problems if you have dependencies between modules or dependencies on assemblies that are not in the “load context”

    If the restricted access to dlls is due to a licensing issue, maybe you need to refine the licensing mechanism somehow (not tie it to access to the actual code, but to some other checks)?

    • 0