Visual Basic migratioon now faster than ever!

6. May 2009 09:44 by Fzoufaly in General  //  Tags: , , , ,   //   Comments (0)

Today ArtinSoft launched the Visual Basic Upgrade Companion 3.0 both for our Enterprise and Developer Editions.  This latest release of the best (I am biased!) Visual Basic migration tool in the world is focused on reducing the total effort of a migration project.  Together with the conversion tool release we also revamped its companion technical site http://www.vbtonet.com/ .  This site, which will be continuously updated in the following weeks, is the perfect side help to any person that needs to complete a migration project.  It contains everything from a getting started guide to how-to articles with advanced migration topics.

At ArtinSoft we are truly proud of this release and we continue to be fully committed to support our customers in their transition from VB 6 to Visual Basic .NET or C#. 

Specifically, here are the latest additions to the VBUC 3.0.  Click here to get a trial of this exciting product.

VBUC 3.0 New Features

 Source Code Conversion Features
  • Windows API and 'Declare' Support
    VBUC 3.0 introduces support for external DLL function declarations and invocations. A vast research was performed to identify the correct way of declaring and passing parameters and return types for primitives, classes, enums, structs, fixed lenght strings, arrays and combinations of these types.
  • Increased Support for Windows Common Controls Conversion
    VBUC 3.0 introduces a substantial amount of improvements for the conversion of Windows Common Controls to native .NET controls.  An extensive effort was performed to identify and resolve issues related to these components which are present in most VB6 applications. The main improvements are related (but not limited) to the following controls:  ImageList, ListView, StatusBar, Toolbar, TreeView.
  • Public Class Instantiation Models Support
    Public classes in ActiveX EXE/DLL projects may have different instantiation models (multiuse, singleuse, etc.) To achieve the same behavior in .NET a whole conversion solution was implemented and incorporated into VBUC 3.0.
  • Default Property Resolution Through Helper
    The VBUC contains a new helper class designed to resolve several late binding issues that are not solved by the typing mechanism. This solution significantly reduces compile errors and EWIs while providing higher functional equivalence.
    This solution resolves the EWIs related to late-binding and default property issues which represent around 50% of known issues from older versions.
  • Data Access Conversion Improvements
    The data access conversion to ADO.NET with System.Data.Common has been a very popular feature from the previous VBUC versions.  VBUC 3.0 introduces several improvements to this feature. It includes enhancements to the helper classes functionality as well as additional members coverage (clone, sort, getrows and many others)
  • IsMissing Support
    VBUC 3.0 introduces support for the IsMissing function. Since VS.NET doesn't include the concept of missing parameters, VBUC now generates a code pattern that produces the same behavior by taking advantage of nullable types and overloading.
  • NotUpgradedHelper for Not-Upgraded Statements and Members Handling
    A very common problem with older versions of VBUC was the handling of NotUpgraded members and statements.  They were usually generating compile or runtime errors that made the post-VBUC manual work more difficult.
    VBUC 3.0 introduces a helper class to report and handle the usages of not supported elements while avoiding compile and runtime errors.
  • Multiple improvements to existing features
    Around 450 individual improvements were implemented for VBUC 3.0.  Most of them are related to providing increased automation and enhance the resulting code quality, others are related to other areas such as robustness and graphical interface.
 Performance Improvements
  • Speed Boosting
    For VBUC 3.0 several time performance improvements were implemented to achieve a substantial improvement, reducing to 50% the required time to perform an upgrade process.  Additional time improvements could be experienced when converting large projects which used large amounts of memory.
  • Reduced Memory Requirements
    Memory usage was also significantly improved.  Based on tests over medium projects we estimate around a 30% improvement.  It is estimated that more significant improvements will be experienced with bigger projects.
 Assessment
  • Assessment Tool Integration
    The VBUC Assessment Tool functionality has been incorporated into the VBUC. Users can now execute the assessment process from the VBUC main window. One important advantage of this approach is that users can solve migration warnings before executing the assessment process, allowing the obtention of better quality information.
  • Additional Assessment Reports
    Two additional reports have been included into the integrated assessment process:
    • An advanced dependency analysis that shows internal-dependency trees per project.
    • A shared and potential-duplicate files report.  It includes the following sub reports:
      • A shared files report indicating which projects include each shared file.
      • A potential-duplicate files report indicating which projects include each presumed duplicate file.
      • A projects list sorted topologically with LOC counts for each project where shared and potential-duplicate files are counted only in the first project they occur.
 Other Features
  • Graphical Interface Status Information
    The VBUC 3.0 graphical user interface shows detailed information for each project.  It shows sizes, progress and status by project and by source file detail.
    It helps the user to understand the volume of work required for each project and its current upgrade progress as well as to identify any eventual pieces of code that may have not been fully converted.
  • EWIs and Upgrade Report Improvements
    Several modification have been implemented to the upgrade messages generated by VBUC into the generated code.
    • UpgradeReport Synchronization: for previous versions of VBUC the UpgradeReport didn't show properly all the EWIs generated into the upgraded code.  For VBUC 3.0 this report includes all the EWIs generated in the converted code plus the global EWIs that are not included into the target source code.
      In addition, the accumulated counts per section where also improved to show the correct amount of occurrences.
    • Links to Online Documentation: Hiperlinks are added for each EWI to its corresponding online documentation in the new www.vbtonet.com site.
    • Restructuring: The EWI message structure was modified to show the numeric code first.  Also some messages where improved and some EWIs were removed or merged.
  • Increased Robustness and Logging
    Several actions were taken to handle and recover from unexpected situations.  In the event that any exceptional situation may arise, an window is displayed explaining the issue and providing the user with options to generate debugging information that can be sent to ArtinSoft support for diagnosis and recommendations.
 Products, Versions and License Types Formalization
  • Developer and Enterprise Editions
    The second version of VBUC Developer Edition is released with VBUC 3.0.  The development process has been formalized to syncronize the maintenance and releases of both versions.  The Developer Edition includes an improved activation and licensing model as well as an easier on-line sale mechanism.
  • Trial Licenses
    Both Developer and Enterprise editions support trial licenses.  Developer trials are now available for download in the Artinsoft web site.
  • ASP Upgrade Engine Integration
    The ASP Upgrade Engine has been integrated into the VBUC 3.0.  It is now installed together with VBUC.  The license file can still restrict the use of ASP upgrade abilities though.
  kick it on DotNetKicks.com

Bittable What????

As vb6 migration experts in our company we deal everyday with a lot of issues around Interop and serialization.

One important thing to note is the concept of “Bittable Types”. I’m not making up terms. Those terms actually exist. Just see this link in MSDN.

In a few words, a bittable type is a type that has the same representation in managed and unmanaged code.

Why in earth is that important at all?

Because if you are calling that great C++ DLL implemented some years ago that just works ok, you won’t be able to pass a NON-Bittable type because that DLL will expect a binary representation different from that in the .NET virtual machine.

This is also an issue in other scenarios like:

  • Serializing content to files
  • Sending messages through messaging mechanisms like named-pipes or sockets.

Well, we have just introduced the problem so now let’s think on a nice solution for this problem.

Well Bittable Types are:

The following types from the System namespace are blittable types:

 

So now let’s look at a couple of non-BITTABLE types

DateTime

To test this differences let’s make a small test in VB6 and write a Date value to a file:

 

Private Sub SaveDateToFile()
    Open "C:\test1.bin" For Binary Access Write As #1
    Dim d1 As Date
    d1 = "1/1/2009"
    Put #1, , d1
    Close #1
End Sub

Now let’s make a quick program in Vb.NET

 

Sub Main()
        Dim f As System.IO.FileStream = System.IO.File.Open("C:\test2.bin", IO.FileMode.Create, IO.FileAccess.Write)
        Dim fw As New System.IO.BinaryWriter(f)
        Dim d As Date
        d = Convert.ToDateTime("1/1/2009")
        Dim val As Long = d.ToBinary()
        fw.Write(val)
        fw.Close()
        Main2()
    End Sub

 

If we compare these files we will have:

image

So the values are obviously different. This is because VB6 Date are stores with the OLE Automation DateFormat

So let’s change the C# code for something like:

 

    Sub Main2()
        Dim f As System.IO.FileStream = System.IO.File.Open("C:\test3.bin", IO.FileMode.Create, IO.FileAccess.Write)
        Dim fw As New System.IO.BinaryWriter(f)
        Dim d As Date
        d = Convert.ToDateTime("1/1/2009")
        fw.Write(d.ToOADate())
        fw.Close()
    End Sub

And now when we compare the files we will have:

image

 

So to make your Date values compatible with VB6 format you must user the DateTime method .ToOADate. Now if you are calling a DLL that expects a Date value in the same format used by VB6 then you will have to do this:

 

        Dim d As Date
        d = Convert.ToDateTime("1/1/2009")
        Dim handle As System.Runtime.InteropServices.GCHandle = System.Runtime.InteropServices.GCHandle.Alloc(d.ToOADate(), Runtime.InteropServices.GCHandleType.Pinned)
        Dim memory_address As IntPtr = handle.AddrOfPinnedObject()
        Try
            APICall(memory_address)
        Finally
            d = DateTime.FromOADate(System.Runtime.InteropServices.Marshal.ReadInt64(memory_address))
            handle.Free()
        End Try  

 

String

Most of the time you wont have to deal with String marshalling because adding marshaling tags to your API call solves most of the problems, but if you arent that luckyly then you might do something like:

IntPtr ptrToStringVar = System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(strVar);
try
{
   APICall(ptrToStringVar);
}
finally
{
strVar = System.Runtime.InteropServices.Marshal.PtrToStringAnsi(ptrToStringVar);
System.Runtime.InteropServices.Marshal.FreeHGlobal(ptrToStringVar);
}

NOTE: if you have an API that might return an string with /0 characters you must call the API with System.Runtime.InteropServices.Marshal.PtrToStringAnsi(ptrToStringVar,size), if you do that the Framework will take in consideration the size bytes at the ptrToStringVar memory address.

 

Double and Singles

At least between VB6 and VB.NET the double and single types follows the same format. Well, at least, that is the result of my tests.

Try it yourself, the following shows a simple test for double variables:

VB6

Private Sub SaveDoubleToFile()
    Open "C:\test1.bin" For Binary Access Write As #1
    Dim d1 As Double
    d1 = 1.123
    Put #1, , d1
    Close #1
End Sub

Sub Main()
    SaveDoubleToFile
End Sub

 

.NET

Module Module1

    Sub Main()
        Dim f As System.IO.FileStream = System.IO.File.Open("C:\test2.bin", IO.FileMode.Create, IO.FileAccess.Write)
        Dim fw As New System.IO.BinaryWriter(f)
        Dim d As Double
        d = 1.123
        fw.Write(d)
        fw.Close()
    End Sub


End Module
 

So you could make an api call in those cases with something like:

Dim handle As System.Runtime.InteropServices.GCHandle = System.Runtime.InteropServices.GCHandle.Alloc(d, System.Runtime.InteropServices.GCHandleType.Pinned)
Dim ptr As System.IntPtr = handle.AddrOfPinnedObject()
Try
    APICall(ptr)
Finally
    handle.Free()
End Try

Change CreateObject during Migration

One of our clients wanted to change the CreateObject function migration for a function of their own. So they wanted all cases like:

Dim x As Object
Set x = CreateObject("Excel.Application")

 

To be migrated to something like:

Excel.Application x = (Excel.Application) Utils.MyCreateObject("Excel.Application", "");

Our migratio vb6migration tool provides a new cool feature called CustomMaps. This feature allows you to provide some simple but useful changes to the way things get migrated.

For this case follow these steps:

1. Open the Visual Basic Upgrade Companion.

2. In the Tools Menu choose:

image

3. Create a new CustomMaps File and an an entry like the following:

 

image

Notice the Source name is VBA.Interaction.CreateObject. To find out this name you can look in your VB6 IDE, right click on the CreateObject and select goto Definition.
image 
 
image 
and for the target name just put the implementation that you what, for example you can write a function like:
class Utils
        {
            public static object MyCreateObject(string className,params object[] ignoreRestParams)
            {
                return Activator.CreateInstance(Type.GetType(className));
            }
        }

and set the SourceName to Utils.MyCreateObject (or NameSpace.Utils.MyCreateObject to use the fully qualified name). You just need to set the New Reference Name column because we will not change the definition of the function.

Learn about low-cost and low-risk migration options with Avanade and ArtinSoft

18. March 2009 04:48 by Fzoufaly in General  //  Tags: , , , , ,   //   Comments (0)

On Wednesday April 15th 2009 Avanade and ArtinSoft will host a webinar on how to quickly and cost effectively renew your Visual Basic 6 applications.

Here’s an excerpt from the invitation:

“Don’t miss this chance to learn more about VBUC and other cost effective migration options, including:
• Which migration strategy works best for you (complete, partial,
  coexistent, partial development)
• How to reduce project risk, costs, and time to market
• How to guarantee business continuity by preserving knowledge
  invested in legacy applications“

You can RSVP and make sure you don’t forget to attend.

Get path of ASP.NET web application that is running

If you have your ASP.NET application for example in c:\inetpub\wwwroot\WebApplication1 and you want to programmatically get that path just use something like:

 

string AppPath = Request.PhysicalApplicationPath;

Large Companies, Successful VB6 Migrations

11. March 2009 11:51 by Fzoufaly in General  //  Tags: , , , , ,   //   Comments (0)

Here is a summary of some recent case studies that we have produced with our customers. 

The message is common: Visual Basic 6 to C# migrations are an excellent alternative that saves time and money when you need to move your application to .NET.

HSI

This Texas-based company provides geo-navigation solutions for the horizontal drilling industry, and when the end of official support for the VB6 development environment was announced, they turned to ArtinSoft to migrate their LatNav application from VB6 to C# on a turn-key basis, using a slightly customized version of the Visual Basic Upgrade Companion.

“Utilizing the Visual Basic Upgrade Companion saved us about one year of development and $160,000. This conversion will allow us to leapfrog well in front of our competition” -- Ken Bowdon - HSI founder

Read the full HSI case study.

MDA

After discarding a manual rewrite and the Upgrade Wizard, MDA –a software services provider for the real estate sector– settled for ArtinSoft’s Visual Basic Upgrade Companion tool, with which RDO was transformed to ADO.NET, third party controls were converted to native .NET controls, Component One’s True DB grid was upgraded to the latest version of that component, and coding standards that were common place when developing in Visual Basic 6.0 were also migrated to equivalents in VB.NET.

“We looked at different options, like a rewrite and the Upgrade Wizard. The UW couldn’t cater for our needs, especially since we were going from RDO to ADO.NET. A rewrite would have been about a five-year project for us, and possibly in the region of US$500,000. Using the Visual Basic Upgrade Companion represented an estimated saving for the project of about 3 years and US$300,000”. -- Rodger Beadle – Technical Director, MDA

Read the full MDA case study.

Vertex

Vertex, a leading global BPO and customer management outsourcing company, managed to ensure compliance and business continuity by upgrading not one, but two mission-critical applications from VB to .NET using a customized version of the Visual Basic Upgrade Companion (VBUC). These case studies underscore the joint efforts made by both companies, which proved to be decisive to accomplish the goal of having both migrated applications up and running within some serious time constrains.

"ArtinSoft has been an excellent company to work with. They have been responsive to requests from Vertex to change their processes in order to accommodate the way in which we work. They have provided us with daily updates throughout the migration life cycle and have worked in partnership with Vertex to resolve any issues that have arisen in a pragmatic and expedient manner." -- Sue Craig - Senior Project Manager, Vertex

Read the full Vertex Omiga Case Study.

Read the full Vertex Supervisor Case Study.

Banamex / Citigroup

Learn how Banamex, one of the most widely recognized financial institutions in Latin America and purchased by Citigroup in 2001, was able to migrate over 5 million lines of code from VB6 and ASP to C# and ASP.NET using ArtinSoft’s Visual Basic Upgrade Companion, in compliance with Citigroup’s corporate policies for quality assurance and information security. The project also included the creation of an effective collaboration environment and the implementation of highly advanced security tactics in order to guarantee full confidentiality in data handling.

Read the full Banamex/Citigroup Case Study.

I've decided to move away from VB6. Now What?

At some point in time companies decide they want to leave a certain platform.  Let’s not focus on the reasons why they decide to move but on HOW to move instead. Companies reach the decision to move on their own timetable.

Once you have decided that you want to move away from VB6 then ArtinSoft comes into play.  The purpose of my blog is to show that there is a way out that is good, fast and cost-effective.  Compared to what? You might ask, let’s see.

Once you decide to move (let me be clear, you made the decision to move, then the rest of the discussion applies) you have to assess your applications and make a decision on HOW to move them one by one. 

There are three axes along which we recommend our customers to make the analysis:

  • How unique is the functionality to your business? For example, if you have a general ledger that does not have any particular features for your business, if you have a “me too” app that does not give you an advantage over your competitors, well, you should consider just buying a package and replace it.
  • How good is the technical quality of your source code? Have you followed best practices in VB?  Is your code maintainable by a third party? (Can they understand it?) If the answer is no then migrating it to a new language is not going to improve this situation.  Consider a rewrite.
  • How fast is the functionality changing to meet business goals? Is the business process it supports fixed?  Do you anticipate that very minimal changes will happen before retirement?  Then you should just leave it as is (one caveat here, in some industries because of regulatory issues you might still make sure you are on a fully supported platform even if the application does not change).

Now, if you have an application that provides you a business advantage, that is of good technical quality and that needs to adapt to new business challenges, then you have a good candidate for a migration.

For applications with the above characteristics, why is a migration better than a rewrite?

  • Cost: when we look at cost there are several dimensions.
    • Cost of the actual migration process: An automatic migration to functional equivalence can be done with about 20% of the cost of a rewrite.  Most of that cost is testing and fine tuning of the application to the new platform.
    • Training of end users: Since the application is functionally equivalent it is not necessary to retrain end-users.  With a rewrite, chances are that the output is not going to be functionally equivalent unless you follow an algorithmic approach just like an automatic migration and therefore end users need a retraining.  In addition to the actual retraining cost (which can be enormous – e.g. we worked with a customer whose system required a 6 weeks training time, for 3000 users.  An application replacement or rewrite would have started with that hole in front of them) but the opportunity cost.  New software, new mistakes, how does that impact the business continuity?
  • Time: An automatic migration process can also be done in about 20% of a rewrite.  This means that you can free up resources much faster to actually build new functionality that the business requires instead of attempting to replicate functionality that already works.
  • Quality: An automatic migration does not fundamentally change the architecture of the original application (even if certain aspects like data access and some pieces of GUI architecture do change). The question is: do you really need to change the architecture for the whole application? Probably not. You might need to change the architecture for certain processes.  The code that is generated by ArtinSoft is completely ready for evolution.  No strange variable names, all comments preservation, no restructuring of the code, etc.  Even if in the worst case scenario you need to rewrite a certain piece of the application it is always a fraction of the total cost.

Comments?

Resizing Forms in C#

In the VB6 world it was very common to use “Resizer” OCXs that you just put on your forms and that they handle all the proportional resizing needed if you changed your form.

It was very simple and easy.

However when I started looking for something like that in .NET it was quite hard to find. So finally I got to ComponentSource and found some alternatives and I evaluated them:

 

Component Vendor Pricing URL
Component One Sizer For .NET Component ONE I think you have to buy the Component One Studio. That’s $800 ($1000 with more support)
and I think is one license per developer, runtime-free
http://www.componentone.com/SuperProducts/StudioWinForms/
.NET Forms Resize Softgroup 380$ per developer
from ComponentSource
if you buy directly from them you can get the component for 180$

Each copy is licensed on a per developer basis. A developer may use the license on multiple CPUs as long as they are not used concurrently nor used by another developer. Run-time royalty free.
http://www.soft-group.it/net/index.php?c=3a&id=11
Resize OCX/.NET Larcom and Young 95$-100$ per license

one license per developer, runtime-free
http://www.lyoung.com/

 

All of them seem to work. So it really up to your company preferences, budget and the level of support you desire. I haven't made tests like how it behaves if you have thirdparty components or activex ??? maybe I'll review that later.

Calling .NET from PowerBuilder

3. March 2009 08:14 by Mrojas in General  //  Tags: , , , , ,   //   Comments (0)

Most of our clients come from a medium-size to a big enterprise level. In these scenarios is very common to have different department using different technologies to solve their business needs.

These different technologies can be on a very homogeneous platform like .NET where you can easily interact between your VB.NET and C# assemblies, or they could be on differente technologies like ASP, Classic VB, C++, or Powerbuilder.

This post is about PowerBuilder, and in order to interact with PowerBuilder I think the easiest way is to expose your assemblies thru COM Interop.

So if there is some .NET functionality that you want to expose to PowerBuilder you just need to expose that functionality with a class in a ClassLibrary project with COM attributes.

Let’s begin with a simple program to show how to comunicate Powerbuilder with C#.

NOTE:  If you don’t have Powerbuilder you can get a trial version from: http://www.sybase.com/detail?id=1052162

  1. Open Microsoft Visual Studio
  2. On the File Menu, choose the New option, and in the File submenu choose Project….

Visual Studio File Menu

Figure 1. Visual Studio File Menu. Choosing the option for a new project

  1. When you choose that option a dialog window will shown with the available options for new projects. In the option for C# Projects choose “Class Library”

image

Figure 2. New Project dialog window

You must introduce the new project name, location and solution name. Type something like ClassLibrary1, D:\PowerBuilder, ClassLibrary1.

1. When you finish creating your project you will have a code file called Class1.cs.

2. Change that code for something like :

using System;
using System.Collections.Generic;
using System.Text;

namespace SimpleClass
{
    public class Class1
    {
        public int AddTenToParameter(int param1)
        {
            return param1 + 10;
        }

        public void SayHi()
        {
            System.Windows.Forms.MessageBox.Show("Hello World!");
        }

        public String GiveMeDate()
        {
            return DateTime.Now.ToLongDateString();
        }
    }
}

This will allow to test things like parameter passing, using different return types like strings or integers. But Before you continue you must add a reference to System.Windows.Forms to be able to use the MessageBox.

 

Context Menu to add a reference

Figure 3. Adding a reference

 

Dialog with References

Figure 3. Reference to System.Windows.Forms

3. Right click on the solution file and select properties:

Project properties

Figure 4. Option to change project properties

4. Select the Register for COM Interop  checkbox

Register for COM

Figure 5. Project properties window

5. Return to Class1.cs code file

6. Add an using statement after the existing using lines on Class1.cs file:

using System.Runtime.InteropServices;

7. Add the following attributes to the class:

[ComVisible(true)]

[ClassInterface(ClassInterfaceType.AutoDual)]

[ProgId("ClassLibrary1.Class1")]

Note: the ProgId is very important, because these value will be use in PB to comunicate with the this code

8. Now you must edit the AssemblyInfo.cs

AssemblyInfo file

Figure 6. AssemblyInfo.cs File

Now make sure to establish the COM settings in this file with statements like the following:

// Setting ComVisible to false makes the types in this assembly not visible

// to COM components. If you need to access a type in this assembly from

// COM, set the ComVisible attribute to true on that type.

[assembly: ComVisible(true)]

// The following GUID is for the ID of the typelib if this project is exposed to COM

[assembly: Guid("69efac5b-d887-40f4-a7e9-2721ac3c1598")]

 

The Guid is also very important, because this is used to differentiate this component and it must be unique.

To generate a new GUID you can got to the Tools Menu and choose the option Create GUID

Create GUID menu option

Figure 7. Option menu to create a GUID

In the Create Guid dialog box, choose the fourth option and press Copy to put the contents on the Clipboard. Later, copy that value in the GUID attribute but remove the “{“ y “}”.

Now we are set. You only need to build the solution and the DLL. The build process with register the COM component.

If you will use the component on another computer you need to create an instalation program.

 

Using your program from Powerbuilder

Using your program from Powerbuilder is very easy. You just need code like the following:

image

Figure 8. PB Code to call a C# class thru COM

When you execute this program you will have 3 messageboxes :

  • Hello World!
  • 30
  • Monday, March 02, 2009 (this message will change depending of the day, locale and regional settings)

 

Creating an instalation program

  1. Right click the solution and in the context menu choose Add and then new project.

Context Menu for Adding new project to solution

Figure 9. Context Menu to add a new project

On the dialog box for Add New projec, look for the Other Project Types section and the choose Setup Project.

Adding a setup project

Figure 10. Creating a setup project

In this dialog bos indicate the name and location of the setup project. For example Setup1 and D:\Powerbuilder\ClassLibrary1.

Later, add a project to the setup program. To do that rigth click on the setup project and select Add, and in the submenu choose Project Output.

 

image

Figure 11. Adding a project to the setup project.

A dialog box will be shown with a combo that allow you to select the proyects in the solution. Choose ClassLibrary1 and press OK.

Add Project Output Dialog

Figure 12. Adding project output to the setup project.

When you build this instalation program two files will be produced:

Release

D:\PowerBuilder\ClassLibrary1\Setup1\Release\Setup.exe

D:\PowerBuilder\ClassLibrary1\Setup1\Release\Setup1.msi

Debug

D:\PowerBuilder\ClassLibrary1\Setup1\Debug\Setup.exe

D:\PowerBuilder\ClassLibrary1\Setup1\Debug\Setup1.msi

When you run the instalation program, this program will handle the instalation of the .NET component and the COM registration.

How to move billions of lines of code from VB6

Danish magazine Version2 published an interesting article last week on VB6 migrations: http://www.version2.dk/artikel/9908-saadan-flyttes-milliarder-af-kodelinjer-fra-vb6#forum_post_anchor .

Microsoft is finally waving goodbye to Visual Basic Version 6. Its successor, VB.Net, is not backward compatible, but the company Artinsoft from Costa Rica can help with a translation machine.

By Tania Andersen, Wednesday 11 February 2009

This article really shows momentum in northern Europe.

Enjoy!

 

Debug XBAP using WinForms Host

26. January 2009 06:13 by Mrojas in General  //  Tags: , , , , ,   //   Comments (0)

Recently I had to deal with targeting an XBAP application that had some Windows Forms controls.

The problem is that those controls can only be used in a trusted environment. If you try to debug an XBAP with some Windows Forms Controls you will get an exception like:

Message: Cannot create instance of 'Page1' defined in assembly 'XBAPWithWinForms, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Exception has been thrown by the target of an invocation.  Error in markup file 'Page1.xaml' Line 1 Position 7.

It took me a while to found a solution, and it was thru Scott Landford Blog that I found a way around.

In short what he recommends to do is:

Change your settings to:

Start Action->Start external program = %windir%system32\PresentationHost.exe

  In my case (and the case of most people that is: c:\windows\system32\PresentationHost.exe)


Start Options->Command line arguments = -debug "c:\projects\myproject\bin\debug\MyProject.xbap" -debugSecurityZoneUrl "http://localhost:2022"

Copy the value from the Start URL after the –debug argument

Very import for using WinForms components you must run in FULL TRUST

fullTrust

 

Here is some XBAP code using a WinForms WebBrowser. They designer does not like it a lot but it works:

XBAPWithWinforms.zip

More than 800k lines of ISVs code successfully migrated using the ArtinSoft Visual Basic Companion

ArtinSoft recently published a number of case studies of Visual Basic migrations for ISVs.  The projects were successful both from the technical as well as the economical perspective.  If you are an ISV and you are considering an evolution of your application and a port to the .net platform I encourage you to take a look:http://www.artinsoft.com/vertex-omiga-vb-to-net-migration-case-study.aspx

http://www.artinsoft.com/vertex-supervisor-vb-to-net-migration-case-study.aspx

 

http://www.artinsoft.com/hsi-latnav-vb-to-net-migration-case-study.aspx

 In this blog I am trying to be as unbiased as possible in reporting my opinion with regards to VB migrations.  This time I am mentioning the case studies as evidence that a lot of the conceptual discussions that I have are actually happening in reality.  It is interesting to see how many of the comments to this blog tend to be from skeptics and from people that just love VB6 and do not want to abandon it.  My purpose is to show that there is life after VB6 and that an automatic migration is not only possible but, in many cases, a great alternative for your evolution plans.Please let me know what you think of the case studies.

 

VB6 Runtime WILL be supported on Windows 7 but no plans to support it on future version of windows.

13. January 2009 14:53 by Fzoufaly in General  //  Tags: , , ,   //   Comments (0)
I spoke to Paul Yuknewicz who is a Program Manager on the Microsoft Visual Basic team and who is quite involved with everything related to VB6 and its migration process.  Paul said and I quote: "VB6 runtime will be shipping and supported as a part of Windows 7, however there are no plans to ship it in future versions of Windows."  Microsoft will surely release an official document stating this in the near future. What is my take on this latest Microsoft move in the VB6 saga?  Well, I guess Microsoft had to react to the fact that VB6 is still widely popular and that a lot of businesses have delayed (procrastinated??) the decision to move to .NET.  From that perspective I believe this is the right move for Microsoft.  They want to minimize the impact of the end of life for Visual Basic 6.On the other hand, I have to wonder, why do people seem to not want to upgrade?  Over the years I have formulated a number of hypotheses as explained below. 
  • Migration is perceived as expensive: In the short term is certainly cheaper to do nothing than to migrate, however, if you have a valuable asset you want to make sure you can extend its life (and therefore ROI) as much as possible.  Automatic migration is the best alternative to achieve it.
  • Migration is perceived as lacking value: I have often heard how by automatically migrating an application at the end I get the same application and therefore I did not gain anything.  This is also false.  Once you upgraded the source code you have injected new life into it.  Your application has suddenly extended its life expectancy and (again) its ROI.  Maintenance and evolution of a .NET application is safer than of a VB6 app.
  • VB6 Applications are not evolving: Can this be true?  It is possible that companies have VB6 applications that support a business function that is not evolving.  If this is the case, leaving applications in VB6 is just fine and the fact that now Microsoft supports VB6 in Windows 7 gives a new breath to those applications.  However, in my more than 15 years of experience in the IT industry I have yet to see an application that never changes!  It is important to remember that the Visual Basic 6 Development environment is off main stream support by Microsoft. 
  • Applications will be retired before VB6 stops working: This is a plausible for a number of applications.  Companies sometimes choose a substitution strategy and just retire applications, or business processes stop being important and therefore the applications that support them are no longer necessary.  These cases certainly happen, and a number of applications might be in this category but it cannot be the great majority of them!  Additionally, companies sometimes believe that substituting an application for an equivalent one is cheaper than migrating them.  Well, I dare them to review this assumption make sure they run a complete comparison.  
  • It’s just procrastination: The famous “if it ain’t broken don’t fix it!” … do I have to comment on this??  May this be the reason why VB6 is still around?
  • There’s just too much VB6: This is the argument Gartner used to make for COBOL: it would be too expensive to migrate all the COBOL.  In fact, I have even heard this from an IBM executive who told me that at some point they were scared that all the mainframe code would migrate to Java (and therefore business rules would no longer be trapped in a mainframe) but then they run the math and just relaxed!  Of course, there is no real automatic solution for COBOL!!!!  For VB6 is a different story (ArtinSoft infomercial: http://www.artinsoft.com/pr_vbcompanion.aspx ).
 What is your position?  Am I missing a category of reasons why VB6 is still around?

 

Use C++ in C#

19. December 2008 07:00 by Mrojas in General  //  Tags: , , , , , ,   //   Comments (0)

COM


The idea is to make a class or several classes available thru COM. Then the compiled dll or the TLB is used to generate and Interop Assembly and call the desired functions.

With this solution the current C++ code base line can be kept or might require just subtle changes. 

Calling a function thru com is involved in a lot of marshalling and can add an additional layer that is not really needed in the architecture of the solution.

Creating a Managed Wrapper with Managed C++

The idea with this scenario is to provide a class in Managed C++ that will be available in C#. This class is just a thin proxy that redirects calls to the Managed object. 

Let’s see the following example: 

If we have a couple of unmanaged classes like: 

class Shape {

public:

  Shape() {

    nshapes++;

  }

  virtual ~Shape() {

    nshapes--;

  };

  double  x, y;  

  void    move(double dx, double dy);

  virtual double area(void) = 0;

  virtual double perimeter(void) = 0;

  static  int nshapes;

}; 
 

class Circle : public Shape { 

private:

  double radius;

public:

  Circle(double r) : radius(r) { };

  virtual double area(void);

  virtual double perimeter(void);

}; 
 

The first thing we can try, to expose our classes to .NET it to set the setting for managed compilation: 

Es posible que tu navegador no permita visualizar esta imagen.Es posible que tu navegador no permita visualizar esta imagen. 

If your project compiles then you are just very close, and what you need is to add some managed classes to your C++ project to expose your native classes: 

Let’s see the Shape class: 

//We can use another namespace, to avoid name collition.

//In this way we can replicate the structure of our C++ classes. 

namespace exposedToNET

{

      //Shape is an abstract class so the better thing

    // to do is to generate an interface 

      public interface class Shape : IDisposable

      {

      public:  

            //public variables must be exposed as properties

            property double x

            {

                  double get();

                  void set(double value);

            }

            property double y

            {

                  double get();

                  void set(double value);

            }

            //method do not expose any problems

            void move(double dx, double dy);

            double area();

            double perimeter();

            //public static variables must

          //be exposed as static properties

          //However we might need to create a new class

          //for all public static variables and methods

          //because C# does not accept methods in an interface

            static property int nshapes;

      };

      //Static methods or variables of abstract class are added here

      public ref class Shape_Methods

      {

                        //public static variables must be exposed as static properties

      public:

            static property int nshapes

            {

                  int get()

                  {

                        return ::Shape::nshapes;

                  }

                  void set(int value)

                  {

                        ::Shape::nshapes = value;

                  }

            } 

      };

} 

And for the Circle class we will have something like this: 

namespace exposedToNET

{ 
 

      public ref class Circle : Shape

      {

      private:

            ::Circle* c;

      public:

            Circle(double radius)

            {

                  c = new ::Circle(radius);

            }

            ~Circle()

            {

                  delete c;

            }

            //public variables must be exposed as properties

            property double x

            {

                  virtual double get()

                  {

                        return c->x;

                  }

                  virtual void set(double value)

                  {

                        c->x = value;

                  }

            }

            property double y

            {

                  virtual double get()

                  {

                        return c->y;

                  }

                  virtual void set(double value)

                  {

                        c->y = value;

                  }

            }

            //method do not expose any problems

            virtual void move(double dx, double dy)

            {

                  return c->move(dx,dy);

            }

            virtual double area()

            {

                  return c->area();

            }

            virtual double perimeter()

            {

                  return c->perimeter();

            }

            //public static variables must be exposed as static properties

            static property int nshapes

            {

                  int get()

                  {

                        return ::Shape::nshapes;

                  }

                  void set(int value)

                  {

                        ::Shape::nshapes = value;

                  }

            } 
 

      }; 

}

DOWNLOAD EXAMPLE CODE

SWIG

 

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.

This is a great tool used for several languages like Python, Perl, Ruby, Scheme, and even in different platforms.

The exposure mechanism used in this scheme is platform invoke, the issues here are similar to those of COM because there is some marshaling going on. This scheme might be more efficient than the COM one but I haven’t really test it to be completely sure that it is better. 

I have reviewed the SWIG code and it might also be possible to modify its code to generate wrappers using managed C++, but this is an interesting exercise that I have to leave for my readers. Sorry I just don’t have enough time. 

But how is SWIG used? 

In SWIG what you do is that you add a .i file to your project. This file provides directives for some code generation that specify exactly what you want to expose and how. 

This can very helpful if you just want to expose some methods. 

If you are lazy like me you can just add something like: 

/* File : example.i */

%module example 

%{

#include "example.h"  ß you put here includes with the definitions for your classes

%} 

/* Let's just grab the original header file here */

%include "example.h" ß add alse the include here 

And SWIG will add a file like example_wrap.cxx that you have to compile with the rest of your C++ code. 

It will also generate a set of C# classes that you use in your C# application, so it seams to your program that all the code is just C#.  

SWIG is a great tool and has been testing in a lot of platforms.

Migration to 64-bit: ODBC

5. December 2008 06:20 by Mrojas in General  //  Tags: , , , , , ,   //   Comments (0)

Most people migrating their application want to move ahead and take advantage of new technologies and new operating systems.

So if you had a VB6 application and you migrated it with us to .NET we will recommend and automate the process to use ADO.NET.

Why?

You can still use ODBC but i will list some compelling reasons:

* There a very fast ADO.NET drivers available. Using ODBC implies addind an interop overhead that can affect performance.
* Some vendors do not support and/or certify the use of ODBC drivers for .NET. So in those cases if you use ODBC your are on your own.
During my consulting experience I have seen several problems using ODBC drivers ranging from just poor performance, problems with some SQL statements, stored procedures calls, database specific features or complete system inestability.
* and also problems running in 64-bit.

This last one is very concerning. If you made all the effort to migrate an application to .NET and run it on for example on a Windows 2003 64 bit server it wont be able to use your 32-bit ODBC drivers unless you go to the the Build tab, and set Platform Target to "x86".

This is very sad because your application cannot take advantage of all the 64 bit resources.

If you are lucky enough you might find a 64 bit version of your ODBC driver but I will really recommend going straigth to 64-bit and use ADO.NET. And that's exactly what we can really help you to do specially in our version 2.2 of the VBUC.

 

Migration of ActiveX UserDocuments to C# or .NET

This post describes an an interesting workaround that you can use to support the migration of ActiveX Documents with the Artinsoft Visual Basic Upgrade Companion which is one of the Artinsoft \ Mobilize.NET tools you can use to modernize your Visual Basic, Windows Forms and PowerBuilder applications.

Currently the Visual Basic Upgrade Companion does not allow you to process ActiveX Document directly, but there is a workaround: in general ActiveX Document are something really close to an User Control which is a element that is migrated automatically by the Visual Basic Upgrade Companion.

This post provides a link to a tool (DOWNLOAD TOOL) that can fix your VB6 projects, so the Visual Basic Upgrade Companion processes them. To run the tool:

1) Open the command prompt

2) Go to the Folder where the .vbp file is located

3) Execute a command line command like:

 FixUserDocuments Project1.vbp

This will generate a new project called Project1_modified.vbp. Migrate this new project and now UserDocuments will be supported.

  

First Some History
 

VB6 allows you to create UserDocuments, which can be embedded inside an ActiveX container. The most common one is Internet Explorer. After compilation, the document is contained in a Visual Basic Document file (.VBD) and the server is contained in either an .EXE or .DLL file. During development, the project is in a .DOB file, which is a plain text file containing the definitions of the project’s controls, source code, and so on.

If an ActiveX document project contains graphical elements that cannot be stored in text format, they will be kept in a .DOX file. The .DOB and .DOX files in an ActiveX document project are parallel to the .FRM and .FRX files of a regular Visual Basic executable project. 

The trick to support ActiveX documents is that in general they are very similar to UserControls, and .NET UserControls can also be hosted in a WebBrowser. The following command line tool can be used to update your VB6 projects. It will generate a new solution where UserDocuments will be defined as UserControls.

 

If you have an ActiveX document like the following: 

 

Then after running the tool you will have an Project like the following:

 

So after you have upgraded the projet with the Fixing tool, open the Visual Basic Upgrade Companion  and migrate your project.

After migration you will get something like this:

 

 

To use your migrated code embedded in a Web Browser copy the generated assemblies and .pdb to the directory you will publish:

Next create an .HTM page. For example UserDocument1.htm

The contents of that page should be something like the following:

 

<html>

<body>

<p>ActiveX Demo<br> <br></body>

<object id="UserDocument1"

classid="http:<AssemblyFileName>#<QualifiedName of Object>"

height="500" width="500" VIEWASTEXT>   

</object>

<br><br>

</html>

 

For example:

<html>

<body>

<p>ActiveX Demo<br> <br></body>

<object id="UserDocument1"

classid="http:Project1.dll#Project1.UserDocument1"

height="500" width="500" VIEWASTEXT>   

</object>

<br><br>

</html>

  

 Now all that is left is to publish the output directory.
To publish your WinForms user control follow these steps.

  1. Create a Virtual Directory:

  1. A Wizard to create a Virtual Directory will appear.

 

 Click Next

 Name the directory as you want. For example Project1. Click Next

 Select the location of your files. Click the Browse button to open a dialog box where you can select your files location. Click Next

 Check the read and run scripts checks and click next

 Now Click Finish

  1. Properties for the Virtual Directory will look like this:

 

NOTE: to see this dialog right click over the virtual directory

 

  1. Now just browse to the address lets say http:\\localhost\Project1\UserDocument1.htm

 And that should be all! :)

 

 

 

The colors are different because of the Host configuration however a simple CSS like:

 

<style>

 body {background-color: gray;}

</style>

 

Can make the desired change:

 

 

 

Notice that there will be security limitations, for example for thinks like MessageBoxes.

You can allow restricted operations by setting your site as a restricted site:

 

For example:

 

 

Restrictions

The constraints for this solution include:

 

* This solutions requires Windows operating system on the client side

* Internet Explorer 6.0 is the only browser that provides support for this type of hosting

* It requires .NET runtime to be installed on the client machine.

* It also requires Windows 2000 and IIS 5.0 or above on the server side

 

Due to all of the above constraints, it might be beneficial to detect the capabilities of the client machine and then deliver content that is appropriate to them. For example, since forms controls hosted in IE require the presence of the .NET runtime on the client machine, we can write code to check if the client machine has the .NET runtime installed. You can do this by checking the value of the Request.Browser.ClrVersion property. If the client machine has .NET installed, this property will return the version number; otherwise it will return 0.0.

 

Adding a script like:

 

<script>

 if ((navigator.userAgent.indexOf(".NET CLR")>-1))

 {

      //alert ("CLR available " +navigator.userAgent);

 }

  else

      alert(".NET SDK/Runtime is not available for us from within " +            "your web browser or your web browser is not supported." +            " Please check with http://msdn.microsoft.com/net/ for " +            "appropriate .NET runtime for your machine.");

 

</script>

Will help with that.

 References:

 

ActiveX Documents Definitions:

http://www.aivosto.com/visdev/vdmbvis58.html

 

 

Hosting .NET Controls in IE

http://www.15seconds.com/issue/030610.htm

 

 

Pesky VB Migration details

During migratio of a simple project, we found an interesting migration details.

The solution has a project with two Forms. Form1 and Form2. Form1 has a command button and in the Click for that command button it performs a code like UnLoad Form2.

Unload 

 

But it could happen that Form2 has not been loaded but in VB6 it is not a problem. In .NET the code will be something like form2.Close() and it could cause problems.

A possible fix is to add some flag that indicates if the form was instanciated and the call the event.

 

 

VSS reset admin password

21. October 2008 05:23 by Mrojas in General  //  Tags: , ,   //   Comments (0)

I had to access an old VSS database and nobody remember any password or the admin password.

The tool from this page http://not42.com/2005/06/16/visual-source-safe-admin-password-reset 

This was a lifesaver!

Scripting your applications in .NET Part 2

14. October 2008 03:10 by Mrojas in General  //  Tags: , , ,   //   Comments (0)

Just more details about scripting

Using the MS Scripting Object

 

The MS Scripting Object can be used in .NET applications. But it has several limitations.

The main limitation it has is that all scripted objects must be exposed thru pure COM. The scripting object is a COM component that know nothing about .NET

 

In general you could do something like the following to expose a component thru COM:

 
   [System.Runtime.InteropServices.ComVisible(true)]
    public partial class frmTestVBScript  : Form
    {
        //Rest of code
    }
 
NOTE: you can use that code to do a simple exposure of the form to COM Interop. However to provide a full exposure of a graphical component like a form or user control you should use the Interop Form ToolKit from Microsoft http://msdn.microsoft.com/en-us/vbasic/bb419144.aspx
 

To expose an object in COM. But most of the properties and methods in a System.Windows.Forms.Form class, use native types instead of COM types.

 

As you could see in the Backcolor property example:

 
public int MyBackColor
{
            get { return System.Drawing.ColorTranslator.ToOle(this.BackColor); }
            set { this.BackColor = System.Drawing.ColorTranslator.FromOle(value); }
}
   Issues:
  • The problem with properties such as those is that System.Drawing.Color is not COM exposable.
  • Your script will expect an object exposing COM-compatible properties.
  • Another problem with that is that there might be some name collision.
 

Using Forms

 

In general to use your scripts without a lot of modification to your scripts you should do something like this:

 
  • Your forms must mimic the interfaces exposed by VB6 forms. To do that you can use a tool like OLE2View and take a look at the interfaces in VB6.OLB
  • Using those interfaces create an interface in C#
  • Make your forms implement that interface.
  • If your customers have forms that they expose thru com then if those forms add new functionality do this:
    • Create a new interface, that extends the basic one you have and
 

I’m attaching an application showing how to to this.

Performing a CreateObject and Connecting to the Database

 

The CreateObject command can still be used. To allow compatibility the .NET components must expose the same ProgIds that the used.

 

ADODB can still be used, and probably RDO and ADO (these last two I haven’t tried a lot)

 

So I tried a simple script like the following to illustrate this:

Sub ConnectToDB
'declare the variable that will hold new connection object
Dim Connection 
'create an ADO connection object
Set Connection=CreateObject("ADODB.Connection")
'declare the variable that will hold the connection string
Dim ConnectionString 
'define connection string, specify database driver and location of the database
ConnectionString = "Driver={SQL Server};Server=MROJAS\SQLEXPRESS;Database=database1;TrustedConnection=YES"
'open the connection to the database
Connection.Open ConnectionString
MsgBox "Success Connect. Now lets try to get data"
'declare the variable that will hold our new object
Dim Recordset   
'create an ADO recordset object
Set Recordset=CreateObject("ADODB.Recordset")
'declare the variable that will hold the SQL statement
Dim SQL    
SQL="SELECT * FROM Employees"
'Open the recordset object executing the SQL statement and return records
Recordset.Open SQL, Connection
'first of all determine whether there are any records
If Recordset.EOF Then
    MsgBox "No records returned."
Else
'if there are records then loop through the fields
Do While NOT Recordset.Eof   
 MsgBox Recordset("EmployeeName") & " -- " & Recordset("Salary")
  Recordset.MoveNext    
Loop
End If
MsgBox "This is the END!"

End Sub
 
 

I tested this code with the sample application I’m attaching. Just paste the code, press Add Code, then type ConnectToDB and executeStatement

 

I’m attaching an application showing how to do this. Look at extended form. Your users will have to make their forms extend the VBForm interface to expose their methods.

 

Using Events

 

Event handling has some issues.

All events have to be renamed (at least this is my current experience, I have to investigate further, but the .NET support for COM Events does a binding with the class names I think there’s a workaround for this but I still have not the time to test it).

In general you must create an interface with all events, rename then (in my sample I just renamed them to <Event>2) and then you can use this events.

You must also add handlers for .NET events to raise the COM events.

 
     #region "Events"

        public delegate void Click2EventHandler();
        public delegate void DblClick2EventHandler();
        public delegate void GotFocus2EventHandler();

        public event Click2EventHandler    Click2;
        public event DblClick2EventHandler DblClick2;
        public event GotFocus2EventHandler GotFocus2;

        public void HookEvents()
        {
            this.Click += new EventHandler(SimpleForm_Click);
            this.DoubleClick += new EventHandler(SimpleForm_DoubleClick);
            this.GotFocus += new EventHandler(SimpleForm_GotFocus);
        }

        void SimpleForm_Click(object sender, EventArgs e)
        {
            if (this.Click2 != null)
            {
                try
                {
                    Click2();
                }
                catch { }
            }
        }

        void SimpleForm_DoubleClick(object sender, EventArgs e)
        {
            if (this.DblClick2 != null)
            {
                try
                {
                    DblClick2();
                }
                catch { }
            }

        }


        void SimpleForm_GotFocus(object sender, EventArgs e)
        {
            if (this.GotFocus2 != null)
            {
                try
                {
                    GotFocus2();
                }
                catch { }
            }
        }



        #endregion
 Alternative solutions

Sadly there isn’t currently a nice solution for scripting in .NET.  Some people have done some work to implement something like VBScript in .NET (including myself as a personal project but not mature enough I would like your feedback there to know if you will be interesting in a managed version of VBScript)  but currently the most mature solution I have seen is Script.NET. This implementation is a true interpreter. http://www.codeplex.com/scriptdotnet Also microsoft is working in a DLR (Dynamic Languages Runtime, this is the runtime that I’m using for my pet project of VBScript)

 

The problem with some of the other solutions is that they allow you to use a .NET language like CSharp or VB.NET or Jscript.NET and compile it. But the problem with that is that this process generates a new assembly that is then loaded in the running application domain of the .NET Virtual machine. Once an assembly is loaded it cannot be unloaded. So if you compile and load a lot of script you will consume your memory. There are some solutions for this memory consumption issues but they require other changes to your code.

 

Using other alternatives (unless you used a .NET implementation of VBScript which currently there isn’t a mature one) will require updating all your user scripts. Most of the new scripts are variants of the Javascript language.

  Migration tools for VBScript

No. There aren’t a lot of tools for this task. But you can use http://slingfive.com/pages/code/scriptConverter/

  Download the code from: http://blogs.artinsoft.net/public_img/ScriptingIssues.zip


 

ADODB RecordSet Save in C# ASP.NET

9. October 2008 04:10 by Mrojas in General  //  Tags: , , ,   //   Comments (0)

I saw this with Francisco and this is one possible solution:

ASP Source

rs.Save Response, adPersistXML

rs is an ADODB.RecordSet variable, and its result is being written to the ASP Response

Wrong Migration

rs.Save(Response <-- The ASP.NET Response is not COM, ADODB.Recordset is a COM object, ADODB.PersistFormatEnum.adPersistXML);  

 So we cannot write directly to the ASP.NET response. We need a COM Stream object

Solution

ADODB.Stream s = new ADODB.Stream();

rs.Save(s, ADODB.PersistFormatEnum.adPersistXML);               

Response.Write(s.ReadText(-1));

In this example an ADODB.Stream object is created, data is written into it and the it is flushed to the ASP.NET response

Categories