Rickard1

Is it possible to create a class library that changes the CopyLocal property of the references to it, when such references are made, without any additional Add-ins or macros is Visual Studio
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.
I've read that the .NET framework DLLs have this, but I don't know how to do it without resorting to the GAC (which I'm using now but it's not a good solution since it requires all developers to run a setup wizard every time the host app is changed).

I am looking for a way of specifying at assembly level that CopyLocal should always be False, i.e. "Don't bother about runtime references, I will take care of it".


Re: Visual C# IDE CopyLocal property

TaylorMichaelL

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





Re: Visual C# IDE CopyLocal property

OmegaMan

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.


The architecture has led you to this point. May I recommend a different architecture that will not have to require such a need and may be applicable to your situation.

I have written a plugin architecture that the only shared component is an definitions assembly. Let me explain, it only contains the interfaces, enumerations and truly generic helper classes. Hence this assembly rarely changes and if it does, even if the plugin brings it along, to the plugin directory mind you...no harm no foul. The main app browses the plugin directory and via reflection if the interface is found in the assembly, it gets loaded.

Hope this helps...



Re: Visual C# IDE CopyLocal property

TaylorMichaelL

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





Re: Visual C# IDE CopyLocal property

OmegaMan

TaylorMichaelL wrote:
Refer to the January and February CLR Inside Out column in MSDN Magazine.


Its good read...see the February CLR entitled .NET Application Extensibility





Re: Visual C# IDE CopyLocal property

Rickard1

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.


OK, this was what I wanted, but if this is not possible there is not much to do. I have to live with either developers forgetting the CopyLocal or continue to use the GAC for development.
I should probably have clarified that the problems I have are only present when debugging, not in production use. And the assemblies that are shared between plug-in and host only contains interfaces and enums, but when the version of the interfaces change I get two loaded versions in the system, causing typecasts to fail etc.
Anyway, I suspected it was impossible and thanks for clarifying that it is.




Re: Visual C# IDE CopyLocal property

TaylorMichaelL

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