i have a classic asp page that calls an exe that does some complex processes. I want the asp page to wait until the exe completes processing. I tried shell. no luck. any solution?
-Vivek
AspExec used to be a popular tool, but it doesn't seem like the company sells it anymore. You can still find it here for download. See this article for using it, as well as other options.
Related
I have several projects in asp.net and in all of them I have the same problem. The first time I access an aspx page the load is very slow. Once I close the page and reopen it, the load is very fast. Why is the first load so slow? Can I change any settings in IIS?
Thanks
I have read a lot of documentation but I am not an expert in this and I have not gotten any progress.
By default, asp.net web pages and code files are compiled dynamically when users first request aspx page from a Web site. After pages and code files have been compiled the first time, the compiled resources are cached, so that subsequent requests to the same page are extremely efficient.
More information about asp.net dynamic compilation:
Understanding ASP.NET Dynamic Compilation.
How to: Precompile ASP.NET Web Sites for Deployment.
Ok, so several issues here.
You don't mention if you are talking about your developer computer - say hitting f5 to run the site.
next up, are you deploying a asp.net web site, or a asp.net web site application?
With a application then the compile of the code and pages occurs on YOUR computer, and the .dll's are built by Visual studio (VS). So, at deploy time, then there is a first-time delay, but it not all that long - maybe 5 seconds, and that's as app pool etc. spools up.
However, if you deploy a asp.net web site? Then unlike an "application", the source code (vb, or c#) pages for code behind are included, and deployed to the web site. And this means that IIS does the compile of pages - and often on the fly. This deployment model is often preferred by many, since you can open even the live files on the server, edit one line of code behind, hit save. On next page use, it will re-compile.
If you use an application, then as noted, IIS does not do the code compile, and in fact not even the source code is deployed during a publish. Of course, while there are many benefits to an "application", the ONE big downside is of course that you require a full site re-publish EVEN if you change just one line of code behind.
So, while an application has "some" delay for the first site use, it tends to be considerably less of a delay compared to when using/deploying a web site. (Since then, IIS has to compile the code, and in fact has to compile each page used).
You don't mention/note which deploy model and approach you are using here.
As noted, while the web site option is certainly less efforts to make a change to one page or a bit of code, I still far prefer the "application" approach, since things like "referencing" additional class library and code, and even being able to say use the Rosyln compiler (which may well not be on the server and available to IIS). As a result, I prefer and use an "application" despite the extra efforts required come publish time, but the benefits at developer time far outweigh the downsides.
And of course, one benefit of the "application" approach, is you do as a general rule get far faster web start up times.
I'm having some problem finding the source of the problem, but here it goes, maybe you know the magic answer.
I'm running this asp.net site with an AJAX updatePanel on my local machine, and everything works just fine, since it's where I developed it. Now, a few days ago, I uploaded the files to my web-host and assigned every single DataBase, and there is no error messages, even though it's still set to debug mode. There is a problem though, whenever I click an element which triggers my asp.net AJAX updatePanel to update, the whole site is updated(which it should not, only the Panel), and my jQuery's (document).ready is called every time as well.
Thank you for any help, I have no idea why this does not work online, nor' do I know why it does work on my local machine.
I have choosen not to upload the code, since I have no idea where the problem might lie, please feel free to ask for the code and I shall reply :)
Have you checked that your web host either:
a) Is running .net 3.5
b) Has the Ajax extensions for .net 2.0 installed
...and that you are testing locally with the same?
I am going to develope a module in ASP.Net. In this module I want to get the list of drives of the local system where this page is displaying. I have already tring with System.IO.... etc. but it gives me the server drives.
I want to get the list of LOCAL drive where page is displaying on server drives.
Thank you.
Do you mean the client's computer's drives?
That is not possible.
EDIT: However, it is possible with ActiveX or a browser plug in.
This absolutely cannot be done with neither server-side ASP.NET, nor with client-side JavaScript. You can try writing an ActiveX "control" (or how are these called?) or Java applet.
Fortunately you can not do that.
This is impossible, since your ASP.Net code runs on the server. The client only sees the rendered page (HTML and javascript).
Remember: your C# or VB.Net code runs on the server for the explicit purpose of sending html/javascript to the client browser. It does not get to peek directly at the "local" system, and the only thing the "local" system knows about is the html/javascript rendered on the server. That's just how the web works.
Furthermore, javascript runs in a sandbox that does not include any way to enumerate the local drives. This is by design.
So the only way to do this is via plug-in like flash, silverlight, or activex.
You can write a .NET control which is downloaded from your website to the clients' PC and looks at the drives there. As this could be abused (you could steal the users' files) you will have to convince the user to download the control in the first place. Look here for more info:
ClickOnce Deployment overview
I'm trying to do load testing against an ASP.NET web site and I need to be able to parametertise field value of a page to test different code paths.
I had great success with JMeter when load testing a JSP web site before. However, because ASP.NET encodes all form values in the ViewState, changing control values does not really work.
I Googled this problem and people said the web testing tool in Visual Studio Team Tester Edition works well with ASP.NET pages. However, it cost quite a bit so I am just wondering does anyone know how to get around the ViewState issue with JMeter or WAPT?
I've used WebLoad before. Its scripting language is basically JS, so you may be able to find controls on the page using JS and invoke them as part of your load script.
WebLoad is free.
I've figured out how to do this, basically you cannot simply record a static script with JMeter. What you need to do is to record a request, send it, capture the viewstate in the response and send the viewstate back in next request.
If you need more details, I've documented how to do this along with some screenshots on my blog post
As webapps get more complex (ViewState, AJAX, etc) it is tougher and tougher to use traditional load testing tools. That's because they try to jam a ton of virtual users on a very small amount of hardware resources.
My company, BrowserMob, took a different approach. We build a load testing service that uses real web browsers to drive load. Your scripts end up being essentially functional tests (specifically Selenium scripts). My background has been in Selenium for some time (I created Selenium RC and founded OpenQA.org), so as soon as cloud computing made it possible to rent the 5TB+ of RAM necessary to do this, I jumped on the idea :)
I'm new to ASP.net but not to C#, .net or Web Development.
In PHP it was nice to be able to go right to the browser and refresh whenever I made a change. Using ASP.net with VS08 however seems a bit awkward.
Should I launch a development server and keep it open, refreshing the browser when I make a change or should I close the development server between editing code?
Sorry if this sounds silly but I'm just not sure what the "accepted" practice is here.
When developing with Cassini, I always just let it run as it saves the startup time whenever I want to debug. It doesn't hurt to do so, it'll always reflect the current built DLLs and works pretty well.
You have two options when going from Visual Studio to the browser. The first is to debug the application by pressing F5 and running it. The second is to choose the "View In Browser" command (or use the keyboard shortcut Ctrl+Shift+W). The latter doesn't attach debuggers to the web server which makes it much faster than debugging but doesn't support things like code-behind break points or breaking into code upon unhandled asp.net excpetions.
For fastest development, minimize the number of times that your web server is started and how many times you attach the debugger to the web server.
I launch my dev server and then leave it running all the time. Instead of closing down the dev server, I detach the debugger, and when I need to step through code I attach it again. This gives me the best of both worlds: saves me the web server startup time AND runs pages fast most of the time.
Depends what stage of development I am in.
If I am adding lots of files (something that you can't do in Debug mode), changing lots of code in App_Code (which will reset the app) or adding lots of components from the toolbox, then I will tend to leave Debug off.
Once I start actively debugging a site, then I will leave it on as much as possible.
I use IIS even for development so there is no "launch" of the web server at all. That being said, I will typically alt-tab between code I'm working on and the browser window while I am fine-tuning HTML, Ajax calls, or the code behind. Bigger changes require a restart and you will receive a message that the code is no longer in synch with the web site (during an exception) when you must restart.
The bottom line: you can debug while running in an ASP.NET application and, as long as you can get away with it, it is an effective way of tuning your software.