I have successfully downloaded and installed AJAX framework, and the control toolkit.
While trying to insert any AJAX controls such as UpdatePanels or ScriptManagers into an existent ASP.NET Web Site (which currently has no AJAX functionalities) I get the following error:
"Attempret do read or write protected memory. This is often an indicator that other memory is corrupt."
So as a test, I've created a brand new project, as an ASP.NET AJAX-Enabled Web Site, as follows:
And in the default page of this project there is an ScriptManager already, and I've been able to insert an UpdatePanel, do a little test with a label and a button updating its content to the current time.
The question is: What does an "ASP.NET AJAX-Enabled Web Site" have that an "ASP.NET Web Site" does not that prevents me from adding AJAX controls ?
Do you have more than one version of the AJAX libraries. Often times, the versions can be different between what you have set to use in the configuration file and the controls you are slapping on the page. That is the first place I would check.
You also need to make sure you have the correct version of both AJAX and the control library. This can be you downloaded an old control kit and are using the latest .NET framework, as much of the AJAX functionality has been included in .NET 4.0. Or it can be downloading newer bits and trying to use them with 2.0.
As far as I remember (it's been a while since I used AjaxControlToolkit) this error occurs when you attempt to modify the response stream from your code behind (ie: perform a Response.Write(); , or Response.End(); etc etc...
if the method your AsyncPostback trigger is calling is doing any kind of response stream modification then comment it out and try it again as a "proof of concept"..
hopefully this gets you going on the right track.
Dave
Related
In my current ASP .Net Core 3.x project using Razor Pages there is a "Reports" page. Each report is a separate assembly on a server. When activated, the client downloads the report's markup (HTML + JS + CSS) through API and renders it dynamically on a page. This works perfectly and makes each report to have it's unique UI with specific validation rules, external requests, etc., since custom JS is used.
Now I'm planning to make a new project using Blazor with the same functionality but this time without JS. Only pure C#.
The only way to render this kind of dynamic content that I've found is through manual RenderTreeBuilder logic. But it seems to be very low-level for this task and that sign saying "These types should be considered unstable and subject to change in future releases" makes me a bit nervous.
So the idea is to dynamically download the entire assembly for the report (or a .zip containing multiple assemblies if needed) and render it's UI with all the logic behind it. It seems that assembly lazy loading could be used for this task, but I'm not entirely sure how to use it for dynamic assembly resolution.
The issue is that this feature requires static information for assemblies that are marked as "lazy" which is not available to me, since reports are separate "plugins" in a server folder. Also it seems that ASP .Net Core hosted solution is also required and my plan was to use static hosting.
In the end I wanted to have a static Blazor SPA, hosted behind any type of a web server (NGINX, Apache, etc.) which requests reports from a API server and renders their UI dynamically with all the logic written in C#.
Any ideas where to start? My thoughts are to go with lazy loading, but not sure how to use that feature for the task.
(I believe that this applies to both normal ASP.NET web parts and SharePoint hosted web parts)
The web part has an 'export' button that renders the output as csv and sets the appropriate headers so its opened in Excel.
Hooking in the buttons click event, clearing the response, adding the appropriate headers and content types is trivial - example
However I've noticed that if this code added to a web part and a debugger attached then if there are multiple instances of this (or any other) web part on the page then neither HTTPApplication.CompleteRequest or Response.End stop the processing/page lifecycle and all the events for all the page controls still fire.
This is wasteful in this example as the other web parts don't need to run - nothing they do will get to the response.
Any way of stopping other web parts being rendered?
What about creating another page that does the actual export function for you, then have the export link merely link to this other page?
This should solve the problem of having to end the request manually, since you can control exactly what is output in the response.
Short answer: no.
Since you're doing full postbacks, HTTP response stream must contain the entire HTML page that was delivered by the server.
You can use ASP.NET output caching and refresh cache by some parameter, allowing your page to render such web parts that have their data changed.
Learn more about ASP.NET caching reading this documentation:
http://msdn.microsoft.com/en-us/library/xsbfdd8c(v=VS.100).aspx
HttpContext.Current.Response.End();
Is only for compatibility with ASP.
ApplicationInstance.CompleteRequest();
is supposed to do what you want.
I've recently become the maintainer of an ASP.NET web project. In the course of deploying some changes, we noticed that at some point the way the project deploys has changed. The project is a web application project. Currently, when I "Publish" it to my local machine, I can open the various .aspx files and see some code--a little ASP, mostly JavaScript, but the majority of the code seems to be compiled into a .dll.
What we would like is to build and deploy this application so that there is no code in the .aspx files--this is how it used to work, before the previous dev stopped maintaining it. There should be no code in the .aspx files at all, just a reference to the compiled .dll files.
Does anyone know what I'm talking about and how to set it up?
EDIT If it helps, it looks like the older version of the app just had text in the .aspx files that said "This is a marker file generated by the precompilation tool, and should not be deleted!" That is what I'm going for.
If you want to do this for your Website just Pre-compile your project for deployment only. You can check out the exact steps in this MSDN article
This will move all the codebehind files into the .dll and create .aspx.compiled files as pointers to the compiled versions in the .dll. Sounds like thats what was being done before.
The code shouldn't be visible from the client's browser.
Any code that in a code-behind will get compiled to a .dll which the pages in the application would reference. The actual code-behind files shouldn't get published with the .aspx files.
.NET code within the .aspx files shouldn't be visible on the client-side because it has no use on the client-side. It should be executed on the server-side to render HTML output to the client. If the .NET code is visible on the client-side in this case, it means the server isn't executing it and the site is essentially broken.
JavaScript code, of course, needs to be visible on the client-side. There are ways to obfuscate it, but the browser needs to see it in order to execute it. So in this case that code should be developed with the full understanding that it is publicly visible and nothing proprietary or compromising should be included in it.
JavaScript code has to exist on the client side, so that has to be on the server. Inline ASP code? I'd look into rewriting that into .NET.
In order to achieve no code in the .aspx files you need to write all the code in the code behind. You use the asp.net events in the life cycle to perform the generation of client code. For example, dynamically generated HTML and javascript could be generated in the Page_Load and written out as a Response. Any asp.net that you may use needs to be dynamically generated in the code behind with everything else.
You will still push HTML and javascript to the client, but all the code will be in assemblies/dll's except the header info in the aspx pages. I have only done this in the context of a web service ( RESTful) where I pushed out XML to an iPhone for consumption. Doing it for a full website may prove to be quite cumbersome.
It doesn't make sense to do this if the concern is security. Moving the code to an assembly is not much more secure than the aspx page. If the concern is to remain concise, I suggest moving to ASP.NET MVC 3.
I've been struggling to find an exmample of some C# code (I'm using C# Visual Studio 2008 Express) that can programmatically save an entire web page (given a URL) including the images and formatting (e.g. CSS). The intention is that in a subsequent phase I'd ship this off (not sure how yet) so it could be viewed later via a browser.
Is there an example of the most simple approach (leveraging the .NET Framework methods) to save an entire web page? Saving as one page with a subdirectory for images, or otherwise. Basically the same as what you get with browsers when you say "save entire web page".
The simplest way is probably to add a WebBrowser Control to your application and point it at the page you want to save using the Navigate() method.
Then, when the document has loaded, call the ShowSaveAsDialog method. The user can then save the page as a single file, or a file with images in a subdirectory.
[Update]
Having now noticed "programatically" in your question, the above approach is not ideal as it requires either user involvement or delving into the Windows API to send input using SendKeys or similar.
There is nothing built-in to the .NET Framework that does all of what you ask.
So my approach revised would be:
Use System.NET.HttpWebRequest to get the main HTML document as a string or stream (easy).
Load this into a HTMLAgilityPack document where you can now easily query the document to get lists of all image elements, stylesheet links, etc.
Then make a separate web request for each of these files and save them to a subdirectory.
Finally update all relevent links in the main page to point to the items in the subdirectory.
In effect you would be implementing a very simple web browser. You may run into issues with pages that use JavaScript to dynamically alter or request page content, but for most pages this should give acceptable results.
From code Project: ZetaWebSpider
It's definitely not elegant, but you could navigate a System.Windows.Forms.WebBrowser to the URL and then call its ShowSaveAsDiagog() method to save the page.
I was reading an article that shows how bad CodePlex uses UpdatePanels and how nice is StackOverflow on this matter when, for example, a user upvotes an answer/question.
I wonder if someone can point a tutorial on how to do such action.
I know some points:
Create a Web Service that gets the action value and ouputs a JSON string
Build the javascript inside <ajax:ScripManager> control to replace the correct value on the page with the new value
But, even in the first I have difficulties, I can send a JSON string, but it will always be surrounded with XML information!
Can anyone (or maybe Jeff) point to a nice "how-to" since scratch? Thank you.
Well, I doubt StackOverflow uses UpdatePanel - more likely it uses jQuery / load to simply update a div, using ASP.NET MVC as the source (rather than ASP.NET vanilla, which has a more complex page cycle).
With this approach, it is trivial... the jQuery examples tab largely says it all.
Re returning the Json - that is simply return Json(obj); from the controller in ASP.NET MVC - but personally I'd return the html (simpler).
Before you dismiss the UpdatePanel I suggest you have a read of this post I did - http://www.aaron-powell.com/blog/august-2008/optimising-updatepanels.aspx. It looks at how to optimise UpdatePanels and it can lead to some performance increases if done well.
I also did a post - http://www.aaron-powell.com/blog/august-2008/paging-data-client-side.aspx which looks at doing client-side templating with jQuery and MS AJAX. I look at how to read a web service with JavaScript and if you download the sample you'll see how to send data client-side to a web service.
But this video cast on the ASP.NET website may also be of use - http://www.asp.net/learn/ajax-videos/video-82.aspx. It's on how to extend web services for script service capabilities.