<< Click to Display Table of Contents >> Navigation:  Programming with Common Vision Blox > Multi-Platform > Type System and Breaking Changes > .Net

 

All the .Net DllImport wrappers for CVB have been recompiled for the CVB 2011 release using the “Any CPU” setting of the C# compiler.

The aforementioned changes to the C++ DLL interface have been taken into account; therefore the newly built wrappers will be identical on the Win32 and the Win64 release of CVB.

 

Furthermore, if you built a .Net application based on the CVB managed wrappers with the “Any CPU” setting, it will be possible to run the same assembly with the same wrapper DLLs on the Win32 as well as the Win64 platforms.

 

Shared Objects

One of the concepts customers frequently seem to struggle with when programming with CVB is that of reference counted objects.

In CVB, objects that may potentially be used in several locations of an application and/or in several threads have been given a reference count that – when used properly – allows the object to determine its own lifetime and manage object disposal.

Use of that reference count however will easily and invariably sooner or later lead to either a memory leak or to access violations.

The .Net runtime provides two features that allow us for the first time to offer objects that automatically handle their reference count properly:

•The CLR itself maintains a reference count of the managed reference objects (which is required for the garbage collector to do a reliable job)

•The CLR allows for the use of objects across programming language boundaries

 

We have made use of that and implemented several new objects that can manage their lifetime autonomously rather than relying on the user to call ReleaseObject/ShareObject.
These objects may be used as a substitute for their “classic” counterparts as they are implicitly convertible.
Where CVB functions take one of the old types (see table) as a ref or out parameter, an overload has been added to accept its shared counterpart as a ref or out parameter.

 

We strongly recommend using the shared object types when starting a new application.

 

Note that the old types have changed as well: Prior to CVB 2011 they were designed as value types and have now be changed to be reference types.
Where necessary, update your code accordingly.

 

VPAEntry

Similar to C++, the components of the VPAEntry structure had to change from pure 32 bit values to platform-polymorphic IntPtr values.
As you cannot calculate with IntPtr values directly, be prepared for using lots of typecasts where VPAT operations are involved and make sure to prefer System.Int64 over System.Int32 when doing so, as you might otherwise accidentally cast away the uppermost 32 bits of a 64 bit value (“pointer truncation”).

 

Node Call-backs and NodeMap Call-backs

As mentioned before, not only have the new shared objects been introduced (see table previously in this chapter), but the underlying “blunt” types also changed: Previously they were value types, and starting with CVB 2011 they have become reference types.
In most cases this does not really affect a customer’s code because all the calls into unmanaged libraries have been adapted accordingly.

However there is one situation for which no workaround exists that does not break backward compatibility and that is when the two call-back types Cvb.GenApi.TFNode and Cvb.GenApi.TFNodeProc are involved: To reproduce the correct behaviour we had on the value type versions of Cvb.GenApi.NODE and Cvb.GenApi.NODEMAP it was necessary to change the signature of those two call-backs to accept System.IntPtr parameters instead of Cvb.GenApi.NODE and Cvb.GenApi.NODEMAP.
Inside the callbacks, of course the respective objects are easily created with new Cvb.SharedNode(IntPtr) or new Cvb.SharedNodeMap(IntPtr) calls.