views:

29

answers:

1

I have created a common library at work, but unlike in this question, it is not published to the GAC. Instead, it is privately published to a company-specific installation folder. EDIT: all the internal apps go into this same folder.

Is it still possible to apply a publisher policy, allowing older applications to use newer versions of the DLL? This article makes it sound like I can, but it's not totally clear to me.

If so, what should I distribute into my company-specific installation folder?

  1. A config file for the common library? (policy.1.0.MyLibrary.config) (This would be easiest.)
  2. A policy DLL for the common library? (policy.1.0.MyLibrary.dll -- the complied version of #1.)
  3. Or a set of config files for every application that uses the common library? (MyApp1.exe.config, MyApp2.exe.config, etc.) (YUCK!)
A: 
  1. would be all you need IMO. Or to be exact in your app.config setup bindingRedirect element and you are done.

Ups sorry. bindingRedirect demands that the folder is under your application folder.

What is the benefit of "company-specific installation folder" that is not under app folder in regard to GAC ? IMO the GAC is better if they want assemblies to be shared.

If they insist you could "manually" load the assemblies. Look at AppDomain.AssemblyResolve event.

Petar Repac
The applications get installed in the same folders as the library, so that would be ok. But it sounds like you are talking about an app.config file for the application, which is my #1. Will it work to write a policy.1.0.mydll.config file instead?
Eric
Sorry, never used policy config file. But I have a suspicion that you do not need one. Just use bindingRedirect in your XYZ.exe.config
Petar Repac
There are multiple applications that use the library. So I would have to create and maintain config files for each one of them, and I would also need to know as new applications are written. Like I said for #3 in the question ... YUCK!
Eric
As I understand it you have some folder and in that folder are copied library .dll's but also application .exe's and .dll's. Deploy of new library .dll's means overwrite of older library .dlls (same name) but new files have different AssemblyVersion. Is that correct ?
Petar Repac
Looked up policy dlls. It seems that they are deployed to GAC and apply only to binding assembly in GAC. But it would be best to test this scenario. Another possibility is maybe assembly binding in machine.config file. To root of the problem is bad deployment scenario IMO. Look here:http://ondotnet.com/pub/a/dotnet/2003/03/17/bindingpolicy.html
Petar Repac
Petar Repac