asp.net ' ASP Syntax (implicit retrieval of Column Value)
Set Conn = Server.CreateObject ("ADODB. Connection ")
Conn.Open ("TestDB")
Set RS = Conn.execute ("Select * FROM Products")
Response.Write RS ("Name")
' ASP.net Syntax (Explicit retrieval of Column Value)
Conn = Server.CreateObject ("ADODB"). Connection ")
Conn.Open ("TestDB")
RS = Conn.execute ("Select * FROM Products")
Response.Write (RS ("Name"). Value)
Changes in data types
In Visual Basic. NET, the integer value is now 32 bits. The Long data type is 64 bits.
Problems can occur when you invoke a COM object from asp.net or call Microsoft®win32®api in your custom visual Basic components component. You should pay special attention to the data types you actually need to ensure that you pass the values correctly.
Structured exception handling
Although in Visual Basic. NET, it still follows the familiar on Error Resume Next and on errors Goto fault handling, but they are no longer the best way. Visual Basic now has a mature, system-by-exception approach. They use try, Catch, and finally, and so on. If possible, you should turn to this new error-handling pattern because it uses a more robust and stable mechanism to handle application errors.
Compared to the. NET framework described earlier, COM basically does not change asp.net. However, this is not to say that you do not have to take into account COM objects and their behavior when you use them from asp.net. Here are some of the elements you should be aware of:
Threading Mode Change
Asp. NET threading mode is the multiple threaded Apartment (MTA). This means that the components that you use for a single threaded Apartment (STA) will not work reliably in asp.net unless you take special precautions. This includes, but is not limited to, all COM components that were built with visual Basic 6.0 and previous versions.
ASPCompat Property
The existing STA component can be used without any modifications. All you have to do is add the attribute aspcompat=true that indicates compatibility in the <% @Page > tab of the ASP.net page. For example, <% @Page aspcompat=true language=vb%>. Using this property forces the page to execute in STA mode, ensuring that your component is working properly. If your page does not specify this property and refers directly to the STA component, an exception will occur at run time.
Setting up Aspcompat=true will also enable your page to invoke com+1.0 components that require the use of ASP-built objects. This can be done by Objectconect objects.
Setting this property can result in a certain performance degradation. I recommend that you use it only if necessary.
Pre-bound and lag binding
In ASP, all calls to COM components are made through the IDispatch interface. Since all calls need to be handled indirectly by IDispatch at run time, we call it lag binding. In asp.net, you can still use this method to complete an object invocation if you wish.
Dim OBJ as Object
OBJ = Server.CreateObject ("ProgID")
Obj.mymethodcall
The above code works, but this is not the usage we recommend. In asp.net, you can use the pre-binding to create the objects you need directly:
Dim OBJ as New MyObject
Myobject.mymethodcall ()
Pre-binding enables your page to avoid type errors during interaction with the component. In order to use the pre binding, you need to add a reference to the project, just as you would add a COM component reference to the VB6.0 project. Suppose that the development tool you are using is visual studio.net,vs.net will create a proxy object in the background on top of the COM component, making you feel as handy as using a. NET component.
You may be able to present a performance issue. In order to ensure interoperability with COM, we introduce proxy objects, which does bring about a certain performance burden. However, in most cases, you do not need to worry about the performance degradation caused by this. After all, the CPU instructions that a proxy object executes are almost negligible compared to lengthy IDispatch calls. You've won far more than you've lost in performance. The ideal situation, of course, is to use the newly created, managed (Managed) object entirely. However, the ideal situation is unlikely to be achieved in the near future-we must protect investment in COM technology over the last few years.
OnStartPage and OnEndPage methods
You may need to spend a little more time on using traditional OnStartPage and OnEndPage methods. If you rely on both methods to access an ASP intrinsic object, you need to use the ASPCOMPAT directive and then use Server.CreateObject to create the object in a predefined manner. See the following example:
Dim OBJ as MyObj
OBJ = Server.CreateObject (myobj)
Obj.mymethodcall ()
Notice that we are not using "ProgID", but we have used the actual object type that was previously bound. To ensure that the above code works, you need to include a reference to the COM component in your Visual Studio project to create a pre-packaged wrapper class vs. Here are the only reasons why you must continue to use Server.CreateObject.
COM summary
Table 2 lists the things you must do to continue to effectively use your existing COM components.
Table 2. asp.net settings for traditional COM objects
COM Component Type/method
ASP. NET Settings/Routines
Custom STA (Visual Basic component or other component marked "Apartment")
Use the ASPCompat property, and the pre-bound
Custom MTA (or other ATL or custom COM components that are flagged as "Both" or "free")
Use pre-binding, improper but do not use ASPCompat property
Built-in objects (accessed through the ObjectContext object)
Use the ASPCompat property, and the pre-bound
OnStartPage, OnEndPage
Use the ASPCompat property, and Server.CreateObject (Type)
The above settings apply regardless of whether your component is deployed using COM +.
In ASP, the configuration information for a Web application is stored in the system registry or in the configuration database (Metabase) of IIS. In many cases, seeing or modifying these settings is a very difficult task because the server lacks the appropriate administrative tools. Asp. NET introduces a new configuration pattern based on simple, readable XML files. Asp. NET application has a Web.config file in its own directory. You can modify the Web.config file to control the application's custom configuration, behavior, and change its security properties.
Because of the habit, you might as well be tempted to open Internet Service Manager to view or modify the configuration of the ASP.net application. However, you must understand that we now have two sets of independent configuration modes. In addition to some security settings, most of the settings generated by the IIS administration tool are ignored by the ASP.net application. You need to put these settings in the Web.config file.
About. NET application settings have a dedicated article discussion, I do not repeat here. Table 3 lists some of the more interesting configurations. Keep in mind that there are a lot of configuration items that are not listed in this table.
Table 3. Web.config file Setup Example
Project
Describe
<appSettings>
Customizing application Configuration
<authentication>
Setting asp.net application support for authentication
<pages>
Setting page-related configuration
<processModel>
To set the process mode for ASP.net in the IIS system
<sessionState>
Specify some session-state options
. NET Basic class library Some classes can be used to simplify application configuration access in your programs.
If your application uses a session or application intrinsic object to store state information, it can still run correctly in asp.net. In asp.net, you have more choices for storing state-related data.
Available state management methods
Asp. NET provides more state-store touch. This enables your application to support state management within the Web farm across multiple Web servers.
You can use the <sessionState> section in the Web.config file to configure the state management options. See the following example:
<sessionstate
Mode= "Inproc"
Stateconnectionstring= "tcpip=127.0.0.1:42424"
sqlconnectionstring= "Data source=127.0.0.1;user id=sa;password=" cookieless= "false"
Timeout= "20"
/>
The Mode property specifies where you want to store the status information. The status you can select includes InProc, StateServer, SQL Server, and off.
Table 4. Session State Store information
Options
Describe
Inproc
Session state is stored locally on the server. (ASP style).
StateServer
Session state is stored in a remote or local state service process.
Sql server
Session state is stored in the SQL Server database.
Off
Session state is closed.
When you choose StateServer State, stateConnectionString works, and when you use SQL Server state, sqlConnectionString works. For each application, you can use only one storage option.
Storing COM components
One thing to keep in mind is that if you rely on a stored reference to a traditional COM component in your session or Application object, you cannot use the new state storage mechanism (stateserver or SQL Server) in your application. You can only use InProc. This is because in the. NET, those objects need to be able to serialize themselves, but obviously COM components do not. Instead, your newly created management (Managed) component can be relatively easy to implement, and of course you can use the new state storage mode.
Performance
Mention of performance, of course, there is no free to speak. The guarantee is that, in most cases, INPROC will continue to maintain its best performance. Followed by StateServer and sqlservr. You should use your application for specialized testing to make the choice that best meets your performance requirements.
Sharing state in ASP and asp.net
Another issue to note is that while your tool accommodates ASP and asp.net Web pages, you cannot share the state variables of an intrinsic session or Application object. You can replicate information on both systems, or you can provide a custom workaround before your application is fully ported. The bottom line is this: if you use little of the session and application objects, you won't be affected very much. But on the other hand, if you use a lot of these objects, you need to use them sparingly. You might consider customizing a short-term workaround to share the state.
Security is another area of concern. A brief summary of the ASP.net security system is provided here. For more detailed information, refer to the documentation for the ASP.net security system.
Asp. NET security is controlled primarily by the Security Settings section of the Web.config file. Asp. NET is coordinated with IIS to provide a complete security model for your application. Some very few IIS security settings are asp.net inherited and applied in the same way as in ASP. Of course, it also has a number of additional enhancements.
Authentication
For authentication, ASP. NET supports the different options in Listing 5.
Listing 5. Options for ASP. NET Authentication
Type
Describe
Windows
Asp. NET uses Windows authentication.
Forms
Customize the Login table based on cookies.
Passport
Microsoft provides Passport services to foreign countries.
None
No authentication performed
In addition to the new Passport authentication options, these options are the same in the ASP. Windows based authentication can be used in the following example configurations.
<configuration>
<system.web>
<authentication mode= "Windows"/>
</system.web>
</configuration>
Authorized
After your users have been authenticated, you can authorize the resources that you want them to access. The following example shows that access rights are granted to "Jkieley" and "Jstegman", and that any other person will be denied access.
<authorization>
<allow users= "Northamerica\jkieley, Redmond\jstegman"/>
<deny users= "*"/>
</authorization>
Play
Play is the process by which an object executes code with another entity identity. In ASP, playing will allow your code to run by an authorized user. Similarly, your users can run anonymously under a special identity. By default, ASP. NET is not responsive to impersonation. This is different from the ASP. If you rely on this feature, you need to activate the feature in your Web.config file, as shown below.
<identity>
<impersonation enable = "true"/>
</identity>
Another key point to note when porting is data access. With the introduction of Ado.net, you now have an efficient new way to get data. Because data access is a big topic in itself, it is beyond the scope of this article. For the most part, you can continue to use ADO as before, but I still recommend that you take a look at ado.net. This is an effective way to improve your data access methods in your ASP.net applications.
Use ASP. NET of the preparatory work
Now that you know most of the problems you might encounter, you might want to know what you should do today before you finally turn to asp.net. There is a lot of work to do to make the process smoother. Even if you don't turn to asp.net in the future, many of the suggestions here are also helpful for your ASP code.
Using option Explicit
This is a good suggestion, but not everyone uses it. When you use Option Explicit in ASP to enforce variable declarations, you will at least have a clear idea of where all content is defined and how the variables are defined. Once you go to asp.net, I recommend that you use option Strict. Option Explicit is the default in Visual Basic.NET. However, if you use a more mandatory option Strict, you can ensure that all variables are declared to be the correct data type. While this is bound to add extra work, you will find it worthwhile in the long run.
Avoid using default properties
As we discussed, the default properties will no longer be allowed. Accessing a property is inherently difficult. This makes your code more readable and saves you more time in the future when porting.
Use parentheses and Call keywords
As described earlier in this article, you should use parentheses and call statements as much as possible. In ASP. NET, you will be forced to use parentheses. Use the call statement now to help you develop good programming habits to better suit your future needs.
Avoid nested include files
This is easy to say and difficult to do. However, you should try to avoid nesting your include files as much as possible. To be more clear, you should avoid repeating nested files in the most significant way. Over time, it often happens that your code has to rely on a global variable that is defined elsewhere in the inclusion file. You are able to access it because one of your included files contains the containing file that you are really looking for.
When you turn to ASP. NET, you will most likely move your global variables and programs into the class library. At this point, if you know where to access all content, it will be more convenient. Finally you may have to reposition some files and change the names of some duplicate routines.
To organize functional functions into a single file
One strategy during the migration process is to transfer functional functions and code to Visual Basic or C # class libraries. In contrast to multiple explanatory ASP files, you can eventually put all the code into the object to which it belongs. Organizing your code in advance will save you time in the future. In the ideal state, you should be able to group subroutines into logical files. This allows you to easily create a set of VB or C # classes. These features are probably long overdue in COM objects.
If you have many mixed global variables or constants in the server-side include file, you might as well put them in a file. Once you turn to ASP.net, you will be able to easily create a class that accommodates all of your global variables or constants. This allows you to have a more organized, easier to maintain system.
Remove the code as much as possible from the content
You should try to isolate your code as much as possible from the content of the HTML, which is another easy job to say. The function body of the mixed code and script is cleared out. By doing so, you will be able to keep up with the good implementation code, because this is an ideal model under the asp.net.
Do not declare a function in a <%%> block
In ASP.net, this type of writing has not been supported. You should declare your function within the <script> block. Please refer to the example in the previous structural change section.
Avoid output (Render) functions
As discussed earlier, you should avoid using output functions. If you can change or prepare your code now, you should use the "Response.Write" statement block when you build these types of functions.
Explicitly release resources (call the Close method)
Try to explicitly call any close () or the release method of the objects and resources that you are using. As far as release is concerned, we all know that visual Basic and VBScript automatically release resources. They can generally release resources immediately, but when we turn to. NET, we cannot know exactly when the resources will be released. So you should free up resources as much as you can.
Avoid mixing languages
If possible, you should avoid mixed server-side VBScript and JScript on the same page. In general, mixing different languages is inherently bad programming practice. Because of the changes in the new compilation mode, each page requires only one language in the <%%> block. This is also a problem to be noted when transplanting to asp.net. You can continue to write client script in the way you used to.
Summarize
To sum up, you need to be aware of quite a few aspects when you move your application to asp.net. Most of the changes I have made in this article should be easy to implement.
If your site is very large, when you complete this process, you find and fix the dead code, inefficient program, the number of bugs, may be enough to amaze you. At the same time, you will be able to fully enjoy asp.net and even the whole. NET platform brings many powerful functions.
