With the release of the ASP.NET AJAX v1.0 RTM, is DASP planning to install this on servers? ... or will we still need to use the non-GAC installation method? Thanks, Kyle
F.Y.I. Scott Guthrie currently, posted today, recommends: We recommend deploying ASP.NET AJAX 1.0 in the GAC rather than the \bin directory. The main reason for this is so that in the event we need to-do updates (security fixes, critical updates, etc), we have a way to service/update it. Our expectation is that hosters will move pretty aggressively to install the 1.0 release on ASP.NET 2.0 hosts. Now that it is at 1.0 and fully supported, there is no reason not to (and customers are demanding it). If your app runs in full trust, then you can deploy into the \bin directory - but I'd really recommend keeping it in the GAC.
I've been successfully using Ajax here at DASP for one month now, putting the System.Web.Extensions.dll into the Bin folder. Everythinghas been working great. All of a sudden this morning, I get this error message: Server Error in '/' Application. -------------------------------------------------------------------------------- Configuration Error Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately. Parser Error Message: Could not load type 'System.Web.UI.Compatibility.CompareValidator' from assembly 'System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Source Error: Line 143: </controls> Line 144: <tagMapping> Line 145: <add tagType="System.Web.UI.WebControls.CompareValidator" mappedTagType="System.Web.UI.Compatibility.CompareValidator, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> Line 146: <add tagType="System.Web.UI.WebControls.CustomValidator" mappedTagType="System.Web.UI.Compatibility.CustomValidator, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> Line 147: <add tagType="System.Web.UI.WebControls.RangeValidator" mappedTagType="System.Web.UI.Compatibility.RangeValidator, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> Source File: E:\web\citrusprice\htdocs\web.config Line: 145 -------------------------------- Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.42 '=== I'm guessing I need to change my web.config to point to the version in the GAC. Can anybody tell me how? Any advice will be appreciated. Polybius
Check out Scotts latest Blog post: http://weblogs.asp.net/scottgu/default.aspx 1) Get the Validator and place the DLL with your others in the apps /bin/ folder. http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx 2) I couldn't get the new tagMapping section to work until I moved it within <pages>, which resolved the app error: <system.web> <pages> <controls> </controls> <tagMapping> </tagMapping> </pages> </system.web>
wisemx - I think you've saved me once again. I'm going to do what you suggest, and will let you know how it works. Polybius
I think DASP folks must have already put in the GAC last night, because my application was broken this morning. It had been working well with the .dll I had kept in the Bin folder. Right now I'm struggling to get RTM installed and working on my development machine, but running into problems getting my web.config converted from RC to RTM, scratching my head. Meanwhile, my production website at DASP is down. Not a good day. Thank god Wisemx was around today, or I would have beencompletely lost. So the question lingers, did DASP put the System.Web.Extensions.dll in the GAC last night? Polybius
I just nowinstalled the Ajax RTM on my dev machine. I followed the directions of wisemx(Mark) posted above,and now everything is working great, both on my dev machine, and mysite at DASP. Many thanks once again, wisemx. Polybius
Yes.We contacted Scott Guthrie and confirmed the official Microsoft stance on whether hoster should install the dll into the GAC. Based on Scott's suggestion, we have made the decision to installed the AJAX 1.0 dlls into the GAC on all servers last night. We have not officially announce this yet because we are waiting for some final testing and documentation. Bruce DiscountASP.NET www.DiscountASP.NET
Thanks, Bruce. Seems like the best way. Everything seems to be working well for me with it in the GAC, now that I'm using the AjaxRTM. Polybius
I just want to thank you guys for helping me today for the second time since being with discountASP.NET only a week ago, just by reading your forum entries. Today I received the same System.Web.UI error message as Polybius. THANK YOU! THANK YOU! THANK YOU!
wow.. this post is getting a lot of attentions today.. this is great!! Bruce DiscountASP.NET www.DiscountASP.NET
By the way, we have couple staff members to thank, Aristotle - tested the component and installation procedure as well as compiled some test code Dave (our night shift admin) - who's responsible for installing the dll into the GAC of all servers. Bruce DiscountASP.NET www.DiscountASP.NET
I don't use my account at DASP too much because of time issues (I usually have zero free time) but this thread exemplifies why DASP are a fantastic web host (which is something coming from me as I also own a hosting business!). Here we have a red hot new release and the people at DASP are actively working to deploy it, helping customers, etc. Fantastic. Sorry if this is the wrong place but you all deserve a pat on the back. Keep up the good work!
I don't understand the praise for DASP in this thread. DASP deployed an unannounced upgrade to production servers, give webmasters zero time to prepare their sites. In fact, the only way you know something happened is to find your sites (and sites of your clients) broken, then dig around to find this thread. This is not an example of good customer service. I'd like to have a host that announces upgrades in advance, so that I don't learn about them by angry clients wondering why their sites are down. Further, as stated in Scott's post, there will be a .Net patch following in a few weeks to correct these issues - considering this why would one upgrade now knowing all sites using ajax will need to apply a temporary work around? No real question here, just frustrated by how this was done.
Michael, don't forget that we were warned a long time ago that DASP has a policy of not deploying anything less than RTM to the GAC. They were good enough to make a way for us early users to enjoy the benefits of Ajax before RTM. In a sense the only thing that broke was something they told us they would not vouch for or support. I'm more and more impressed by DASP. I'll also add that this forum, and having someone like Wisemx here really adds to the power of DASP to me. Polybius
This has nothing to do with what happened. There was no System.Web.Extensions in the GAC - they were loaded in /bin folders. This was nothing special done by DASP, bin folders are a feature given to every account. A dll in the GAC trumps a dll in a bin folder. There is no config setting to change this. Why Microsoft did this I do not know, but the version, namespace, pubkey, etc of RC and RTM are exactly the same. This means when DASP changed the GAC they broke any site using RC. I'm quite disappointed - DASP should have some basic policies in place to notify users of changes; either they don't or they don't follow them. They also should understand asp.net enough to know what they were doing would have an effect on every site. There was no reason DASP couldn't have waited a day or two and sent an email to all customers to allow them time to prepare. Honestly? There was no reason they could wait a week or more until the related .net framework patch was released. Bottom line, they read the same blog post I read, and knew that this would break sites, the fix wasn't in yet - and choose to go ahead without alerting customers. If you think that's wonderful service, then we have different definitions of the term.
Hi, I didn't mean to spark off any controversy. Basically, if you are using non rtm releases, what do you really truly expect your supported rights to be? When the rtm hits that's different but before then, everyone should just be playing. If you were running production code prior to rtm, then more fool you - ctp = beta. I'm not fussed about emails, I read the forums. As far as AJAX.NET goes, which other hosts have this ready to run, out of a box at this time at the price point DASP provide? Right, back to lurking )
Here's new blog entry in Scott Guthrie's blog regarding how to fix the problem w/ the backward incompatibility between the beta / released version. http://weblogs.asp.net/scottgu/archive/2007/01/25/links-to-asp-net-ajax-1-0-resources-and-answers-to-some-common-questions.aspx Hope this helps. Bruce DiscountASP.NET www.DiscountASP.NET