views:

178

answers:

2

I'm trying to upgrade an asp.net c# web project from framework 2.0 to 3.5.

When I do this, the client side script that gets written using RegisterStartupScript isn't rendered on the client page.

This works perfectly when I compile for 2.0, and for 3.0, but not when I compile for 3.5.

Here is the code that isn't getting rendered:

Page myPage = (Page)HttpContext.Current.Handler;
ScriptManager.RegisterStartupScript(myPage, myPage.GetType(), "alertscript", "alert('test');", true);

This is called from a class project, and not the web project itself, which is why I'm using the HttpContext.Current.Handler.

There are no errors getting generated from the compiler, the CLR, and there are no client side JavaScript errors.

If I do a search for the "alertscript" in my rendered page, the above code actually isn't there.

Anyone have ideas as to what is going on?

-Edit-

This seems to be an issue when I'm trying to register the script from an external project.

If I use the exact same code in a class file in the web project (not the code behind), it works. However, if I make a call to a method in a class from another project, it does not work.

Does the ScriptManager.RegisterStartupScript not get registered correctly if performed from somewhere besides the web project itself?

-Edit2-

To add more to this, I did the following:

  1. Registered an alert script from my web project class
  2. Called a method in an external class and simply registered another alert script
  3. Registered another alert script from my web project class

After all this is done, if I view the variable: myPage.ClientScript._registeredClientStartupScripts from the web project, I do see these three new entries, one for each of the scripts I just registered. So, I believe everything was added properly.

However, when I let the page finish executing and I look at the results in fiddler, I only see the two that were actually registered from the web project itself, and the one from the external class never makes it down.

Keep in mind, this all works perfectly fine in frameworks 2.0 and 3.0, just not in 3.5.

+1  A: 

Two things

1- Your arguments to the call should probably be something like the following

ScriptManager.RegisterStartupScript(myPage, myPage.GetType(), "alertscript", "alert('test');", true); 

The first argument is the reference to the control registering the script block and the second is the type of the control registering the script block.

2- Are you using this in an UpdatePanel?
http://msdn.microsoft.com/en-us/library/bb359558.aspx

Startup script blocks that are registered by using this method are sent to the page only when the control that is registering the block is inside an UpdatePanel control that is being updated

Chris Taylor
Thanks for the response. I did initially have the type set correctly. I tried setting it to a string to see if it made any difference, and forgot to change it back before pasting in the code.This control that fires this logic is inside an UpdatePanel, and works fine for framework 3.0. Are there any changes to this behavior from framework in 3.5 that you're aware of?
AaronS
@AaronS, nothing that I know of that would affect the registration of the script. Have you tried testing the registration directly on the control rather than from your library function, just to check if that is working?
Chris Taylor
I does work from within the web project. See the update above.
AaronS
@AaronS, a silly question, but I will ask anyway. Are you sure that the Page you are getting using Page myPage = (Page)HttpContext.Current.Handler; is the correct page? Are you calling the library function for an event in you page/control code? If you are can't you pass the Page through to the library function?
Chris Taylor
I initially thought that as well. See edit 2 above. I can see where everything is registered after I add them in both locations.
AaronS
I found the problem, see the separate answer I posted. Thanks again for the help.
AaronS
+1  A: 

The problem was in the external projects.

If you change a web project to use Framework 3.5, the System.Web.Extensions dll reference was automatically updated to the 3.5 version.

This is not the case for non-web projects, probably because they were manually added.

The external projects were still referencing the 2.0 version of the dll, even though I changed the project to compile with 3.5.

Everything worked after I manually changed the reference to the 3.5 version.

AaronS
Excellent, I am sure this is never going to catch either of us again :)
Chris Taylor