.Net在两个Web服务之间共享dll

Question

I have two web services that are both contained underneath a common subdirectory

CompanyName\Service1
CompanyName\Service2

Each directory has a bin folder that contains its dlls. I've now come to a point where some of this code has been restructured and has quite a few common components and i'd like to be able to 'share' them. What would be the best way to go about this? Below is a list of solutions I have found (along with the negatives).

• AssemblyResolving - Security issues.
• codeBase element inside of web.config - Hardcoded paths to component locations.
• GAC - Currently non of our products use the GAC and I personally have very limited knowledge on using it. This one may just be a fear of the unknown.
• Place assemblies in both locations - Harder to update in place patches. Need to ensure files get replaced in all locations.

Am I missing anything else that could be helpful to me? Would anyone recommend using any of the options listed above?

Additionally, I cannot combine the two services into as they are currently used by third parties (they were build separately).

Answer 1

i would go for the GAC, since is solves all your other problems that you listed, plus it looks natural that a shared library will be in one location.

to use the GAC, all you need it to strong name the dll, and drop it in the GAC in install time it also gives you good side by side versioning options (one WS using version 1.0.0.0 , another can use 1.0.0.1)

Answer 2

You best best is almost assuredly updating both services at once. Take a look at your deployment process if this is something that worries you.

The other real option is using the GAC. The GAC comes with it's own problems such as having to strong name/sign your assemblies and more deployment issues.

In relation to the build system, if you always build and deploy both web services at the same time then you won't have to worry about mix-matches since you indicated the assemblies need to stay the same between services. If you aren't using a CI system, I would suggest you start one, TeamCity is a great one to start with and it's free (well, for a limited number of users/projects - enough to get you started). Then just deploy from CI, either directly or from packages generated from there. I'll admit CI is a bit to tackle for solving one problem but it can help make your life easier if you embrace it in the long run.

Answer 3

Both locations. That way you can publish a change to the common code in one version (interface change / breaking change), by replacing the files in that bin folder, without endangering/breaking the other web service.

Update: this has the same "side-by-side versioning" advantages as using the GAC, without any of the coordinated publishing complexity, strong naming requirements, etc.

Answer 4

This is what the GAC was made for.

You can also do a private NuGet feed if you want to coordinate the shared code.

http://haacked.com/archive/2010/10/21/hosting-your-own-local-and-remote-nupack-feeds.aspx

http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspx

Answer 5

Another option is to put the files in a single location and link to them using a symbolic link. This thread explains the command.

I have no experience of trying this so would not recommend it.