Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

VB IDE and ObjectContext

A myth that is still being spread in various VB and MTS/COM+ related newsgroups, is that an application can not obtain a reference to the MTS or COM+ ObjectContext in the Visual Basic Integrated Development Environment (VB IDE). The truth is, since VB 5 a VB ActiveX DLL project in the IDE can obtain a reference to the MTS ObjectContext object, and this article explains a little bit about how to use this capability, some things to check if it doesn't seem to be working for your project and detailed instructions for creating a VB application that demonstrates the capability. MTS/COM+ ObjectContext not available in VB IDE: Myth Debunked. If you still believe that the MTS or COM+ Object Context doesn't work in the VB IDE, this article is for you!


advertisement

A myth that is still being spread in various VB and MTS/COM+ related newsgroups, is that an application can not obtain a reference to the MTS or COM+ ObjectContext in the Visual Basic Integrated Development Environment (VB IDE).

Ever since VB 5 a VB ActiveX DLL project in the IDE can obtain a reference to the MTS ObjectContext object.



This article explains a little bit about how to use this capability, some things to check if it doesn't seem to be working for your project and detailed instructions for creating a VB application that demonstrates the capability.

This article applies equally to Windows NT (Server or Workstation) with MTS 2.0 installed and Windows 2000 Professional or Server. For easier reading, I'll refer to both situations as MTS.

Hyperlinks to documentation mentioned in this article can be found at the end of this article

Background - the MTS context object

When code in client application instantiates an object of an MTS component, MTS provides a context object that the code in the component can interact with. Code in an MTS component is not required to interact with the context object, but it normally does, at least to the extent of calling the SetAbort or SetComplete methods. Application code acquires a reference to the MTS context object by calling the GetObjectContext function.

A call to GetObjectContext will terminate normally whether the code making the call is in a component configured as an MTS component or not. If the code is not in configured as an MTS component, GetObjectContext returns the value Nothing.

An MTS component is always a COM DLL (ActiveX DLL in VB parlance). Each MTS Server Package (applications in Windows 2000 Component Services terminology) gets a process of its own and all components in that package execute in the same process. MTS Library packages run in the process of the client.

The VB Integrated Development Environment (VB IDE)

The VB IDE is a normal Windows executable and runs in it own process. So, how can code executing in the VB IDE be part of an MTS component?

For VB version 5 and 6, Microsoft provides a behind the scenes mechanism to overcome this technical difficulty. Without attempting to explain exactly how this works (I don't understand all the details myself), this mechanism allows ActiveX DLL VB projects executing in the VB IDE to obtain a reference to the MTS context object. The mechanism is available automatically when MTS 2.0 (from the NT Option Pack) and VB 5 or 6 are installed. It is also available automatically when VB is installed under Windows 2000.

The VB Version differences:

VB 5:

Support for debugging MTS components with Version 5 of VB is somewhat primitive. VB 5 uses a special version of GetObjectContext and the associated context object which allows code executing in the VB IDE to obtain a reference to a simulated context object. This simulated object allows calls to SetAbort, SetComplete etc. to execute without error, but the calls have no affect on anything. To get this to work, you have to add the registry entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Transaction Server\Debug\RunWithoutContext

This, and limitations that apply in this environment, are explained in the Microsoft Knowledge Base Article Q188919.

VB 6

Support for debugging MTS components with Version 6 of VB is far superior to that for VB Version 5. VB 6 MTS connects the component executing in the VB IDE with the real (not simulated) MTS run-time. There are a few limitations imposed by the debugging environment, such as only one thread of execution and thus only one client at a time can use the component executing in the VB IDE. The Microsoft Transaction Server (MTS) Issues section of the VB Readme file that accompanies Visual Studio 6 (READMEVB.HTM) explains the limitations fairly well and is the first place too look for additional information. This Readme is installed in the root of the Visual Studio folder (typically c:\Program Files\Microsoft Visual Studio). It’s also available as Microsoft Knowledge Base Article Q170156.

The registry key that is required for VB 5 is ignored by and therefor not required for VB 6.

Gotcha’s:

Here are a few of the main points from the VB 6 Readme mentioned above.

  • To avoid certain kinds of problems, it is recommended that components being debugged in the VB IDE not be configured under MTS. If your component is already registered as an MTS component on the development computer, you might want to delete it from MTS before opening it in the VB IDE. In my experience, this is good advice, despite many suggestions to the contrary in newsgroup posts.
  • You can not execute a component in the VB IDE while it is active in MTS. If you choose to ignore the advice above, you must make sure the component is Shut Down in MTS before starting it in the VB IDE.
  • Components in the VB IDE always run in an MTS Library package. Under NT 4.0 and MTS 2.0, this means that testing of code that interrogates security related information in the MTS context object may behave differently in the VB IDE from when the component is configured in a Server package. This is especially the case if the component implements programmatic security (e.g. the IsSecurityEnabled method will always return False). Under Windows 2000 with COM+, Library application security behaves differently; testing security related code may be less of problem. However, there still may be differences when the application is configured as a Server application (for example, see MS KB article Q243437).
  • If you try to "watch" a property of the context object or any associated objects, you may get an unexpected result or a failure in the VB IDE.

Some other things to keep in mind (not in the VB ReadMe):

  • Although VB allows you to have multiple VB Projects active in a single instance of the VB IDE, it’s a really good idea to start your client and components each in separate instances of VB. If you don’t, the VB IDE may crash if you terminate execution of the MTS component (e.g. by clicking on the "End" button on the Debugging toolbar).
  • When debugging a VB component invoked by IIS, the security environment for IIS and the VB IDE must be the same (see MS KB Article Q244807). Disable anonymous access to the asp page, so that IIS must validate the user through integrated security, thus getting the same identity as the component.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date