once your users have been authenticated, you can focus on authorizing what resources you would like them to have access to. the following sample shows access being granted to "jkieley" and "jstegman," while everyone else is denied access.
as a refresher, impersonation refers to the process whereby an object executes code under the identity of the entity on whose behalf it is performing. in asp, impersonation will allow your code to run on the behalf of an authenticated user. alternately, your users can run anonymously under a special identity. by default, asp .net does not do per-request impersonation. this is different from asp. if you rely on this capability, you will need to enable this in your web.config file as follows:
another key area you may need to focus on for your migration efforts is that of data access. with the introduction of ado .net, you now have a powerful new way to get at your data. since data access is a large topic in itself, it goes beyond the scope of this article. for the most part, you can continue to use ado as you have in the past, but i highly recommend taking a look at ado .net as a means to improve your data access methods within your asp .net application.
preparation for asp .net
now that you have been exposed to most of the issues you are likely to encounter, you may be wondering what things you can do today to be better prepared for them when you finally move to asp .net. quite a few things can be done that will make the process smoother. many of these suggestions will be beneficial to your asp code even if you do not move to asp .net until sometime in the future.
use option explicit
this has always been a good idea but still not everyone uses it. by enforcing variables to be declared in asp by using option explicit, you will at least have a handle of where everything is defined and how your variables are being used. once you move to asp .net, i suggest using option strict. option explicit will be the default in visual basic .net but by using the more enforcing option strict, you will ensure all of your variables are declared as the correct data type. doing this definitely requires a bit of extra work but, in the long run, you will discover that is was well worth it.
avoid using default properties
as we discussed, default properties are no longer allowed. accessing your properties explicitly isn't really that hard to do anyway. it will make your code more readable and also save you time in porting in the future.
use parentheses and the call keyword
use parentheses and call statements wherever possible, as detailed earlier in this article. in asp .net you will be forced to use parentheses. using the call statement today will help you add a bit of discipline that will better prepare you for the future.
avoid nested include files
this may be easier said than done but, if possible, you should avoid nesting your include files. to clarify what i mean by this, you should try to eliminate any areas where you have include files that include other include files. what tends to happen over time is that your code ends up relying on a global variable that is defined in an include file somewhere else, and you are getting access to it only because you have included another file that includes the one you really need. when you migrate to asp .net, you will most likely be moving your global variables and routines into class libraries, in which case, it is much easier to do if you have a clear picture of where you are getting access to everything. you may end up having to move things around and change some routines' names that were duplicated in multiple files.
organize utility functions into single files
one strategy used in the migration process is to migrate all of the utility functions and code contained in your server-side include files into visual basic or c# class libraries. this allows you to finally put all of the code where it belongs—in objects, as opposed to multiple-interpreted asp files. by organizing your code ahead of time, you will be saving yourself time in the future. ideally, you should be able to group your sub-routines together in logical files thus allowing you to easily create a set of vb or c# classes. these are the functions that probably should have been in com objects in the first place. if you have a bunch of global variables or constants mixed in server-side include files, consider placing all of them in a single file, as well. once you move to asp .net, you can then easily create a class that will house your global or constant data. this will make for a much cleaner and more maintainable system.
remove code from content as much as possible
this is another thing that is easier said than done but, if at all possible, you should separate your code from html content. clean up functions that mix code and script throughout a function body. doing so puts you in a much better position to leverage code-behind as this is the ideal model under asp .net anyway.
do not declare functions inside <% %> blocks
this is not supported in asp .net. you should be declaring your functions inside <script> blocks. see the structural changes section earlier in this article for an example of this technique.
avoid render functions
as discussed earlier, you should avoid using "render functions." if you can change or prepare your code now, you should be using response.write blocks when constructing these types of functions.
explicitly free resources (call close methods)
make sure you explicitly call any close() or cleanup methods that exist on the objects and resources you may be using. we all know how forgiving visual basic and vbscript are when it comes to cleanup. normally, they are pretty good at cleaning things up immediately but, as we move to .net and the garbage-collected world, one cannot be sure exactly when objects will be cleaned up. if you can cleanup and release your resource explicitly, you should.
avoid mixing languages
if possible, you should avoid intermixing server-side vbscript and jscript in the same page. in general, this is a poor programming practice anyway. this is also a migration issue for asp .net in that it requires only one inline <% %> language per page because of the new compilation model. you can continue to emit client-side script in the same manner as you are used to.
summary
as you have seen, there are a quite a few things you need to be aware of before moving your application to asp .net but most of the changes i have outlined should be relatively easy for you to implement. if you have a large site, you will be amazed when you are finished with this process at the amount of dead code, inefficiencies, and outright bugs you came across and fixed. additionally, you will be able to take advantage of the many powerful new features added to asp .net and the .net platform in general.
