Hello.
I don't know the AjaxControlToolkit very well, but I found a problem which I believe I should report.
I recently noticed that my ASP.NET web site was loading noticeably slower than normal when running on IIS instead of the ASP.NET development server. By attaching the debugger to the process, I noticed that tens of ArgumentNullException were being raised on every page load, in some location which was not visibile in the stack trace.
After some investigation, it turned out that these exceptions come from the ToolkitScriptManagerCombiner.WriteScripts() method, specifically from this code block:
```
try {
Thread.CurrentThread.CurrentUICulture = new CultureInfo(scriptEntry.Culture);
}
catch (ArgumentException) {
// Invalid culture; proceed with default culture (just as for unsupported cultures)
}
```
Basically, this happens when scriptEntry.Culture (string) is null. I traced back the usage of this code and found that this method is invoked by the GetCombinedRegisteredScriptContent() method of the same class, which passes the _scriptEntries list as a parameter, after having initialized it. The problem is that in the initialization of such list (on line 191 with the latest snapshot), the 1-argument constructor of ScriptEntry is invoked, which *always* set the Culture field to null.
It seems to me that the Culture field will always be null, but even if I am wrong it is clear that it *can* be null by design. In this case, I believe it's bad practice to rely on an expensive exception (which in my case occurs 151 times per page load) and that at the very least that value should be checked for being null before invoking the CultureInfo constructor. I would expect this to considerably speed up the code.
Best regards
Comments: Starting with the v15.1 release, we have removed the ToolkitScriptManager due to various issues it caused. So, the described error no longer exists.
I don't know the AjaxControlToolkit very well, but I found a problem which I believe I should report.
I recently noticed that my ASP.NET web site was loading noticeably slower than normal when running on IIS instead of the ASP.NET development server. By attaching the debugger to the process, I noticed that tens of ArgumentNullException were being raised on every page load, in some location which was not visibile in the stack trace.
After some investigation, it turned out that these exceptions come from the ToolkitScriptManagerCombiner.WriteScripts() method, specifically from this code block:
```
try {
Thread.CurrentThread.CurrentUICulture = new CultureInfo(scriptEntry.Culture);
}
catch (ArgumentException) {
// Invalid culture; proceed with default culture (just as for unsupported cultures)
}
```
Basically, this happens when scriptEntry.Culture (string) is null. I traced back the usage of this code and found that this method is invoked by the GetCombinedRegisteredScriptContent() method of the same class, which passes the _scriptEntries list as a parameter, after having initialized it. The problem is that in the initialization of such list (on line 191 with the latest snapshot), the 1-argument constructor of ScriptEntry is invoked, which *always* set the Culture field to null.
It seems to me that the Culture field will always be null, but even if I am wrong it is clear that it *can* be null by design. In this case, I believe it's bad practice to rely on an expensive exception (which in my case occurs 151 times per page load) and that at the very least that value should be checked for being null before invoking the CultureInfo constructor. I would expect this to considerably speed up the code.
Best regards
Comments: Starting with the v15.1 release, we have removed the ToolkitScriptManager due to various issues it caused. So, the described error no longer exists.