I was changing around the Directory Security for an ASP.net page. In the process of doing this, the IUSR account was removed. After fixing the problem, I wanted to set the Anonymous Access for the website back to IUSR. Unfortunately, I needed the password for the IUSR account in order to do this.
WindowsITPro has a great solution posted for retrieving the username and password information for IUSR.
Just in case that link ever goes down, here is the solution: Take the following code, save it in NotePad as a .vbs file and run it.
Worked like a charm
So I created a Windows Service (based on this) that is designed for one purpose: to call a Web Service on my ASP.net application every 2 minutes that will perform certain jobs (like sending emails, other maintenance). In the config file for the service there is an appsetting labeled <add key=”Namespace.WebServiceName” value=”http://WebServiceAddress/JobRun.asmx”/>.
According to this article, by changing the key for this appsetting before installation of the Windows Service, the Windows Service would call the Web Service identified by the key. So it was written.
In the the Solution Manager in VS 2003, there is a Property under the Web Service called “URL Behavior”. This can be set either to “Static” or to “Dynamic” (see here for more official info).
- When set to Static, the URL that is entered for this Web Service when the Web Service is first referenced in VS is the url that will always be used.
- When set to Dynamic, the Web Service will always use the URL located in the config file | appsettings.
Obviously, in order for the Windows Service to function properly (ie: call the Web Service that is indicated in the Config file), the URL Behavior property of the Web Reference must be set to Static. Unfortunately for me, during my editing of this file and changing of the Web Reference, I forgot to set my Web Reference from its default behavior of Static to its correct behavior of Dynamic. Thus wasting many of my hours and killing many of my brain cells. Don’t let it happen to you.
This article from The Code Project gives instructions on how to set up your ASP.net project so that as long as the user is logged in with the browser set to your site, the page will automatically refresh a few second before the session will expire (and will continue to do so indefinitely, as long as the user remains on your site).
The best part is that it is just two lines of code:
private void Page_Load(object sender, System.EventArgs e)
Read about The Session Defibrillator for more implementation information.
See the article with this title from MSDN Magazine’s March 2005 issue.
The basic flow of the article:
- Create a Web Service that will be called to run the jobs
- Create a Windows Service that will call the web service at specified intervals. Create installation package.
- Create classes that inherit from a Job class for each job that will need to be run
- Set up interface with database to store job timing, populate the job classes when needed
- Hook up the jobs to the web service
It does seem to be a little bit more complicated than is needed (the core of it all is the Web Service and Windows Service). However, it does give a very scalable solution for scheduling jobs in ASP.net – once the initial setup is defined, adding jobs will be pretty simple and it should work pretty well.
In a 4 Guys article entitled Why I Don’t Use DataSets in My ASP.NET Applications and in a blog post, Scott Mitchell discusses the merits of using DataSets to retrieve data in an ASP.net application (or lack thereof). Here’s the gist of it:
Although DataSets provide many useful builtin functions, they add a large amount of overhead (which will increase the more data is retrieved). Check out A Speed Freak’s Guide to Retrieving Data in ADO.NET for more conclusive numbers backing this up. The increase in performance using a DataReader (or SqlDataReader if you are using Sql Server) more than offsets the loss of functionality. So Scott concludes (though many of his other readers disagree).
Personally, I agree. So far I have exclusively used SqlDataReaders in my development efforts. (Though as soon as I start working more with Web Services, XML and Desktop I will probably start to delve in to DataSet-land).
Update: Scott has posted a new article on 4Guys: More On Why I Don’t Use DataSets in My ASP.NET Applications, responding to 60+ comments that were made on the original article. If anything, he is now even more adamant that DataReader is the only way to go.
In this blog post by Scott Mitchell, Scott gives a review of the issues brought up by this article, discussing ways in which a page’s ViewState in ASP.net could be used to compromise a site. ViewState is encrypted by default (unless you set EnableViewStateMac to false, which you shouldn’t need to do). If a ViewState is posted to a page that did not encrypt it, the server will throw an error. However, if a ViewState is posted to the same page (perhaps with different querystring parameter settings), the page may accept the posted VIewState and use its data:
The point is, don’t trust view state (or the data that is put there by Web controls, such as the DataGrid). That is, if you have important information, such as pricing data, it’s OK if it is placed in view state (such as in a row in a DataGrid), but don’t grab the pricing data to charge by just poking around the view state (as in programmatically accessing the contents of a DataGrid). Instead, if you need to get pricing information (or any other important bit of information) for the final order processing, it is imperative that you requery the database.
You have been warned.