2

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).

Community
  • 1
  • 1
Kyle
  • 17,317
  • 32
  • 140
  • 246
  • if you do no change the code of your dll that often, then Place assemblies in both locations. Or if you have an automated build procedure for the dll have the build script copy the output dll to both the folders if possible. – Aravind May 18 '11 at 12:37
  • Your note to both locations "Harder to update in place patches", is actually the wrong way around. By sharing the same physical assembly you would make it much harder to coordinate a change to one or the other web service, if the common assembly needs to change interface or have some other breaking change. – Tao May 18 '11 at 12:44
  • 1
    I don't understand... can't you just add a reference from both projects to a new project that contains the shared code? The reference will result in the shared project being built when one of the specific projects are built – Simeon May 18 '11 at 12:45
  • @Simeon: Right - there may be some confusion here between coding/build-time management (separate class library project used by both web services, automatically maintained by IDE/build process) and deployment management (safer to update each web service separately, with its version of the core code). – Tao May 18 '11 at 12:48

5 Answers5

3

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)

Menahem
  • 3,974
  • 1
  • 28
  • 43
  • Just add the caveat that the projects will continue to look at the older version in the GAC until recompiled with the newer version, or the web.config is updated to include an assemblyRedirect entry to force use of the new version. – Andy May 18 '11 at 12:48
  • 1
    Right - the deployment overhead of registering in the GAC every time you need to deploy the core code with a breaking change far outweighs the disadvantage of having the shared code assembly duplicated (in my opinion, hence why we have separate answers :)). – Tao May 18 '11 at 12:49
  • @Andy - isnt the default assembly reference option - use latest version ? – Menahem May 18 '11 at 13:41
  • 1
    @Meanahem, not once the assembly is strongly named. Then it's, by default, tied to a specific version. Every time you increment the version you have to remove and re-add the references in Visual Studio. It's such a pain :( We tried doing strongly named assemblies in some open source projects throughout the stack but it was too much hassel. Now you can cheat by signing an ilmerged assembly afterwards. – Travis May 18 '11 at 13:45
  • Travis is right, building against a strong named assembly ties it to a particular version. – Andy May 18 '11 at 17:39
  • @Andy @Travis thanks for the clarification. i mistakenly thought that the "Specific version" property on the reference was not just for VS build time. – Menahem May 19 '11 at 07:01
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.

Travis
  • 10,444
  • 2
  • 28
  • 48
1

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.

Tao
  • 13,457
  • 7
  • 65
  • 76
1

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

bryanjonker
  • 3,386
  • 3
  • 24
  • 37
  • Not sure the GAC was made to make ASP.Net deployment more breakable/complex ;) - but the self-updating website concept is pretty cool! – Tao May 18 '11 at 12:58
0

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.

Community
  • 1
  • 1
IndigoDelta
  • 1,481
  • 9
  • 11
  • 1
    bad idea - this FORCES both web services to be updated at the same time when the core code has a breaking change. GAC solution is messy/heavy but safe when properly applied, and duplicate deployment is safe and simple. – Tao May 18 '11 at 12:56