Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).
Related
Spoiled by Ruby on Rails (3), I expect all my HTML output to be automatically encoded.
I asked this question about script exploits a bit earlier and am now wondering, is there some setting, plugin or extension for ASP.NET that will automatically cause all HTML to be HtmlEncode'ed or do I have to be really careful and ensure that on my own?
Various ASP.NET controls automatically encode HTML with HtmlEncode (and a few do URL encoding with UrlEncode), but it's not universal. Here's a list of controls and what encoding (if any) they do automatically. I don't know if it's updated for .NET 4.0 or not:
Which ASP.NET Controls Automatically Encodes? (this link will ask you to save the document)
This is the blog that the above document is from:
http://blogs.msdn.com/b/sfaust/archive/2008/09/02/which-asp-net-controls-automatically-encodes.aspx
It was originally posted in Sep 2008, so it's probably current for 2.0, but not necessarily 4.0. Still a useful resource to have, though, IMO.
You should also look at the Microsoft Anti-Cross Site Scripting Library 3.1.
As pointed out by balexandre, it appears the Anit-XSS library is now part of the open source Web Protection Library:
Microsoft Web Protection Library
Also, OWASP is a good resource for security information, and they have an Enterprise Security API project (ESAPI) that is available (to varying degrees) in various programming languages. The .NET one is not complete yet, I believe.
OWASP Enterprise Security API
If you're using ASP.NET 4.0 with WebForms, then using the code nugget <%: %> will automatically HtmlEncode the output. If you're using the Razor engine, then all data is HtmlEncoded by default.
By default, ASP.Net will not accept postbacks where a Inputcontrol contains html elements. This behaviour is set at a page level by the property ValidateRequest.
If you want to accept postbacks containing html, you need to set ValidateRequest to false and HtmlEncode the userinput yourself on the server before further proceeding
I use the ASP.Net ScriptManager to load the scripts needed for calling WCF services via HTTP/JSON. I am optimizing the total size of my pages (including scripts) and I see that Microsoft's AJAX library is the biggest file that I have at 96KB. Is there anyway that I can get a version of this file with just the features I need loaded?
Or since I already have jquery, should I use that to call my WCF JSON service instead?
Cheers,
Jon
WCF JSON services degrade gracefully down to working as a standard webservice, so you should have no problems using jQuery to post and retrieve data from them. You may lose some of the integration bells and whistles, but as someone who has taken the path you're suggesting, I can say that I don't miss it at all.
The only problem might be if you're using advanced WCF feature like 2 way connections, or guaranteed connections.
I'm planning a ASP.NET project for which I'm going to use AJAX. I'm researching all the available technologies for doing so in the .NET world.
I need a solution that is well documented and stable.
The current solutions I've found are:
1. ASP.NET AJAX UpdatePanel
2. ASP.NET AJAX with Web Services + JQuery
3. JQuery + Http Handlers
In the second and third solutions the backend would only send JSON or XML messages to the client.
In my experience the best way to go is JQuery with WCF with JSON webservices.
The reason is:
ASP.NET ajax is gives you alot for free in terms of coding but is bloated from the start and needs to be stipted and slimed. On the other hand you have JQuery that you needs more development but is light weight. JQuery has a great plugin library as well.
XML is to slow, JSON is fast.
Thats how I would do it today.
All will work but I've had most performance and stability with using JQuery and a script service.
An update panel will work but as its designed to work in the general case it can be a little bloated if you aren't careful. One reason being is that it posts the viewstate back with each update.
I recommend you check out the site: encosia.com as it has a number of posts on how to use script services and page methods. Then you can make a more informed decision. I would say that I've not used page methods and probably won't but that's entirely for personal reasons.
One other thing to consider will be any mvc you may end up doing. The general consensus is that it's a whole lot easier with JQuery. Added to that Microsoft have officially adopted it and also provide intellisense in VS2008.
All compelling reasons to include at least some of it in your project. In mine I only use the built in ScriptManager when I absolutely have to.
HTH!
S
I'm wondering if someone can point me in the right direction. I've got an ASP.NET web application. And there's autogenerated portion of JavaScript in every page that handles postback. Sometimes that javascript is surrounded by
<[CDATA[ ... ]]>
, while on the other machine it may be enclosed in simple HTML comment like
<!-- ... -->
So, I'm searching for an answer or a clue about what may cause this difference. Any ideas?
Answer:
The cause is version of .Net framework. Was hard to find because I used installer to setup everything, from web server to framework and application sources. Not very obvious line in httpd.conf caused latest framework to be used.
Story behind: MS changed JS generation from version 2.0 sp1 to use CDATA.
Thanks for replies.
You didn't said about what do you mean by different machine. If different machine is used for web server, then it's because of .NET framework version. As I recall, prior to .NET2.0sp1 CDATA wasn't used.
My guess is that it is not the machine that matters but the user's browser that may be different. Javascript will be rendered differently for "down-level" browsers which do not support Javascript. So, the JS section will be enveloped by an HTML comment tag.
I'm using an older version of ASP.NET AJAX due to runtime limitations, Placing a ASP.NET Validator inside of an update panel does not work. Is there a trick to make these work, or do I need to use the ValidatorCallOut control that comes with the AJAX toolkit?
I suspect you are running the original release (RTM) of .NET 2.0.
Until early 2007 validator controls were not compatible with UpdatePanels. This was resolved with the SP1 of the .NET Framework.
The source of the problem is that UpdatePanel can detect markup changes in your page, but it has no way to track scripts correctly. Validators rely heavily on scripts. During a partial postback, the scripts are either blown away, not updated, or not run when they are meant to.
In early betas, MS had the UpdatePanel try to guess what scripts needed to be re-rendered or run. It didn't work very well, and they had to take it out.
To get around the immediate problem, Microsoft released a patched version of the validator classes in a new DLL called Validators.DLL, and gave instructions on how to tell ASP.NET to use those classes instead of the real ones. If you Google for that DLL name, you should find more information. See also This blog post.
This was a stop-gag measure and you should not use it avoid it if possible.
The real solution to the problem came shortly after, in .NET 2.0 SP1. Microsoft introduced a new mechanism to register scripts in SP1, and changed the real validator classes to use that mechanism instead of the older one.
Let me give you some details on the changes:
Traditionally, you were supposed to register scripts via Page methods such as Page.RegisterStartupScript() and Page.RegisterClientScriptBlock(). The problem is that these methods were not designed for extensibility and UpdatePanel had no way to monitor those calls.
In SP1 there is a new property object on the page called Page.ClientScripts. This object has methods to register scripts that are equivalent (and in some ways better) to the original ones. Also, UpdatePanel can monitor these calls, so that it rerenders or calls the methods when appropriate. The older RegisterStartupScript(), etc. methods have been deprecated. They still work, but not inside an UpdatePanel.
There is no reason (other than politics, I suppose) to not update your installations to .NET 2.0 SP1. Service Packs carry important fixes.
Good luck.
#Jonathan Holland: What is wrong with using Validators.dll?
Since they replace the original classes, you are quietly bypassing any bug and security fixes, enhancements, etc. that Microsoft might release in the future (or might have already released). Unless you look carefully at the web.config, you might never notice that you are skipping patches.
Of course, you have to evaluate each situation. If you are absolutely stuck using .NET 2.0 RTM, then Validators.dll is better than nothing.
#jmein
Actually the problem is that the Validator client script's don't work when placed inside of an updatePanel (UpdatePanels refresh using .innerHTML, which adds the script nodes as text nodes, not script nodes, so the browser does not run them).
The fix was a patch released by microsoft that fixes this issue. I found it with the help of Google.
http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx
If for what ever reason you are unable to use the udpated version of the ASP.NET validator controls is actually very easy to validate a validation group yourself, all you need to do is call
Page_ClientValidate("validationGroupName");
Then you can use the PageRequestManager execute the validation as you need.
Definately using the updated validation controls is the way to go, but I'm quite partial to JavaScript ;)