6

We had a bit of an incident today which has got me thinking. We have a project with a pretty standard web.config transform setup for our various configs. There is a section which controls access to our DAO services which looks like this:

<endpoint address="http://myserver/myservice1.svc/basicHttp"
binding="basicHttpBinding" contract="MyAssembly.IItem" name="DataAccessEndPoint"
kind="" endpointConfiguration="" />
<endpoint address="http://myserver/myservice2.svc/basicHttp"
binding="basicHttpBinding" contract="MyAssembly.IItem2" name="LoggingEndPoint"
kind="" endpointConfiguration="" />

And a transform like this:

<endpoint address="http://mytestserver/myservice1.svc" name="DaoEndPoint" xdt:Transform="SetAttributes" xdt:Locator="Match(name)"  />
<endpoint address="http://mytestserver/myservice2.svc" name="LoggingEndPoint" xdt:Transform="SetAttributes" xdt:Locator="Match(name)"  />

Hopefully you will have spotted the error here - the name for the DaoEndPoint doesn't match. Unfortunately the dev who created it didn't, and had also been locally debugging against the live services, which caused the test deployment to, yup, point to live. We luckily picked it up pretty quickly, but I'm sure you can see the potential for extreme pain here!

I got thinking about your intent when creating transform files and it seems to me that if you put in a transform that you intend to transform something. So it would be nice if the transform (and therefore the deploy) failed if there was a DaoEndPoint transform but no matching DaoEndPoint item in the main .config file.

So I'm sort of canvasing for people's opinions, is this something that would be useful? Is it plain overkill? Am I totally missing the point?

Also, is there anything out there that does this? I'm happy to dig about and develop a solution, but I'd be happier if someone had done the legwork for me ;)

Chris Surfleet
  • 2,462
  • 4
  • 28
  • 40
  • Don't know anything that will cause an exception, though could be useful. Might want to just try leaving the value blank in the main web.config and if it doesn't get transformed, you'll quickly get an error in the application. Not as helpful, but prevents any unintentional PROD access. – dbugger Mar 15 '12 at 23:04
  • The problem with this is that you then can't debug locally without adding in a value, which takes us back to the original issue when the dev forgets to take that value out again... – Chris Surfleet Mar 28 '12 at 09:12

1 Answers1

1

See Sayed Ibrahim Hashimi's great answer to this question, which involves creating a custom class that inherits from Microsoft.Web.Publishing.Tasks.Transform. You could use the same technique but inherit from the Locator class instead, and then throw an exception when you are unable to match a target node.

I actually tested this myself and was able to have the exception thrown during publishing. However, my custom locator class (MyMatch) didn't actually do anything besides throw the exception. It might be a fair bit of work to override methods to mimic the Match class (which you can't inherit from) and then figure out the appropriate place to do a final check for a failure to match.

Anyway, I definitely think it would be useful to at least have an option that you could set where publishing would fail or give you a warning when your transform had no effect.

Community
  • 1
  • 1
regularmike
  • 1,167
  • 10
  • 22
  • Brill, this is just the sort of thing I was looking for, I'll try and get something put together and posted on github in the next couple of weeks. (Apologies for late reply by the way, on vacation with no internet!) – Chris Surfleet Mar 28 '12 at 09:14