locked
Ajax RC not working on production server, works on dev machine RRS feed

  • Question

  • User1603054497 posted

    Hi,

    I updated an Ajax Beta 2 web application to use the new RC build and it works fine on my development PC, but it doesn't work on my IIS6 production server.  I checked and both of the DLLs are in the GAC.  Has anyone else ran into this?  I get this error when trying to access the page:

    Server Error in '/UserManager' Application.

    Object reference not set to an instance of an object.

    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

    Stack Trace:

    [NullReferenceException: Object reference not set to an instance of an object.]
    System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods) +378
    System.Web.Script.Services.PageClientProxyGenerator.GetClientProxyScript(HttpContext context, IPage page, Boolean debug) +45
    System.Web.UI.ScriptManager.RegisterServices() +728
    System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e) +244
    System.Web.UI.Page.OnPreRenderComplete(EventArgs e) +2012740
    System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1566


    Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.210
     

    Friday, December 15, 2006 11:11 AM

Answers

  • User1603054497 posted

    Well, I started this topic 123 replies ago so I thought it would be appropriate for me to wrap it up as well.  Go get the RTM version. [:)]  I can testify that the RTM build fixes this problem.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 24, 2007 4:19 PM

All replies

  • User-1411892346 posted
    Completely down here too.  Two different servers, both savme error.  Works great on dev machine.
    Friday, December 15, 2006 12:03 PM
  • User1603054497 posted

    I've tried it on 2 other IIS6 servers as well, doesn't work on them either.  Dev machine is running Windows XP SP2 and it works perfectly.

     

    Friday, December 15, 2006 12:10 PM
  • User-1411892346 posted
    In case it helps, here's my error, which is pretty much identical to yours.  I've restarted the servers and even copied the bloody dll's from the programfiles/microsoft asp.net/ folders into my bin folders, but nothing.

    Server Error in '/' Application.

    Object reference not set to an instance of an object.

    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

    Stack Trace:

    [NullReferenceException: Object reference not set to an instance of an object.]
       System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods) +378
       System.Web.Script.Services.PageClientProxyGenerator.GetClientProxyScript(HttpContext context, IPage page, Boolean debug) +45
       System.Web.UI.ScriptManager.RegisterServices() +728
       System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e) +244
       System.Web.UI.Page.OnPreRenderComplete(EventArgs e) +2012740
       System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1566
    


    Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.210
    Friday, December 15, 2006 12:10 PM
  • User1453324696 posted
    I'm seeing the exact same thing.  Dev machine is XPSP2 and test server is 2003.
    Friday, December 15, 2006 12:12 PM
  • User-1411892346 posted
    To test to see if it was an IIS vs VS2005's web server thing, I set up the virtual directory on my XPSP2 box and it runs fine under there.  I'm really at that panic stage as I updated since it worked perfectly fine on this machine(just like all the other updates since the Jan when I first started using it)
    Friday, December 15, 2006 12:24 PM
  • User-1411892346 posted

    I got it to work, I'm not sure what else its going to screw up, but I turned on "Allow this precompiled site to be updatable" and "Use fixed naming and single page assemblies" and its running on my production server.  Now I need to get back to finding out what damage this is doing.

    Friday, December 15, 2006 12:32 PM
  • User1603054497 posted

    Interesting... I found that all I need to do is just check off "Allow this precompiled site to be updatable" when deploying the project and it seems to work on IIS6 now.  This can't possibly be the release candidate if they are introducing bugs...

    Can anyone else confirm that this is a problem with the "RC", or am I just going crazy/doing something wrong?

    Thanks

     

    Friday, December 15, 2006 12:47 PM
  • User1453324696 posted
    I checked the "Allow this precompiled site to be updatable" and sure enough, it works on Server 2003!
    Friday, December 15, 2006 1:07 PM
  • User-2129142612 posted

    Can someone from Microsoft please give this thread some attention?

    I had exactly the same issue.  I have been upgrading <STRIKE>Atlas</STRIKE> ASP.NET AJAX each and every time, and never had a problem.

    This time I got everything working perfectly on my DEV box, and then uploaded to my PROD box.  Then it gave exactly the same error message as people posted above.  Turning on debug and trace did not provide any more detail in the error message.

    The only way I could fix it was to deploy the source files, which I hate doing.

    FYI, I am using the AJAX library, the Dec. Futures library and the latest Toolkit.

    I need to get my box straight again.  Please put some resources on this and help us out with a solution!

    Thank you.

    Friday, December 15, 2006 3:55 PM
  • User-2129142612 posted
    BUMP
    Saturday, December 16, 2006 11:23 AM
  • User-2129142612 posted
     

    Server Error in '/' Application.

    Object reference not set to an instance of an object.

    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

    Stack Trace:

    [NullReferenceException: Object reference not set to an instance of an object.]
       System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods) +378
       System.Web.Script.Services.PageClientProxyGenerator.GetClientProxyScript(HttpContext context, IPage page, Boolean debug) +45
       System.Web.UI.ScriptManager.RegisterServices() +728
       System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e) +244
       System.Web.UI.Page.OnPreRenderComplete(EventArgs e) +2012740
       System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1566
    


    Version Information: Microsoft .NET Framework Version:2.0.50727.91; ASP.NET Version:2.0.50727.210
    Saturday, December 16, 2006 11:25 AM
  • User211531759 posted
    I am also having the same issue.  Ticked off updatable and fixing naming and it works.
    Saturday, December 16, 2006 8:45 PM
  • User543848960 posted
    I have the same issue, anyone found out why this is happening?
    Sunday, December 17, 2006 11:31 AM
  • User-808642076 posted
    Just the same also here. Turned both options ON and it start working....In my experimenting it had a for a while a message about the security error, but it sure cannot be...

     
    Sunday, December 17, 2006 1:20 PM
  • User543848960 posted

    This is really weird. If I compile my application with the "updatable" and then try to access the Login.aspx-page I get an error that says "Cannot convert type 'ASP.login_aspx' to 'System.Web.UI.WebControls.Login'". I got proof that this error is due to the "updatable" option: http://blogs.sqlxml.org/bryantlikes/archive/2005/12/14/4570.aspx.

    Sunday, December 17, 2006 1:56 PM
  • User1922605967 posted

    Yes, rename your login page so its != login.aspx, and it will work

     

    Ken 

    Sunday, December 17, 2006 2:54 PM
  • User543848960 posted

    Well, I thought that was the solution too... I renamed my Login.aspx to UserLogin.aspx, but the same error occurs - only now it's with UserLogin.aspx.

    Since this is occuring because of the subject of this thread, I hope they fix that soon!

    Sunday, December 17, 2006 4:07 PM
  • User-275701703 posted

    My site that is hostd is also broke..

     Appreciate a quick response on this one to fix the problem

    Thanks

     

     

    Version 0.0.0.0
    Browser Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
    User
    Remote Address 127.0.0.1
    Remote Host 127.0.0.1
    Exception Details
    Type System.NullReferenceException
    Message Object reference not set to an instance of an object.
    Target System.Web.Script.Services.WebServiceData GetWebServiceData(System.Web.HttpContext, System.String, Boolean, Boolean)
    Stack at System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods) at System.Web.Script.Services.PageClientProxyGenerator.GetClientProxyScript(HttpContext context, IPage page, Boolean debug) at System.Web.UI.ScriptManager.RegisterServices() at System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e) at System.Web.UI.Page.OnPreRenderComplete(EventArgs e) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

    Sunday, December 17, 2006 5:55 PM
  • User-356119435 posted
    I'm having the exact same problem if that helps spur anybody at Microsoft to get involved...
    Sunday, December 17, 2006 6:52 PM
  • User-356119435 posted

    I have determined that the problem only occurs when you deploy a Precompiled project (i.e. using the "Publish Website" command from VS). If you do a file-by-file copy from your development machine to your production machine, you can avoid the error.

    I have also verified that this error occurs on even a very simple website (basically, the only thing on the page is a single UpdatePanel).

     

    Sunday, December 17, 2006 7:27 PM
  • User2006178999 posted

    Same here - doesn't work on our production server either.

    Secondly, i use a DEPLOYMENT PROJECT to move my code from my local box to our dev, test, uat and prod servers.

     *sigh*

    Sunday, December 17, 2006 7:32 PM
  • User-75921627 posted

    I'm having the same problems too. It works perfect on my dev machine but not on the production server (2003, iis6). Now I had this Object reference not set error. This is the error I'm getting now when I had ticked off the "updatable" in the publishing of the site. Previously I had a different error but now it won't show up.

    I might just be confused but I had not seen these assemblies being added before in the beta versions.

    <add assembly="System.Drawing.Design, Version=2.0.0.0, Culture=neutral ......

    <add assembly="Microsoft.VisualStudio.Shell, Version=2.0.0.0, Culture=neutral .....

    Now, everytime I tried to compile the page, it adds those two assemblies. I am not worried about the System.Drawing.Design, but I'm worried about the Microsoft.VisualStudio.Shell, If I'm right, that dll is only available on the SDK and not on the runtime. (Correct me if I'm wrong)

    Is there by any chance a problem with webservices? I'm consuming another webservice and it does not have ajax. I hope someone would reply and give us the light.. :) Good day.

    Regards,

    Sunday, December 17, 2006 9:56 PM
  • User-2129142612 posted

    I have determined that the problem only occurs when you deploy a Precompiled project (i.e. using the "Publish Website" command from VS). If you do a file-by-file copy from your development machine to your production machine, you can avoid the error.

    I have also verified that this error occurs on even a very simple website (basically, the only thing on the page is a single UpdatePanel).

    Doing a file-by-file copy does not avoid the problem for me.  I always manually FTP the files, once they are prepared by a Web Deployment Project.  I never use "Publish".

    Hopefully that wind storm has died down in Redmond.  [:)]

    Sunday, December 17, 2006 10:13 PM
  • User-1634877164 posted

    Have you installed the ASP.NET AJAX RC build on the production server?  The errors you are describing sound like the RC build hasn't been installed on the target server.

    Thanks,

    Scott

    Monday, December 18, 2006 12:45 AM
  • User-2129142612 posted
    Thanks for replying Scott.  Yes, it has definitely been installed on the target server.
    Monday, December 18, 2006 12:51 AM
  • User-75921627 posted

    Hi,

    Should this be installed on the server? Previous ajax builds worked fine on the server without it being installed (just pure dll's in the bin), I don't see a reason why to put it in the server. (besides, I don't have much of an access right to the server, It does have Framework 2.0 installed since it was already released) :)

    Regards,

    Monday, December 18, 2006 2:43 AM
  • User963264391 posted

    I get the exact same issue when using "non-updateable" builds using Web Deployment Projects. All pages work except any that have ajax controls. I checked "Allow site to be updateable", rebuilt, re-deployed and it works now. All my pages use master pages as well, not sure if that helps narrow it down (since master pages and ajax don't get along perfectly...i.e. intellisense issue).

    If not for this thread, we miss our maint window. Thankfully, I got the app up with 7 min to spare!

    Monday, December 18, 2006 2:54 AM
  • User-75921627 posted
    Hi,
    Monday, December 18, 2006 3:02 AM
  • User-75921627 posted

    Hi,

    First, this was a double post, my browser thought I was passing the post when I hit enter even though I was just going to the next line in the text area. (Pls delete it, I can't seem to delete it)

    May I ask if by any chance you had Microsoft.VisualStudio.Shell.dll added in your assembly automatically when you had compiled. If so, is it existing in the GAC of the production server? I believe that dll is not in the runtime but in the SDK. Should those be installed too? In the previous beta builds, Microsoft.VisualStudio.Shell.dll was not used. Does anyone know why? I'm having errors saying that it could not load that file or assembly. I searched for it in my local pc and I found it under the SDK folder (I installed it before).

    Regards,

    Monday, December 18, 2006 3:07 AM
  • User-75921627 posted

    I installed the ajax rc extensions at a development server (mimics most of the production server), I also had this issue at that server. After I installed Ajax RC, it still complains about the Microsoft.VisualStudio.Shell thing. I also get an "object reference not set" on master pages.

    Monday, December 18, 2006 4:43 AM
  • User-75921627 posted

    Hi, It seems I got things sorted out but I really want to know why. After I had installed Ajax Extensions at the development server, I tried to remove the configuration line that concerns the Microsoft.VisualStudio.Shell. It works now, but I don't know why. That assembly reference was automatically added to my config file everytime I build the site. If anyone knows why this dll is being added and yet not needed, pls tell us. (Note: this dll assembly reference only appeared when RC was installed) Thanks! (Sorry if I keep my post in one paragraph, If I press Enter, my browser seems to be very happy to post this w/o my consent, instead of going to a new line)

    Monday, December 18, 2006 5:02 AM
  • User-1411892346 posted
    Beta 2 was removed using Add Remove Programs, the server was restarted, RC was installed, server restarted, project deployed.  As with all the previous versions since Jan.  Two different 2003 servers, both same result.
    Monday, December 18, 2006 8:14 AM
  • User1453324696 posted

    Scott -- Yes, RC was installed on the production server.  (After the beta was uninstalled)  The only thing I changed was to check the "Allow pages to be updated" in the Publish website window.


     

    Monday, December 18, 2006 8:21 AM
  • User1347944086 posted

    I've got the same problem too, but I know where it's coming from.

    We are using "Web Deployment Project".

    Everything was OK with beta 2 and prior. Now with RC the deployed web site do not run on the production server. But it works fine if we just copy all source files and update manually our web.config.

    It's a hudge probem !!! WDP is very usefull and RC do not work at all anymore !!!!

    Monday, December 18, 2006 8:49 AM
  • User1453324696 posted
    I'm not using the Web Deployment Project.
    Monday, December 18, 2006 9:13 AM
  • User1347944086 posted
    I thought you were using the standard "Publish"... Quite the same thing... Did you try to simply copy your sources ?
    Monday, December 18, 2006 11:54 AM
  • User-2129142612 posted

    It would be nice to know if someone is working on this issue. [:#]

    Monday, December 18, 2006 12:22 PM
  • User1453324696 posted
    I didn't realize that the Publish wizard was the same thing was a web deployment project.  It works fine if you check the Allow page to be updated in the Publish window.
    Monday, December 18, 2006 1:17 PM
  • User-2129142612 posted

    I didn't realize that the Publish wizard was the same thing was a web deployment project.  It works fine if you check the Allow page to be updated in the Publish window.

    They are not the same thing.  The Publish option is available whether or not you install the Web Deployment Project.  The WDP allows you to automate some tasks that Publish cannot, and it includes various ways to merge your assemblies before they get deployed.

    We have already been discussing in this thread that the only way around the problem is to allow the site to be updatable, and that is the point.  Most people do not want their site to be updatable in a production environment, especially where security is concerned.

    I am sure I'm not alone in wanting someone from microsoft to comment on this issue, if only to say "we're working on it."  The official policy seems to be not to ackknowledge an error unless the solution has already been created, no matter how long it takes.  I wish that would change, because it's very frustrating to keep checking back only to see more people reporting the problem, with no response from Microsoft.

    Monday, December 18, 2006 2:06 PM
  • User-1634877164 posted

    Just to give a quick update to the thread on this - I've forwarded it to the appropriate developer and he will be investigating to figure out what is going on here (unfortunately this week a lot of people are out of the office - so there might be a slight lag).

    I want to confirm whether everyone on this thread is seeing the same issue and if these are the approximate repro steps:

    1) Create a site that uses the ASP.NET AJAX RC using a VS 2005 Web Site Project.  Everything works fine locally.

    2) Build the project using either the "publish web site" or "web deployment project" utility with the "allow the site to be updatable" checkbox unchecked

    3) Install the ASP.NET AJAX RC on a remote server

    4) Deploy the project onto the remote server, and you see the below error stack trace:

     [NullReferenceException: Object reference not set to an instance of an object.]
       System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods) +378
       System.Web.Script.Services.PageClientProxyGenerator.GetClientProxyScript(HttpContext context, IPage page, Boolean debug) +45
       System.Web.UI.ScriptManager.RegisterServices() +728
       System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e) +244
       System.Web.UI.Page.OnPreRenderComplete(EventArgs e) +2012740
       System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1566

    To fix it, it sounds like people have discovered that keeping the "allow this site to be updatable" checkbox checked (which is the default) doesn't cause this issue.  This pre-compiles the code-behind filles into assemblies, but doesn't remove the .aspx html/server control markup from pages.

    Can people who are having this issue verify the above steps, and respond to the thread if this isn't correct? 

    Thanks,

    Scott

    Monday, December 18, 2006 3:48 PM
  • User963264391 posted

    Confirmed. That is my exact problem.

    Unfortunately, after unchecking "Allow this site to be updateable" I got numerous class conflict errors, so I had to just post the raw files for now.

    Monday, December 18, 2006 3:54 PM
  • User1922605967 posted

    Confirmed and correct

     

    Ken 

    Monday, December 18, 2006 4:36 PM
  • User-1942745458 posted

    Above is correct.

    I changed by deployment batch file by adding the -u (allow updatable) and I don't get the exception.

     aspnet_compiler -v %virtualPath% -p %sourcePath% -f %destinationPath% -c -nologo -u

    Monday, December 18, 2006 4:38 PM
  • User-1158022506 posted

    This indeed looks like a bug where we weren't expecting the BuildDependencies to be null, but when a site is precompiled and not updateable, there are no build depedencies for the page, and we were missing a null check for this case, thanks for reporting this issue, it will be fixed...

    -Hao

    Monday, December 18, 2006 4:58 PM
  • User-2129142612 posted

    Scott,

    Thank you for checking into this!  I can confirm that's the exact problem and workaround.

    Monday, December 18, 2006 5:30 PM
  • User1347944086 posted
    Yes. As expected "allow updatable" works fine for me but it's not a solution for production servers... Thanks to find a better solution, and merry xmas !
    Monday, December 18, 2006 5:38 PM
  • User-2129142612 posted

    This indeed looks like a bug where we weren't expecting the BuildDependencies to be null, but when a site is precompiled and not updateable, there are no build depedencies for the page, and we were missing a null check for this case, thanks for reporting this issue, it will be fixed...

    -Hao

    Interesting, thanks for the expanation.  Is there any way to force BuildDependencies to be non-null without deploying the source files?  (As a temporary workaround.)

    Monday, December 18, 2006 5:41 PM
  • User-1158022506 posted
    Unfortunately I can't think of one, as not deploying the source files means there are no BuildDependencies which is what uncovers this bug...
    Monday, December 18, 2006 5:59 PM
  • User-2129142612 posted

    Unfortunately I can't think of one, as not deploying the source files means there are no BuildDependencies which is what uncovers this bug...

    OK, understood.

    Is there a chance to slip-stream the bug fix so we don't need to wait for the next RC?  Or would you release an RC2 quickly?

    Monday, December 18, 2006 6:27 PM
  • User-356119435 posted
    For me, checking Allow Updateable does not solve the problem. The only way I could solve it was to do an xcopy deployment.
    Monday, December 18, 2006 11:32 PM
  • User198088005 posted

    I have the same problem, but I don't want to mark "allow website to be updatable".

    I'm waiting and finding a solution

    Thanks 

    Tuesday, December 19, 2006 2:38 PM
  • User-1799478678 posted

    I have never been able to do an "Allow Updateable" (probably a config problem on workstation or server), so I am still getting the exact error. 

     I built a page from the ground up, adding in components and controls to find out where the app breaks. I can do most things until I have to add the following:

    <asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager> 

    Just adding that breaks it, where it previous releases were fine.

     Hope that is helpful in trying to resove this!

     

    Tuesday, December 19, 2006 2:42 PM
  • User-75921627 posted

    To summarize my posts, this solved it for me. (I had used the Publish option)

    Intall the RC version at the server (uninstall any old versions)

    Remove the System.Web.Extensions.* from your local bin (should be in GAC)

    Publish the project. (Uncheck the Allow Updateable box) (I had checked it again now, no problems but uncheck it on the first try)

    Copy the precompiled site to the server.

    If necessary, remove the assembly reference Microsoft.VisualStudio.Shell from the web config. (I think this got something to do with the Toolkit but I can't trace what control is automatically adding this reference)

    If you're still getting an error, try to do the it again (beats me but sometimes it works, I tried restarting the application pool although I don't believe it would do the trick)

    If you had access at the server, try to get the error from there. If you are unsure, compare your web.config to the one at the microsoft asp.net folder. Check if you had everything there.

    Tuesday, December 19, 2006 11:11 PM
  • User-2129142612 posted
    Just curious if we are any closer to seeing a solution for this bug.  Would anyone from MS care to comment?
    Wednesday, December 20, 2006 9:20 PM
  • User-1634877164 posted

    Hi Speednet,

    Hao is the Microsoft developer of this feature who was on the thread a little earlier.  The good news is that he found and fixed the issue and it will be fixed with the next drop.  The workaround until then would be to compile the project with the "allow site to be updatable" checkbox selected.  This will work around the problem (while still keeping your project compiled).

    Hope this helps,

    Scott

    Thursday, December 21, 2006 1:01 AM
  • User-2129142612 posted

    Hi Speednet,

    Hao is the Microsoft developer of this feature who was on the thread a little earlier.  The good news is that he found and fixed the issue and it will be fixed with the next drop.  The workaround until then would be to compile the project with the "allow site to be updatable" checkbox selected.  This will work around the problem (while still keeping your project compiled).

    Hope this helps,

    Scott

    Thank you Scott.

    Thursday, December 21, 2006 6:59 AM
  • User-1713614716 posted

    Add me to the list of those with this issue. The workaround does not work for me either. I can't get it to work deployed locally or on my production server with "allow site to be updatable" checked.

    For those who are really in a bind and need something working right now as I do, you might consider downgrading to the Beta 2 version. I had a working system with Beta 2, so I've gone through a successful downgrade. It was a huge pain, but I'm back in business on my deployment server.

    Thursday, December 21, 2006 11:43 AM
  • User-484987990 posted

    Add me to the list of those with this issue. The workaround does not work for me either. I can't get it to work deployed locally or on my production server with "allow site to be updatable" checked.

    For those who are really in a bind and need something working right now as I do, you might consider downgrading to the Beta 2 version. I had a working system with Beta 2, so I've gone through a successful downgrade. It was a huge pain, but I'm back in business on my deployment server.

     exactly the same here - we had to rollback also... checky-tick-check no work! :)

    Friday, December 22, 2006 12:21 AM
  • User825625080 posted

    Hello Scott,

     You solution does solve the problem in some cases.  But on the other hand, it created another issue:

     

    Server Error in '/TP8i' Application. <o:p></o:p>


    Parser Error <o:p></o:p>

    Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

    Parser Error Message: The base class includes the field 'NotePad', but its type (Contacts_NotePad) is not compatible with the type of control (ASP.contacts_notepad_ascx).

    Source Error: <o:p></o:p>

    <o:p> </o:p>
    Line 14:     <tpo:Rolodex ID="contact_rolodex"  runat="server" />     <o:p></o:p>
    Line 15:   </div><o:p></o:p>
    Line 16:   <tpo:NotePad ID="NotePad" runat="server" /><o:p></o:p>
    Line 17: </asp:Content><o:p></o:p>
    Line 18: <o:p></o:p>


    Source File: /TP8i/Listings/ViewEditListing.aspx    Line: 16 <o:p></o:p>


    Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.210


     This error is caused by Updateable = True.  Is this a bug?  Thanks

    Friday, December 22, 2006 5:39 PM
  • User-1937182130 posted
    I'm on the list, too. Can we expect to have an official patch or shall we have another RC release soon?
    Monday, December 25, 2006 5:18 AM
  • User1021810413 posted

    The workaround began working for me after I rebooted the 2003 test server and refreshed all files for the web folder using the Updateable feature checked.  This is not how we want to operate when we go to production.   

    Is there an estimated date that the RC version will be updated? 

    I have wasted a lot of time on this and it is not making me look good here at work.  Your assistance is greatly appreciated and needed. 

    Tuesday, December 26, 2006 4:04 PM
  • User-2129142612 posted

    The workaround began working for me after I rebooted the 2003 test server and refreshed all files for the web folder using the Updateable feature checked.  This is not how we want to operate when we go to production.   

    Is there an estimated date that the RC version will be updated? 

    I have wasted a lot of time on this and it is not making me look good here at work.  Your assistance is greatly appreciated and needed. 

    I agree, there really should be a way to slip-stream the bug fix for an error of this magnatude.  We're not talking about an official version of the software anyway, so all the formality of waiting for the next release candidate does not help anybody, and in fact punishes those who take a chance and work with beta software.

    The concept of people gaining access to unofficial releases for important bug fixes is very common these days, especially for any developer who has worked with "CVS" code on SourceForge or nightly builds on CodePlex.  I am really surprised that a fix for this major bug was not rushed into everyone's hands who needs it.

    Like dutchinusa, I am completely stuck, unable to deploy new functionality until I get the bug fix.

    Tuesday, December 26, 2006 7:18 PM
  • User-1411892346 posted

    Its that whole beta works better than the release canidate.

    I know after I got it to work that day, I haven't touched a single thing on our software that uses MS Ajax because I'm afraid that checking my two options on a publish won't work anymore and completely fry out my customers rather than the "small" 4 hour outage when it came out.

    Tuesday, December 26, 2006 8:41 PM
  • User-2129142612 posted

    Happy new year.

    STILL NO FIX?

    Tuesday, January 2, 2007 1:47 PM
  • User-581386078 posted
    Add me to the list as well. Any updates?
    Tuesday, January 2, 2007 6:27 PM
  • User1715089119 posted

    Well I don't know if this will help or not.  But I think the problem is definately related to upgrading visual studio.  Last week I was running the RC version fine with no problems.  This week I installed the following and I now get the same error as mentioned above:

     Visual Studio.Net 2005 Service Pack 1

    .Net Framework 3.0

     Windows SDK

     Visual Studio Extension.

     It appears that one of these four is incompatible with the Ajax.

     

     

    Tuesday, January 2, 2007 7:00 PM
  • User-2129142612 posted

    Well I don't know if this will help or not.  But I think the problem is definately related to upgrading visual studio.  Last week I was running the RC version fine with no problems.  This week I installed the following and I now get the same error as mentioned above:

     Visual Studio.Net 2005 Service Pack 1

    .Net Framework 3.0

     Windows SDK

     Visual Studio Extension.

     It appears that one of these four is incompatible with the Ajax.

     

     

    If you look back earlier in this thread you'll see that a Microsoft tech isolated and identified the source of the problem already, so whatever problem you're having is not related to this topic.  Maybe you want to start a different topic describing your issue, so that it won't get lost here.

    The reason I bumped this thread looking for an update is that I personally feel that Microsoft is not using best judgement to sit on the solution, while weeks go by and I (and others) cannot properly deploy their web sites.  You may feel that this is not a critical issue, but I am telling you it is.  The workaround involves deploying source code to the web server, which is not an acceptible solution in all cases, especially were tight security is required.

    Tuesday, January 2, 2007 7:30 PM
  • User-1158022506 posted

    Since this appears to be a critical issue for some folks, we are willing to provide a private preview build with this fix in addition to other fixes that will be included in the final release. 

    We are still working out the details exactly, but if you are interested in getting a preview build with this fix, email me directly at haok@microsoft.com and I'll put you on the list...

    Hope that helps,
    -Hao

     

    Tuesday, January 2, 2007 7:49 PM
  • User1347944086 posted

    The reason I bumped this thread looking for an update is that I personally feel that Microsoft is not using best judgement to sit on the solution, while weeks go by and I (and others) cannot properly deploy their web sites.  You may feel that this is not a critical issue, but I am telling you it is.  The workaround involves deploying source code to the web server, which is not an acceptible solution in all cases, especially were tight security is required.

     You're right. But you should not forget that you are using beta stuff... How can you speak about "properly deploy" beta pieces ?

    Tuesday, January 2, 2007 8:12 PM
  • User1347944086 posted
    Great idea at last... Thanks for listening to us...
    Tuesday, January 2, 2007 8:29 PM
  • User-2129142612 posted

    The reason I bumped this thread looking for an update is that I personally feel that Microsoft is not using best judgement to sit on the solution, while weeks go by and I (and others) cannot properly deploy their web sites.  You may feel that this is not a critical issue, but I am telling you it is.  The workaround involves deploying source code to the web server, which is not an acceptible solution in all cases, especially were tight security is required.

     You're right. But you should not forget that you are using beta stuff... How can you speak about "properly deploy" beta pieces ?

    You either read my post too fast, or you did not understand it.  If you go back and read more slowly you'll see I was talking about properly deploying a web site without deploying source code.  If you have never done this, it is accomplished using Microsoft's Web Deployment Projects.  The AJAX bug prevents people from deploying their sites without source code.  That was mentioned a few dozen times in this thread.

    The other thing wrong with your post is that this is a Release Candidate, not a "beta" as you say.  The only bugs are supposed to be minor in nature, not something like this.  Plus, to imply that a web site using pre-release software should be deployed with lower security is really not appropriate.

    Tuesday, January 2, 2007 10:02 PM
  • User-1634877164 posted

    Just in case people missed Hao's post above, we will be able to provide an updated version of ASP.NET AJAX that fixes this problem.  Send mail to haok@microsoft.com to obtain a copy of this.

    Thanks,

    Scott

    Wednesday, January 3, 2007 12:37 AM
  • User-2129142612 posted
    Thank you HaoK anbd Scott!
    Wednesday, January 3, 2007 8:19 AM
  • User1347944086 posted
    You either read my post too fast, or you did not understand it.  If you go back and read more slowly you'll see I was talking about properly deploying a web site without deploying source code.  If you have never done this, it is accomplished using Microsoft's Web Deployment Projects.  The AJAX bug prevents people from deploying their sites without source code.  That was mentioned a few dozen times in this thread.
    I understood well what you're talking about and I am one of the guys who fell on this bug and have posted on this thread already!

    The other thing wrong with your post is that this is a Release Candidate, not a "beta" as you say.
    You're playing with words and it's none of interest. Even if it is a "RC" level and no more a "beta" stage, it is not completely a final release yet. This thread has started the following day of the new RC release. And many people have found the bug upgrading their production server. Upgrading means there were deploying beta 1 or 2 before...

    You certainly have noticed one day that even when you release a minor subversion of any product you may introduce a new critical bug... No one is perfect. It happened to me a long time ago. It can happen to everyone.

    The only bugs are supposed to be minor in nature, not something like this.  Plus, to imply that a web site using pre-release software should be deployed with lower security is really not appropriate.

    You cannot expect new bugs to be minor. A bug can be minor or critical. So you finally agree that RC stage is still pre-release ?!?!

    It is not a so huge bug. A critical, but not a blocking one. You can still work on your site, that's the more important. And you can still deploy the site on any server if you do not prebuild your code.

    Of course I've lost time deploying my prebuilt site on a pre-production (not production in my case) server before understanding what was happening. But in my opinion it is my problem as I have decided to use "beta" components. I found that this thread, and everybody who has contributed, was very reactive. The AJAX team does not have any obligation to release a fix and thanks again to them to do so...

    PS : and sorry for my english, you may understand something I didn't wanted to say ! so don't reply in the thread as it is not the subject...

    Wednesday, January 3, 2007 10:19 AM
  • User-1411892346 posted

    You certainly have noticed one day that even when you release a minor subversion of any product you may introduce a new critical bug... No one is perfect. It happened to me a long time ago. It can happen to everyone.

    And once you found and fixed the problem, how long did it take before you posted the update?  I started using Atlas back in March 2006 when they gave the Go Live license(aka, its safe to use on production applications) and the "release canidate" has been the only one that's created problems for my deployment.  If it where Beta 3, I'd have shrugged it off as another beta release and tried to find a mirror of Beta 2, but it wasn't.  It seems reasonable to expect a quick patch to something that was such a milestone.

    Wednesday, January 3, 2007 11:03 AM
  • User1132075246 posted

    thank you -

      when deploying on a production server,(with atlas dll's in the bin ) I am getting the error  below  - on my test server I have no problem even with the atlas framework uninstalled: 

    MESSAGE: Request for ConfigurationPermission failed while attempting to access configuration section 'system.web/deployment'. To allow all callers to access the data for this section, set section attribute 'requirePermission' equal 'false' in the configuration file where this section is declared.
    MESSAGE: System.Security.SecurityException: Request for ConfigurationPermission failed while attempting to access configuration section 'system.web/deployment'. To allow all callers to access the data for this section, set section attribute 'requirePermission' equal 'false' in the configuration file where this section is declared. ---> System.Security.SecurityException: Request for the permission of type 'System.Configuration.ConfigurationPermission, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed. at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) at System.Security.CodeAccessPermission.Demand() at System.Configuration.BaseConfigurationRecord.CheckPermissionAllowed(String configKey, Boolean requirePermission, Boolean isTrustedWithoutAptca) The action that failed was: Demand The type of the first permission that failed was: System.Configuration.ConfigurationPermission The first permission that failed was: <IPERMISSION class="System.Configuration.ConfigurationPermission, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" version="1" Unrestricted="true"></IPERMISSION>The demand was for: <IPERMISSION class="System.Configuration.ConfigurationPermission, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" version="1" Unrestricted="true"></IPERMISSION>The granted set of the failing assembly was: <PERMISSIONSET class=System.Security.PermissionSet version="1"><IPERMISSION class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="TEMP;TMP;USERNAME;OS;COMPUTERNAME"></IPERMISSION><IPERMISSION class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="D:\hshome\davoust\davoust.com\test" Write="D:\hshome\davoust\davoust.com\test" Append="D:\hshome\davoust\davoust.com\test" PathDiscovery="D:\hshome\davoust\davoust.com\test"><IPERMISSION class="System.Security.Permissions.IsolatedStorageFilePermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Allowed="AssemblyIsolationByUser" UserQuota="9223372036854775807"></IPERMISSION><IPERMISSION class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Assertion, Execution, ControlThread, ControlPrincipal, RemotingConfiguration"></IPERMISSION><IPERMISSION class="System.Security.Permissions.PublisherIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" X509v3Certificate="308205333082041BA003020102020A61469ECB000400000065300D06092A864886F70D01010505003081A6310B3009060355040613025553311330110603550408130A57617368696E67746F6E3110300E060355040713075265646D6F6E64311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E312B3029060355040B1322436F70797269676874202863292032303030204D6963726F736F667420436F72702E312330210603550403131A4D6963726F736F667420436F6465205369676E696E6720504341301E170D3036303430343139343334365A170D3037313030343139353334365A3074310B3009060355040613025553311330110603550408130A57617368696E67746F6E3110300E060355040713075265646D6F6E64311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E311E301C060355040313154D6963726F736F667420436F72706F726174696F6E30820122300D06092A864886F70D01010105000382010F003082010A0282010100CD819638AE5CA2F2C1DFDED0AB958DD63C9D1F8BC35D862E5DF0B172F5ABAC886AB5DAB1227B0BC8C8A54B915E2213E9F9F5239DB5F46E76AEEFEEA43CC7C4C0595C3FABB3733326A662816179A162F4 6E8895D06EDDC79FD2A451117661BA708A65A1961689A75D81D04466E5DB569E40CAFCDC76242E443000E5D67D7B9511D5581DA3E84F0BC988DCA2D653996CCA63CA996A9A925E4C4D11E82FD35B5B5E5F52A3732DA5BB84450D8C191576CB08DA9AA67015E84DEC69FD5DB26B8FED295137388BC6464915945098B0F468A4D7DE097167749E778C1D856B97EAE75F45CCE0E6710DD16300937B31988E0BB413BDB3D0EEF1DF21EEA96061EE37433DC30203010001A38201923082018E300E0603551D0F0101FF0404030206C0301D0603551D0E04160414EED96BA97553CD4FEE1B4E19061EA39CABCF94FD30130603551D25040C300A06082B060105050703033081A90603551D230481A130819E801425F82B4B5DC87254ADE5F6A02A1716FBC1F95381A174A4723070312B3029060355040B1322436F70797269676874202863292031393937204D6963726F736F667420436F72702E311E301C060355040B13154D6963726F736F667420436F72706F726174696F6E3121301F060355040313184D6963726F736F667420526F6F7420417574686F7269747982106A0B994FC0001DAB11DAC402A16627BA304B0603551D1F044430423040A03EA03C863A687474703A2F2F63726C2E6D6963726F736F66742E636F6D2F706B692F63726C2F70726F64756374732F436F64655 369676E504341322E63726C304F06082B0601050507010104433041303F06082B060105050730028633687474703A2F2F7777772E6D6963726F736F66742E636F6D2F706B692F63657274732F436F64655369676E504341322E637274300D06092A864886F70D0101050500038201010038D9EF95389B5C98145D546E69DF02C8E7B3FBD3C24DAD2FAB7F540DDA32B6F86AE60DFB211A773EA5687AB4957E8A5CF243C4839B657D8850517C8214F58373D7A2BE5CCA0270CE266C17BC5214A589C0B7E4A1CCA1759D91713D1BC0560056B5F88426DA5E33FBD6257A5E9ADAA6FBF4F2411AAC5546AD48DC913813580949F1F331871FBC048E5B126503E90B51D0A10C8A99BDD9C1A8D008152521B5B657891CD15B8635A5CAFDAA87ECA9373FB7436BE320F145BC7EAEE9F155B2A148BC65BE5334D9C9E806630406786E50FF48BB9BEA435A87DBAD0A80F559C52CE4E57F5B4AE53279EE2285920C2DB3505BC6C2405858ABD2CDE32FC1CDEC6D9F3779"></IPERMISSION><IPERMISSION class="System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" PublicKeyBlob="0024000004800000940000000602000000240000525341310004000001000100B5FC90E7027F67871E773A8FDE8938C81DD402BA65B9201D60593E96C492651E889CC13F1415EBB53FAC1131AE0BD333C5EE6021672D9718EA31A8AEBD0DA0072F25D87DBA6FC90FFD598ED4DA35E44C398C454307E8E33B8426143DAEC9F596836F97C8F74750E5975C64E2189F45DEF46B2A2B1247ADC3652BF5C308055DA9" Name="System.Web.Extensions" AssemblyVersion="1.0.61025.0"></IPERMISSION><IPERMISSION class="System.Security.Permissions.UrlIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Url="file:///D:/hshome/davoust/davoust.com/test/bin/System.Web.Extensions.DLL"></IPERMISSION><IPERMISSION class="System.Security.Permissions.ZoneIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Zone="MyComputer"></IPERMISSION><IPERMISSION class="System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Level="Medium"></IPERMISSION><IPERMISSION class="System.Net.DnsPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"></IPERMISSION><IPERMISSION class="System.Drawing.Printing.PrintingPermission, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" version="1" Level="DefaultPrinting"></IPERMISSION><IPERMISSION class="System.Net.Mail.SmtpPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Access="Connect"></IPERMISSION><IPERMISSION class="System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"></IPERMISSION><IPERMISSION class="System.Data.OleDb.OleDbPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"></IPERMISSION><IPERMISSION class="System.Data.Odbc.OdbcPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"></IPERMISSION><IPERMISSION class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"></IPERMISSION><IPERMISSION class="System.Net.SocketPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"></IPERMISSION></PERMISSIONSET>The assembly or AppDomain that failed was: System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 The method that caused the failure was: System.Web.UI.IDeploymentSection GetDeploymentSectionWithAssert() The Zone of the assembly that failed was: MyComputer The Url of the assembly that failed was: file:///D:/hshome/davoust/davoust.com/test/bin/System.Web.Extensions.DLL

     any ideas ?

     

    Wednesday, January 3, 2007 11:05 AM
  • User1347944086 posted

    Your production server is hosted and you can't install AJAX in GAC ? You must run with Full Trust for that trick to work. But generally you don't have Full Trust...

    You may check your <configSections> section from your web.config too.

     

    Wednesday, January 3, 2007 11:26 AM
  • User1132075246 posted

    yes my prod, server is hosted and i have no access to the GaC, -

     I cannot run full trust either, I tried  I got [Parser Error Message: This configuration section cannot be used at this path.  This happens when the site administrator has locked access to this section using <location allowOverride="false"> from an inherited configuration file.

    My 
    <configSections> are copied from the AjaxEnabledWebsite template

    <configSections><sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

    <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

    <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>

    <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

    <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>

    <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>

    <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>

     

    Wednesday, January 3, 2007 11:44 AM
  • User1347944086 posted

    yes my prod, server is hosted and i have no access to the GaC, -

     I cannot run full trust either,

    ...Then you have to ask your hoster to install AJAX in GAC

    Wednesday, January 3, 2007 12:00 PM
  • User-2129142612 posted

    *sigh*

    There are a number of things you are saying which I'll respond to once again, just to set the record straight.  Hopefully this can be the end of it, as I'm sure everyone is getting tired of this exchange, especially when Microsoft is offering the solution privately to those who need it now.

    I'll skip over all of your editorial comments about the critical bugs you've made in your life.  I'll cede the point that nobody's perfect.

    You cannot expect new bugs to be minor.

    Ah, yes I can.  Microsoft said that all bugs in the RC release should be minor.   

    So you finally agree that RC stage is still pre-release ?!?!

    You said Beta, which is why I pointed out your error.  Beta is Beta.  RC is RC.  They are not the same thing.  Your argument is like saying "Beta software is software, and Released software is software, so you finally agree they are both software ?!?!

    If you don't understand the difference between Beta and RC, then I'm sure you can locate the deifnitions somewhere on MSDN.

    It is not a so huge bug. A critical, but not a blocking one. You can still work on your site, that's the more important

    I'm not sure who you think you are, trying to tell me what is important to me.  Again, I call your reading and comprehension skills into question, as you completely avoided all of the careful points I made in my post.  It has nothing at all to do with whether or not I can work on a web site.

    But in my opinion it is my problem as I have decided to use "beta" components.

    That's great for you, but not everyone thinks the way you do.  Please try to be more accepting of others' ideas.

    The AJAX team does not have any obligation to release a fix and thanks again to them to do so...

    I beg to differ, especially as it relates to a major bug such as this.

    By the way, it's not your English that's terribly bad, it's your preconceived notions.  Please try approaching things with a more open mind, especially where a discussion of ideas is concerned.  The world is not black and white.  Your arguments sound just like the type of arguments made by C# enthusiasts who feel that Visual Basic is worse than a pile of garbage and should be eliminated.

    Wednesday, January 3, 2007 12:05 PM
  • User1347944086 posted
    ... and Happy New Year speednet !!!
    Wednesday, January 3, 2007 12:11 PM
  • User-2129142612 posted
    To you as well.  Good luck to you.
    Wednesday, January 3, 2007 12:30 PM
  • User1132075246 posted

     ...Then you have to ask your hoster to install AJAX in GAC

    Thank you steffff, I thought I could start deploying my atlas web site now, as It may be month before they upgrade it in Atlas. -

    Wednesday, January 3, 2007 12:36 PM
  • User-1158022506 posted

    I sent out the build to everyone I've received an email from as of around 11 AM PST 1/3.  If you sent email to me and don't recieve the build today, please send me another email and I'll resend it...

    Thanks,
    -Hao

    Wednesday, January 3, 2007 2:07 PM
  • User-581386078 posted

    I just tried the update and unless I'm missing something I'm still receiving the exact same problem.

     
    Steps:

    1. Unistalled previous version
    2. Installed new version
    3. Deleted any references to the AJAX dlls in my project
    4. Re-added dll references to the newly installed dlls.
    5. Published website.

     
    Did I miss something?
     

    Wednesday, January 3, 2007 4:57 PM
  • User1347944086 posted

    Did we miss something ? I'm afraid this build is not better. I get the same error with the same stack trace... Sorry.

    Wednesday, January 3, 2007 5:11 PM
  • User-1158022506 posted

    Are you sure you've removed the old dll from everywhere?  You definitely should not be seeing the Null Ref exception from WebServiceData in the callstack assuming you installed the new build I sent out...  Make sure you reset iis on the machine you are publishing too as well after you upgrade, since the dll is installed in the GAC.

    Hope that helps,
    -Hao

    Wednesday, January 3, 2007 5:30 PM
  • User1347944086 posted
    Reset IIS ? That's an idea... and a good idea. It's really better now !!! Thank you Hao.
    Wednesday, January 3, 2007 6:12 PM
  • User-2129142612 posted

    I have a mid-way update for the forum on the temporary fix that was e-mailed out (thank you), and I'd be interested to hear if anyone has hands-on knowledge of a problem I've found.  I have not yet re-compiled and tested using the DLL-only publish, but I'll post on that once I'm at that point.

    I methodically went through the steps of installing the new version (everything mentioned above in previous posts), then had to fight through some "Ambiguous Reference" errors.

    (Ironically, there is something ambigiuous about a big error message that says "Ambiguous Reference" without much supporting detail, but I digress.....)

    After recompiling a bunch of times, checking every folder to be sure I didn't add an extra DLL, deleting all ASP.NET temporary files, putting the AJAX Extension DLLs into the bin folder, taking them out again, and I'm sure several other things, I started tracing through code to see if I could figure out anything in there.

    Eventually I narrowed down the problem to a custom web control I built that used Rick Strahl's nice little ClientScriptProxy class to load scripts and other resources.  When I commented out most of the code in the ClientScriptProxy, forcing it to only use the Page's normal ClientScriptManager, everything started working.

    I'm now noticing that Rick has made some changes in the past couple of weeks to his code, so perhaps that will help, I'll try it out.

    For anyone who has not tried Rick's ClientScriptProxy, it's a great little class, when you get to know it.  I wonder if Microsoft will build something like that into <STRIKE>Atlas</STRIKE> AJAX Extensions?

    Wednesday, January 3, 2007 8:04 PM
  • User-2129142612 posted
    By the way, the "hands-on experience" was related to Rick's ClientScriptProxy, and any changes that would be necessary to update it for the latest release. 
    Wednesday, January 3, 2007 8:07 PM
  • User-581386078 posted

    Hoa, 

    Restarting IIS did the trick, site now works. Great job on the fix!


    Thursday, January 4, 2007 10:43 AM
  • User-302890775 posted

    The "allow updates" option was not an option for me because I have to protect intellectual property.

     Thanks for the patch Hao. You're a life saver! [:D]

     The only difficulty now is that the AjaxToolkit doesn't work anymore. Apparently, the patched RC1 does not provide the debug javascript object in the release compile. Unfortunately, the toolkit uses the debug object all over the place. I will have to go through the code and remove the references to it or insert checks for existence before invocation.
     

    Friday, January 5, 2007 2:38 PM
  • User-302890775 posted

    There's only like 10 references to the debug object in the script of the toolkit. I commented them out and the toolkit works like a charm.

     It looks like there was the beginnings of an attempt to insert conditionally compiled debug code in the script. Things like:

     
    // ##DEBUG debug.assert( ...

     Good work AJAX team.
     

    Friday, January 5, 2007 2:56 PM
  • User1210007617 posted
    After updated to the new preview build, most features work fine, but got a new error now. It shows “The server method ‘Login’ failed.” when call Sys.Services.AuthenticationService.Login, but it works fine in RC1 build. And I got the same error even I try it in AJAX Samples Applications\TaskList\0_Login.aspx after modified the code to show the error message as following. <script type="text/javascript"> function Login() { Sys.Services.AuthenticationService.login( aspnetForm.user.value, aspnetForm.pwd.value, true, /*customInfo*/null, '1_ListOfTasks.aspx', null, FailedCallback); } function FailedCallback(error, userContext, methodName) { alert(error.get_message()); } </script> When I look into by Nikhil’s WebDevHelper, found it request /Authentication_JSON_AppService.axd/Login and the server return http 404.
    Sunday, January 7, 2007 12:28 PM
  • User-1411892346 posted

    There's only like 10 references to the debug object in the script of the toolkit. I commented them out and the toolkit works like a charm

     Definately let the toolkit guys know.  Its my sunday so I'm taking time out from my weekend to see if I can get the patch to work right and just finished commenting out 21 lines out of the latest toolkit source.  *crosses fingers*

    Sunday, January 7, 2007 2:57 PM
  • User-1411892346 posted

    There's only like 10 references to the debug object in the script of the toolkit. I commented them out and the toolkit works like a charm.

    Does your AlwaysVisibleControl, Animation, ConfirmButton, DropDown, HoverMenu, PopupControl, Slider, TabContainer/TabPanel, ToggleButton, UpdatePanelAnimation work?  I tried the development and release folders after commenting out all the debug.asserts, it gives me a

    Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.

    Details: Error parsing near 'b7

    168|error|500|Re'.

    when I try and do anything with the Toolkit sample site.

    Sunday, January 7, 2007 3:11 PM
  • User-1411892346 posted
    I went ahead and tried it with my project, seems to work okay for the few toolkit controls I use.
    Sunday, January 7, 2007 4:46 PM
  • User-302890775 posted
    You're right NXTwoThou. I get the same toolkit errors. I guess it doesn't work like a charm [:-(] . Fortunately for me, the toolkit controls/extenders that I need seem to work fine.
    Monday, January 8, 2007 4:48 PM
  • User739833330 posted

    Is is still possible to get a copy of the preview build.  I am having the same problem with our production system and need to run them compiled.

     Thanks,

    -Nathan Wheeler
     

    Monday, January 8, 2007 5:42 PM
  • User-1331076166 posted

    Can someone point me to the download for the hotfix for this issue?

    This issue has been preventing us from updating our production server and needs to be fixed ASAP...

     Thank you.

    Tuesday, January 9, 2007 11:23 AM
  • User1119954915 posted

    Can someone point me to the download for the hotfix for this issue?

    This issue has been preventing us from updating our production server and needs to be fixed ASAP...

     Thank you.

    go back one or two pages on this topic for the email address that the request needs to goto

    Tuesday, January 9, 2007 1:34 PM
  • User-1553550390 posted

    Hi guys,

    first of all I would like to thank you for this thread. I already pushed the enter button "with my fist" because I didn't have the slightest idea what was wrong with my solution - after deploying it to the production machine on friday evening...

    I actually had two issues which have been mentioned around here and which probably help others.
    I use MasterPages, AJAX RC1 and Web Deployment Projects, which actually gives you a lot of locations to search for the error. This was especially annoying because the only error I got from my custom event-logging mechanism was "Object reference not set to an instance..." and that doesn't really help you finding the exact location of the bug - until I figured out it wasn't my bug, but a problem with "Debug" and "Release" (thanks again guys)

    The workaround for me contained two steps:
    1) Mark the project as "updateable" in web deployment project
    2) Rename my Login.aspx class so it's not "Login" anymore (which conflicts with another control unfortunately). I read this hint in one of the earlier postings but I would like to point out one important thing. It is necessary to rename the CLASS - not the aspx-Page.

    Thanks Microsoft for ruining my Friday :-)
    kind regards, Chris

    Wednesday, January 10, 2007 4:41 AM
  • User-2129142612 posted

    I just wanted to confirm to MS that the interim release DOES work properly and fixes the bug.  I was able to deploy without marking the site as "adaptable".

    As a follow-up to my earlier post, I was able to patch Rick Strahl's ClientScriptProxy class to work with the new release of ASP.NET AJAX.  I posted my fix in his blog comments, but he has not yet updated his module with the changes.  I think once he sees it blow up after the new release comes out he will.  [;)] 

    Wednesday, January 10, 2007 7:17 AM
  • User-2129142612 posted
    I meant to say "updatable" in my last post, not "adaptable".
    Wednesday, January 10, 2007 7:19 AM
  • User-485340671 posted

    I received the fix and am preparing to try installing it, but I am running into a problem at step one: I assume based on other posts in this forum that I should start by uninstalling the previous version, which I have read should be done by going to Control Panel -> Add / Remove Programs.  I don't see anything there that looks remotely related to AJAX.  (fyi, this should be a clean install.  RC1 is the first and only version we have installed, and there haven't been any previous attempts to uninstall.)

    So:

    1. (less important) Why don't I find ASP.NET AJAX in Add/Remove Programs?  and
    2. (mor important) How do I uninstall since it isn't listed?
    Thursday, January 11, 2007 3:54 PM
  • User-1415763228 posted

    I have this problem, too (see my post yesterday).  It looks like people fix this problem by checking "Allow this precompiled site to be updatable" when deploying the application.  Is there anyway to do this at the IIS management MMC?

    My IIS 6.0 runs on a Windows 2003 server box. 

    Thanks.
     


    Friday, January 12, 2007 1:25 AM
  • User739833330 posted

    I just wanted to go on record as saying that the preview build that I received from Hao (see the previous posts for more information) worked like a charm.

     
    It also seems to have addressed a separate issue that I was having with one of my pages where the row data bound events on a GridView were not firing correctly and thus it would not render any results.  The page worked fine on the identically configured test/dev server but every time I posted the code (compiled or un-compiled) to the production server the GridView would not display any results. 

    This problem started about the same time I upgraded to VS 2005 SP1 and AJAX.net RC1 and only affect our production server.  The frustrating part was the fact that there were other controls that were being updated but the selection, but the GridView would fire its DataBound event and then not render any content to the page.  Anyway, this preview build seems to have addressed the problem so thanks again to all involved.<o:p></o:p>

    Friday, January 12, 2007 9:35 AM
  • User1119954915 posted

    Is there anyway to do this at the IIS management MMC?

    That "allow updatable" is a feature of Studio, not of IIS, so you are not going to find it in the MMC


     


    I don't see anything there that looks remotely related to AJAX

    Are the files at "C:\Program Files\Microsoft ASP.NET"  ?  if there are no folders for MS AJAX in there, then it's not installed


    (fyi, this should be a clean install.  RC1 is the first and only version we have installed)

    clean = nothing installed....  so if RC1 is indeed installed, then you wouldn't be doing a clean install  (hope that makes sense)

    Friday, January 12, 2007 9:47 AM
  • User-485340671 posted

    I don't see anything there that looks remotely related to AJAX

    Are the files at "C:\Program Files\Microsoft ASP.NET"  ?  if there are no folders for MS AJAX in there, then it's not installed

    If you look at the context of my post, I'm saying I don't see anything in Add / Remove Programs related to AJAX.  Yes, RC1 is installed and there are files in C:\Program Files\Microsoft ASP.NET.  But since I don't know everything about what the installer does, I'd prefer to run an uninstall rather than just delete files that I know about and risk missing something.


    (fyi, this should be a clean install.  RC1 is the first and only version we have installed)

    clean = nothing installed....  so if RC1 is indeed installed, then you wouldn't be doing a clean install  (hope that makes sense)

    I didn't mean that I am trying to do a clean install; I meant that the current install of RC1 should be clean - hence my confusion at why I can't find it in Add / Remove programs to remove it.

    Thanks for your attention and for any other advice that you may have.

    Friday, January 12, 2007 10:37 AM
  • User-2129142612 posted
    In Add/Remove Programs it is listed as "Microsoft ASP.NET 2.0 AJAX Entensions 1.0".
    Friday, January 12, 2007 11:07 AM
  • User-1415763228 posted
    antonyliu2002:

    Is there anyway to do this at the IIS management MMC?

     

      That "allow updatable" is a feature of Studio, not of IIS, so you are not going to find it in the MMC

    So, this is not available to Visual Web Developer 2005 Express Edition?  Then how do I "allow updatable" as I don't have Visual Studio?


     

    Friday, January 12, 2007 11:29 AM
  • User-2129142612 posted

    So, this is not available to Visual Web Developer 2005 Express Edition?  Then how do I "allow updatable" as I don't have Visual Studio?

    Just make sure you don't compile everything to DLLs in the bin folder.  At the very least you need to deploy the ASPX files with the source code intact (not just the stubs that are created when you compile everything to DLLs).  The code-behind files can be either compiled to DLLs or deployed with full source code, it will work either way.

    Of course, if you need to deploy everything in DLLs for security reasons, you can write to the e-mail address mentioned earlier in this thread for the pre-release.  It fixes the problem nicely.

    Friday, January 12, 2007 11:42 AM
  • User-1415763228 posted

    Thanks, but I don't even have a bin folder for the entire (abeit very small) application. 

     Look:

     F:\Website\AjaxTest>dir
     Volume in drive F is Webspace
     Volume Serial Number is 67A1-398D

     Directory of F:\Website\AjaxTest

    01/12/2007  11:08 AM    <DIR>          .
    01/12/2007  11:08 AM    <DIR>          ..
    01/10/2007  03:32 PM    <DIR>          App_Data   /* <--- This folder is empty */
    01/11/2007  12:45 AM            15,412 Default.aspx
    01/11/2007  12:21 AM               509 Default.aspx.cs
    12/14/2006  11:44 AM             6,697 Web.config

    F:\Website\AjaxTest>

    Friday, January 12, 2007 12:10 PM
  • User-2129142612 posted

    Thanks, but I don't even have a bin folder for the entire (abeit very small) application. 

     Look:

     F:\Website\AjaxTest>dir
     Volume in drive F is Webspace
     Volume Serial Number is 67A1-398D

     Directory of F:\Website\AjaxTest

    01/12/2007  11:08 AM    <DIR>          .
    01/12/2007  11:08 AM    <DIR>          ..
    01/10/2007  03:32 PM    <DIR>          App_Data   /* <--- This folder is empty */
    01/11/2007  12:45 AM            15,412 Default.aspx
    01/11/2007  12:21 AM               509 Default.aspx.cs
    12/14/2006  11:44 AM             6,697 Web.config

    F:\Website\AjaxTest>

    Then you don't need to change a thing; the bug in this topic thread does not affect you.  If you are having issues, it is due to some other problem.

    Friday, January 12, 2007 12:13 PM
  • User-485340671 posted

    In Add/Remove Programs it is listed as "Microsoft ASP.NET 2.0 AJAX Entensions 1.0".

    Thanks for confirming; that's pretty much how I expected it to be listed.  But it's not there, despite the fact that it is installed and working (aaauugh!)  Is there a "plan B" for uninstalling?  And if plan B is manually removing stuff, can somebody give me a list of everything I need to remove (including files, registry entries, anything else)?

    Friday, January 12, 2007 2:33 PM
  • User1119954915 posted

    You can try MsiSpy and MsiZap to remove it from your system

    http://www.google.com/search?complete=1&hl=en&lr=&q=msispy+msizap

     

    Friday, January 12, 2007 6:13 PM
  • User-723195338 posted

    same problem here,

    when compiling with WAP, the problem does not occur.. strange..

    Sign me in for the fix also.. thanx!

     

    Monday, January 15, 2007 1:41 PM
  • User1270845582 posted

    I have had the same problem here, took me a little to figure out what was going on, please sign me up for the fix too.. cheers

    Tuesday, January 16, 2007 9:58 PM
  • User1119954915 posted
    For those asking "sign me up"..  it's something you have to do yourself....    go back a page or two and find the email address that you have to email to request having the updated install sent back to you
    Wednesday, January 17, 2007 7:52 AM
  • User-838325193 posted

    Very good post!

    I've asked for the fix, don't know if I'll get it.

    Friday, January 19, 2007 3:30 PM
  • User1946274433 posted

     I read through the over one hundred posts here and I am still confused whether there is an answer to this problem or not.

     As with everyone else here, the newest version works great on my development machine, but when I move it over to my production server I receive the dll errors.

    I can't ask my hosting service to update their GAC, and I can't run anything in FullTrust.  I found this out after putting the missing dlls into the bin folder on the production server and the security errors came out.

    I liked it better when everything you needed was nicely tucked into 2 dlls (atlascontroltoolkit.dll and the Microsoft.Web.Atlas.dll) and it didn't give you any problems.

    If the answers are in this thread then I apologize.  However, one last summary of the issue and solution (if exists) for people who can't run in full trust or update their GAC.

    Thanks in advance.

     

     

    Sunday, January 21, 2007 1:55 PM
  • User-1609241555 posted
    I've checked both the boxes when doing a publish and still am getting this error on the server hosting the site.  Anything else to do?  Can someone post that other build?
    Monday, January 22, 2007 10:40 AM
  • User1603054497 posted

    Well, I started this topic 123 replies ago so I thought it would be appropriate for me to wrap it up as well.  Go get the RTM version. [:)]  I can testify that the RTM build fixes this problem.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 24, 2007 4:19 PM
  • User-557514964 posted
    I unistalled the RC and installed the RTM and still having same problem. When looking at the .dll version between RC and RTM they look the same. Did they bump up the version for the RTM or is my old RC stuck in my GAC?
    Friday, January 26, 2007 2:04 AM
  • User-1634877164 posted

    Can you try doing an iisreset to restart the web-server?  It could be that the loaded assembly is cached in the process.

    Thanks,

    Scott

    Friday, January 26, 2007 3:12 AM
  • User1603054497 posted

    Just to re-enforce what Scott said, I have found in the past that when I upgrade anything that is loaded in the GAC I have to restart IIS in order for the change to take effect.  Sometimes it will work fine without the restart, but most times it is required.

    Jon 

    Friday, January 26, 2007 2:16 PM
  • User-557514964 posted

    I tried restarting IIS and/or rebooting. Did not help. What ended up working is uninstalling Ajax, then deleting the web project from production, then rebooting, then installing Ajax again, and then placing the project back.

    Friday, January 26, 2007 6:58 PM
  • User-885555185 posted

    Dear All,

     I experienced the same problem as titled. After uninstalling the RC and installing the lastest release (Jan 29's one), the situation changed from System.Web.Extensions to Microsoft.Web.Extensions as below:

    "Could not load file or assembly 'Microsoft.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified"

    I'm using Visual Web Developer Express w/o Publish function, but I tried to use both  the source to run directly and the pre-compiled things (by VS2005 command prompt) with the "-u" options still got the same error. May anyone help?

    Thanks

    Friday, February 2, 2007 12:36 AM
  • User1616199771 posted

    I also used the aspnet_compiler with '-u' option, but this does not build dll's into a \bin folder.  It merely precompiles to

    " C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\some_directory". Or so it appears. At least that is the only change I can see. How is one to 'deploy' this if this is the case?

    Again, the problem probably lies between the keyboard and chair in my case, [:P]  but I need a little guidance...

    TIA 

    Saturday, March 10, 2007 12:11 PM
  • User525300860 posted

    Hi Scott,

    could u plz help me in solving this problem. I have installed asp.net ajax 1.0 in my machine and same version has been installed in the production server. Whenever i precompile website withe "allow this precompiled web site to be updatable" option unchecked, i am facing this problem. I understood that this was a bug with ajax 1.0 RC and fixed in RTM.but i am still facing this problem. I tried all the options suggested like restarting IIS, rebooting etc but no luck. Please suggest me some workaround.Thanks in advance

    shiva

    Friday, June 1, 2007 3:59 PM
  • User-666544324 posted

    stardust25: You likely have a reference to "microsoft.web.extensions" in a config file or in the register tag of your page. The RTM version of Atlas is System.Web.Extensions.dll

    ksasp: There's a walkthrough on publishing web sites on msdn. Hope this helps: http://msdn.microsoft.com/en-us/library/1y1404zt(VS.80).aspx

     

    Monday, June 4, 2007 3:22 PM
  • User-666544324 posted

    ShivaKrishnaK - This is fixed in the RTM version of ASP.NET AJAX. Please make sure you have the correct version installed, and recompile your site. Thanks!

    Monday, June 4, 2007 3:28 PM
  • User525300860 posted

    Hi chrisri,

    Thank You very much for you reply, I checked and found that the installed version is  ms ajax 1.0 in my system as well as in production. I have never installed any betas or RCs of atals because of policies of my organization will not allow. I checked in add/remove programs and "Microsoft asp.net' folder of "program files" as well. Both places are showing only latest version is installed ("System.web.Extensions"). Could u please help me in solving this problem. Everybody in my team except me were against using ajax as they dont believe that it is stabilized. I pushed everybody to use ajax and now we arein very nasty situation because of this problem. EspeciallyI am in  very bad position. Please help me in solving this problem. anyways thanks for your time and help

    shiva

    Tuesday, June 5, 2007 1:38 PM
  • User-544648519 posted

    Shiva,

    I have seen this before when a previous version of the AJAX extensions were not cleanly uninstalled before installing the RTM version.

    1. Restart IIS (iisreset) - make sure the System.Web.Extensions assemblies in the NI cache and GAC are closed. You can use a tool like Sysinternals Process Explorer to see which DLLs are loaded: http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx.
    2. Uninstall the AJAX extensions.
    3. Verify that the System.Web.Extensions and System.Web.Extensions.Design were removed from the GAC_MSIL (%windir%\assembly\GAC_MSIL) via cmd.
    4. Verify that the System.Web.Extensions was removed from the native image cache (%windir%\assembly\NativeImages_v2.0.5.0757_32) via cmd.
    5. Install the RTM: http://www.microsoft.com/downloads/details.aspx?FamilyID=ca9d90fa-e8c9-42e3-aa19-08e2c027f5d6&displaylang=en
    6. Verify that the assemblies were correctly installed into the GAC and NI cache. Make sure they are the RTM versions (compare to versions located in %programfiles%\Microsoft ASP.NET\ASP.NET AJAX Extensions\v1.0.61025\).

    The RTM version does fix this issue, but it is very important to make sure that you know that previous versions were cleanly uninstalled and that the RTM version is installed.

    Friday, June 8, 2007 9:37 AM
  • User-856764066 posted

    here too the same issue...... we tried both Ajax script method and Ajax frame work....

    session values get empty.... any clue ? how to get rid of it

     

    MS build functions did not work on our production srever

    Friday, August 31, 2007 10:26 AM