I was using the following:


Where FrameworkPath is defined in the wizard. This nevercompletes.

I broke into it with the debugger, and found that it is in the process of executing the regular expression used to parse the "Expression" attribute. I tried the same regular expression against Regulator, and sure enough, there's a problem with that Regex that has to do with the length. Using a shorter expression, like "$(FrameworkPath)\WebFramework\v1" works well, but as the length increases, the amount of time to complete the Regex increases much faster. It may be exponential.

Is this a known problem?

---

John Saunders | Use File->New Project to create Web Service Projects

Hi John,

This is a known issue. There is nothing wrong with the regex itself but with the way the regex engines parses it, we reported this back ago through Connect to the BCL team and we gotthis response from them:

-----------------------------------------------
This is a known performance issue with System.Text.RegularExpressions when there are nested quantifiers (+ and *) in the expression. The nested quantifiers cause nondeterministic finite automaton (NFA) engines to have exponential running time.

* Please refer to the BCL blog entry for more details - "Regex hangs with my expression [David Gutierrez]": https://mail.microsoft.com/OWA/redir.aspx?C=d6651a8ce58a45e9a139cfd880ac6a4e&URL=http%3a%2f%2fblogs.msdn.com%2fbclteam%2farchive%2f2005%2f02%2f10%2f370690.aspx

WORKAROUND
The workaround is to re-write the expression to no longer have nested quantifiers, reduce pattern ambiguities, and to limit backtracking where possible.

EXTRA INFO
* Please refer to the MSDN article for more details on NFA versus DFA engines - "Matching Behavior": https://mail.microsoft.com/OWA/redir.aspx?C=d6651a8ce58a45e9a139cfd880ac6a4e&URL=http%3a%2f%2fmsdn2.microsoft.com%2fen-us%2flibrary%2f0yzc2yb0.aspx

Thanks,
Josh Free
Base Class Libraries Development
-----------------------------------------------


So this is "by design" and would require a rewrite of the regex used by GAX to accomodate for this behavior. Oddly enough, there are only a few reports from users hitting this, which may be the case this wasn't address yet on the GAX side. This and the fact that users could write their own ExpressionEvaluator service with a modified regex (or whatever else they may need) as this can be done by 3rd parties without requiring any internal code. Although possible this isn't trivial.

If you feel GAX vNext should include a modified Regex let us know here and I'll make sure to put this feedback on the team's plate.

thanks,
-Victor.

---

Working with GAX/GAT/DSL? Download SFT now! http://softwarefactoriestoolkit.net

Yes, I think this is, in effect, a bug. Should I report it on Connect? In any case, my example (or a worse one) should be included, along with the suggestion to use Regulator. (Yes, this is a plug for a nice tool).

---

John Saunders | Use File->New Project to create Web Service Projects

No need to enter it into Connect, it was logged already since some time now, I'll make sure it gets considered again.

thanks,
-Victor.

---

http://t4editor.net -> RTM version coming soon!!

Thanks, Victor. Please note for them that the big issue is the surprise factor. It was a fairly simple expression evaluation, and yet suddenly my recipe is taking 100% CPU and apparently not terminating! I was very surprised. I expected a different bug at that time! ;-)

---

John Saunders | Use File->New Project to create Web Service Projects