title: Enumerated types as constants across web services?
body: <p>I'm working on a project where I'm trying to avoid hard-coding DB IDs in a .NET service-oriented project. There are some instances where I <strong>need</strong> to set ID values through code but I don't want to just hard code the IDs since I've done that before and it lead to DB alignment nightmares when the auto-incrementing IDs were changed when the DB was dumped to a new system.</p>
  
  <p>What I want to do is create an enumerated constants that store the IDs as so that at the worst, only 1 file has to be updated if the DB is ever changed instead of trying to go through thousands upon thousands of lines of code to replace any ID in the system.</p>
  
  <p>This will work on a single system, but in my company's service oriented environment, enumerations don't serialize with their values, just their names.</p>
  
  <p>What is the best way to share IDs across a web service? I'd like to use either enumerations (the ideal situation) or constants in some way, but I can't seem to get this to work. I could make a web method that returns the IDs, but sending a web request for every ID and then serializing the response and deserializing on the client machine just sounds like a bad idea.</p>
  
  <p><strong>EDIT</strong><br>
  I wasn't entirely clear about what I was asking, so I'll elaborate.</p>
  
  <p>I want to have a group of constants. The enum would only be used because it groups constants together appropriately. I'm mainly interested in see if there is a way to share constants across a web service. I need the values the enum represent, not the enum itself. The enum is never sent between the service and the client except as an integer. Internally everything is stored as an ID, not an enum.</p>
  
  <p>Having a separate shared library doesn't sound like the ideal solution since I'm almost at the completion point for this project and I'd only be storing 1 enum/class in the library. It seems like a bit of a waste to make for just one class.</p>