Tales from the messagebox: Shared port types are landmines

I know… In school they told you it was inefficient, and just plain wrong, to write code more than once. When you created a new orchestration you referenced the port type in another already existing orchestration. Everything compiles and it works on your machine. Sweet!

Except you just put in a landmine for yourself or your posterior… uhh uhh posterity.

So here are some scenarios to think about:

  1. A couple of months later they decide that old orchestration is outdated and it can go. So you delete it and when you recompile it blows chunks. You deleted the definition you’re using in the new orchestration.
  2. Some other developer gets the latest code you wrote from the repository and tries to build it. It fails to compile with undefined type errors. It works on your machine, but the same code doesn’t on his. WTF?

Scenario two has a dependency loop. Here’s the setup:

  • Two orchestrations, in the same assembly, Orchestration “A” and Orchestration “B”.
  • Orchestration “A” depends on something in Orchestration “B”
  • Orchestration “B” can’t be compiled because it depends on something in Orchestration “A”.
  • This is the simple version. You can imagine a larger chain with more than two creating a circular reference problem

It compiled on one machine because when that developer coded it all the orchestrations had already been built. Visual Studio didn’t recompile them because it didn’t need to. So after introducing the circular reference it only needed to compile the new code.

So what’s the answer here?

Don’t use shared port types. I haven’t benchmarked it, but they probably aren’t saving any compile time. They’re just definitions so they aren’t testable and you can’t benefit from others testing them either.

Want some hints how to untangle it if you’ve inherited this issue?

  • Find the orchestration where the port type causing problems. You can tell if the type is defined in the file you have open (not a reference) by the text font. Local definitions are in a bolder and heavier font. Other definitions in the same namespace are shown in a lighter font.
  • Right click on it and select “go to definition.” Be careful here. I’ve noticed if you have more than one copy of the same orchestration open visual studio tends to crash.
  • In the properties menu change the declaration type from “public” or “internal” to “private.”
  • Make sure your orchestration is in its own unique namespace. If you have duplicate type names you’ll get name hiding errors at compile time.
  • Select the port definition and hit Control-C to copy it. Head over to the other Orchesration(s) and hit Control-V to paste the identical definition into that file. Feels good to be bad doesn’t it? Duplicating code! You’re such a monster. 😉

Happy untangling! I’ve made a lot of money over my career cleaning up other people’s messes.

Leave a comment