CopyLocal property

This has come up before and has been thoroughly discussed. I get 25 hits just with "copy local" alone so I won't go into the details as to why it is the way it is.

Here's the summary:

• CopyLocal is strictly a VS setting and has no impact on the runtime loading of assemblies. The CLR loader neither knows or cares about this setting.
• Assemblies in the GAC are loaded first followed by a search algorithm that includes the application directory and any configured probe directories.
• If CopyLocal is false then the referenced assemblies must be accessible either in the GAC or in a configured probe directory or the application will fail to load them.
• It is not possible to automatically change the VS setting through an attribute. The only solution is a macro or add-in but this is overkill. VS will automatically set this flag for any non-GAC assembly. Your macro/add-in would have to detect the add-in assembly being added and change the setting. It is just easiest to manually set it.
• If you have an add-in model then the fact that the assembly is copied locally probably shouldn't matter as add-ins normally are only loaded for a specific directory (using Load) or through a configuration file or registry entry (that includes the relative path). So you will probably never simply specify an assembly name. Since that is the general case the fact that the assembly already exists in the app's primary directory doesn't really matter (other than wasting a little space).

Michael Taylor - 4/13/07

http://p3net.mvps.org

Rickard1 wrote:

I am setting up a solution so that plug-in assemblies are built using specific folders different from the host program, and the plug-in developers should not have to worry about this.

To build upon what OmegaMan said I'll point out that MS is adding formal add-in support to .NET. The last report I heard said it'll be in Orcas. It provides a fully architected add-in system for applications to use because application extensibility is really popular. Refer to the January and February CLR Inside Out column in MSDN Magazine.

Michael Taylor - 4/13/07

http://p3net.mvps.org

TaylorMichaelL wrote:

It is not possible to automatically change the VS setting through an attribute. The only solution is a macro or add-in but this is overkill. VS will automatically set this flag for any non-GAC assembly. Your macro/add-in would have to detect the add-in assembly being added and change the setting. It is just easiest to manually set it.

One recommendation I'll make is to move all your add-ins to a fixed subdirectory of your app (or perhaps a config or registry entry). If you use a fixed subdirectory then you can use a post-build event to copy the files to the appropriate location and eliminate any debug-time problems I believe. For example your library assembly resides in the application directory along with all your other core assemblies. Plugins then go in an AddIns subdirectory (through a build step). When your app runs you will always run against the latest library assembly as it always gets built and placed in the app directory (because you will have a reference to it in your main project). The plugins always go into a subdirectory. You'll always load the latest versions in all cases.

If you want plugins to be able to use older versions of the library assembly then you should probably use the GAC but simply strongly-naming the class library and either renaming it based on the version # or placing it into version-specific subdirectories (which the GAC already does) will allow you to load plugins with different library assembly versions. However even in the framework loading multiple versions of the same class library is not really a good idea so compatibility wrappers in the library code is a better approach.

Michael Taylor - 4/16/07

http://p3net.mvps.org