CODEWITHSUNDEEP
c#.netgac
Yaron Naveh
Yaron Naveh

Reputation: 24406

Is this a valid use of the GAC?

We have a big winform application which we install on the users disk. We want third parties to be able to write applications that use some of our app capabilities. So we have written API.dll which interacts with some of the others assemblies by resolving the installation dir from the registry. We send API.dll to third parties as an SDK. There are a few options as for how an actual deployment of a third party app will look like:

  1. They "copy local" API.dll and ship with it. Cons: We cannot make a change (non breaking of course) in API.dll since customer apps have it copied. We might need to change it if we change other assemblies it interacts is (which we will probably).

  2. Third parties don't ship with API.dll but instead we put API.dll in GAC. Cons: the hussle of GAC, signing.

  3. same as #1 but API.dll only has abstractions + a factory to load them from our /bin. Cons: may not always turn out trivial, some work.

I don't like the GAC and try to avoid it but some people in the team do and have a point here. What do you think?

Upvotes: 2

Views: 126

Answers (1)

Reddog
Reddog

Reputation: 15579

In general, and as a potential customer, I would avoid the GAC at all costs.

Regarding point 1, I think your customer apps (and dev teams) would more likely rather deploy your updates at their own leisure and testing cycles rather than relying on yours. That way they take your updates when their ready - what if they've already circumvented the "bug" that you just fixed?

Regarding point 2, you'll have a tough time getting everyone to actually use this mechanism except by the convention shown in your own docs. Certainly, I'd still always use copy-local deployments of third party assemblies anyway.

Regarding point 3, you could do this... But it might annoy your customers. If you are going to such large efforts to keep third party vendor software updated perhaps you should question whether you've released your library a little too soon.

Plus from your perspective, I would rather reserve the right to make a breaking change (and document it of course). If your upgrade model doesn't allow you to properly refactor and deprecate old code then you're going to have a tough time making your product better.

My two cents.

Upvotes: 4

Related Questions