In VB6 ActiveX-EXEs or ActiveX OLE Server where used for several
reasons. Sometimes it was performance (because it allowed you to run
your code in another process) and sometimes as way to share resources
between several applications, like connection information, database
connections, mainframe info, etc.

During migration some of this ActiveX-Exes can be migrated as simple
Assembly DLLs, but other require more attention. Specially if they have
global variables that hold state shared by several programs.

In that is your case what are your options then?

1. Convert those ActiveX-Exes to Windows Services.

This option is simple. You modify your migrated assembly to work as a Windows Service. The easier way to do that is:

2. Convert those ActiveX-Exes using the Artinsoft ActiveX migration helpers.

Sometimes, you need your migrated application to replicate some of
the original ActiveX EXE \OLE DLL VB6 characteristics. For example you
need your ActiveX-EXE to start just when the first instance is created
and to resemble the VB6 logic for Process creation\destruction.

For that purpose Artinsoft has created some helpers that our
migration tool is able to automatically use in the generated code if it
detects that this functionality is needed.

The migration tool will modify your ActiveX-EXEs or OLE Servers to
be Windows EXE and the helper will then locate the assembly that
contains the desired Class, create an instance and initilize a Remoting
channel to the desired classes. Settings as SingleUse and MultiUse are
also taken care by the helpers.

3. Other possible alternatives are using WFC and COM+ that I will comment in another post.

A quick post to let you all know that the recording of last week’s webcast I did on compatibility options for Windows 7 is now online. In this webcast I briefly covered different compatibility options available for Windows 7, mentioning things like virtualization (such as XP Mode) and Remediation, and the focusing on the benefits of using automated migration tools to get the application off VB6.0 and into .NET so it can take advantage of the new APIs available in Windows 7 (Taskbar API, touch API, etc).

There are still many myths out there surrounding software migrations. Through all the years we have found not only that many people still ignore that there are automatic migration tools available, but some believe that automation is just more trouble than it’s worth, and that, besides, it is just plain better to start from scratch. To concur with this idea is, for starters, to simply devalue all of the effort and thought that was put into developing the application, therefore willing to risk years of business knowledge embedded in these systems.

In any case, the truth is that a rewrite from scratch implies a much more difficult task, but due to these misconceptions, valuable resources are wasted in projects that sometimes just never get to see a successful ending. There’s no doubt that any software renewal project isn’t a simple, overnight task, but a well-planned automated migration can make the process comparatively painless. So once you learn about the availability of advanced migration technologies that allow generating code of a superior quality, with a much lower project cost, time and risk, you will definitely agree that using automated migration tools as part of an overall software renewal initiative is the most viable way to leverage the current investment in legacy applications and move them to the latest platforms.

With that in mind I just wrote a white paper highlighting the main myth-debunking reasons why an automatic migration is a far better software modernization approach than a manual rewrite, based not only on ArtinSoft’s own experience in migration projects but on all the customer and industry analyst feedback and evidence gathered over the years.

I have been studying your writings on extending the WebBrowser control, and verified that the extended web code you wrote for C# compiles and works fine in VS 2010 beta, against FrameWork 4.0.

Many thanks for the valuble code and writing !

I am "stuck" on how to read the contents of an IE browser page when the page is displaying a local file, like the contents of the Favorites folder.

All my attempts to get at the Document or DomDocument by casting it to the usual mshtml.dll interfaces fail.

I am NOT asking you to answer my question, or respond, but if you ever get interested in blogging about this aspect of use of IE, I think many people would be interested.

I have done a lot of research on the net, and posted my own question on StackOverFlow : so far not one real pointer, and, possibly, this is not "doable" (?) : maybe what you are seeing when IE shows a file contents is a kind of "virtual explorer" view that is not parseable.

best, Bill xxxxxx”

And I decided to take at look at it to see if I could be of any help and I found out that it is easy and doable.

And now you can access the special folder from your code. As Bill mentioned, that “page” or “special page” is not real HTML and not parseable but you can examine its contents for example you can do something like:

a. First type a new SourceName. The source name is used by the VBUC to identify the element that you want to map. NOTE: If you are migrating just one Project, you just enter one custom maps line with the the source name of the class you want to rename. If your are migrating several project you must enter an additional line like <ProjectName>.<ClassName> for example Project1.Interface that is because for other projects that have Project1 as a Reference they see that class as Project1.Interface and not just Interface.

b. Set the Map Type. For classes we call it a Type Map. For Functions, Subs or Properties we call it a member map.

c. We now change the New Reference Name. For a class we call a “Reference Name” to every time a the class is used to define a variable. For example each Dim x as Class1, or every appearance as a parameter, like Sub Foo(x as Class1).

d. We set the Reference Action to Modify.

e. And we set the NewDeclarationName to InterfaceClass and the DeclarationAction to Modify

f. To make sure that Keyword renamed declarations are mapped with your custom maps configuration, you have to add a line just the same as the one you had just entered but type Interface_Renamed in the SourceName

6. Now you have to activate it in your profile. Click on the Edit button for profiles in the main VBUC window

7. If you don’t have a Profile now, In the Profile Maintenance Dialog click New, and type a name for your Profile.

8. In your profile Select the custom maps configuration you just created:

//Adding event handlers is now very simple
wbEvents.NewWindow += new SHDocVw.DWebBrowserEvents_NewWindowEventHandler(wbEvents_NewWindow);

wbEvents2.NewWindow2 += new SHDocVw.DWebBrowserEvents2_NewWindow2EventHandler(wbEvents2_NewWindow2);
}
void wbEvents2_NewWindow2(refobject ppDisp, refbool Cancel)
{
//If you want make popup windows to open in your own window // you need to assign the ppDisp to the .Application of // the WebBrowser in your window

Make an initial migration of the VB6 source code

4. Open the Explorer and navigate to the location of your VB6 code (For example C:\MergeExample\Sample1)

5. Under the directory where your code is located, create a new directory called GreenCode (For our example this directory will be C:\MergeExample\Sample1\GreenCode )

6. Copy your migrated code to GreenCode (for our example it means copying the contents of C:\MergeExample\Sample1\VB6_UpgradedCode to the C:\MergeExample\Sample1\GreenCode). All this is important to helps us stablish a base line for comparison and merge

7. Open Microsoft Visual Studio 2005

8. On the Team Explorer locate your project (for example MergeExample) and double click on SourceControl

9. On the Source Control Explorer toolbar click the Add Files button

10. Click the Add Folder… button and select the GreenCode folder we had just created

11. Check in the GreenCode. IMPORTANT. Add a descriptive Comment. We recommed at least setting this information:

Green Code Date

VB6 Source Code Date/ version

VBUC version used to generate the Green Code

12. Create a brach of the Green Code

Create a Branch of the GreenCode directory and call it MigratedCode. For example in the target field type: $/MergeExample/Sample1/MigratedCode

After branching you will node a MigratedCode folder under Sample1 in the Source Control Explorer

Performing the Continuous Migration Process

1. Check out the green code

2. Open the VBUC and migrated again the VB6 Code. In our example the code is in C:\MergeExample\Sample1\VB6

3. Copy the new contents of the Upgraded folder and overwrite the contents of folder GreenCode (in this case copy contents from C:\MergeExample\Sample1\VB6_UpgradedCode\Upgraded to C:\MergeExample\Sample1\GreenCode).

5. In our example we know that we modified the Form1.vb file so we select the “Merge changes in merge tool” option

TIP: Typically you will just keep changes in target branch because you have already worked on those files. Specially for resource files, project files, bitmaps, etc you will leave the file in the target branch.

6. The merge tool will appear showing the different changes and providing you a simple way to select what version to take or to manually edit the result

7. When you are done with the Merge tool click close a dialog indicating that all conflicts have been solved will appear. Click Yes

8. Click close in the Resolve Conflict dialog and if asked to accept the merge result click yes

The Source Control Explorer might show marks in the modified files.

9. Right click on the migrated code and select check in changes

10. Type an appropiate comment indicating which versions where merged and press Check In

This post will show you the necessary steps to configure Microsoft Visual Studio 2005 to use a Team System Project. In this example we will use a Team Project created to illustrate Continuous Migration with VBUC and MS Team System 2005, called MergeExample.

1. Start Microsoft Visual Studio 2005

2. Go to the File Menu\Open\Team Project…

3. Dialog is presented, where you can choose your Team Foundation Server, and the Team Project to use. For these Continuous Migration example we’ll assume a project called MergeExample.

4. The Team Explorer is shown, with your selected project. Expand the elements for the Team Project you previously selected.

5. We now have to map our local directories to bind them to the source control system. On the expanded tree, double click on the Source Control Node

9. On the Edit Workspace dialog type a description for your source control and select the source control Folder we had created (for this example it is $/MergeExample) and the directory for your code (for this example it is C:\MergeExample).

NOTE: if a message box about a pending update is shown, just click ok.

Now you have successfully mapped your directories, and you can start setting up your VB6 code for continuous migration

Last month we delivered a webcast around the different options to get applications originally
developed in Microsoft Visual Basic 6.0 running on the Windows 7 operating
system. It also covered some of the business reasons for getting applications to
work with Windows 7 and the benefits provided by that operating system and the
.NET Framework. We did this with Microsoft Latinamerica, so it was in Spanish, but many people asked for an English version of the presentation. Hence, we partnered again with Microsoft to develop a similar webcast entitled “Visual Basic 6 and Windows 7: Alternatives for Application
Compatibility”, scheduled for Thursday, October 15, 2009 1:00 PM Pacific Time. This live
event is part of Microsoft’s “Momentum” initiative, which is designed for growing
and mid-sized organizations and provides expert advice, tips, and techniques to
align IT with your strategy and drive your business forward.

Recently, one of customers in the UK, an
Independent Software Vendor with headquarters in Bristol, told us that they managed
to save about 14 man/months by using ArtinSoft’s VB
to .NET tool to migrate their flagship application, comprised by 59
VB6 projects and a total of more than 550,000 lines of code.

We are talking about a
critical, comprehensive processing platform used by insurers, managing agents,
third party administrators and business process outsourcers, with installations
in the UK, Ireland, USA, Middle East, Far East, China and Africa, and Activus
really needed to ensure compliance for these customers in the international
health insurance sector.

There were definitely
some time constraints, plus the value and complexity of the business logic
embedded in the application didn’t favor a manual rewrite. So they licensed the
Visual Basic Upgrade Companion and performed
the migration in-house, and managed to maintain the current application’s
architecture while moving the visual controls to .NET native controls.
Additionally, coding patterns were consolidated, and data access models (ADO) were
upgraded to ADO.NET.

In the end, Activus not
only was able to cut down the migration time substantially, but the benefits of
the Visual Basic Upgrade Companion went beyond time and cost reductions: the
resulting code was far superior from the one generated by other migration
tools. As Chris Routleff-Jones, Solution Architect at Activus puts it: “We found the Visual Basic Upgrade Companion
to be a very powerful, easy to use migration product. Not only did it speed up
the conversion process, allowing us to save time and money, but we ended up
with high quality, 100% native .NET code. In fact, we were particularly
impressed by the VBUC’s ability to analyze the code and detect patterns that
are upgraded to .NET-like, native structures, making the output fully readable
and maintainable”.

Please invoke the Registry editor, add the "HideMenu" DWORD value to the following Registry key, and set its Value to 0: HKEY_LOCAL_MACHINE\SOFTWARE\Developer Express\CodeRush for VS\9.1 This should make the "DevExpress" menu visible.

Well, as long as I have tested it, they exactly the same. From the MSDN you can even read

“I could have selected the ref keyword here as well, and in fact both result in the same machine code at run time. The out keyword is simply a specialization of a by-ref parameter that indicates to the C# compiler that the data being passed is only being passed out of the called function. In contrast, with the ref keyword the compiler assumes that data may flow both in and out of the called function.”

“When marshaling pointers through P/Invoke, ref and out are only used with value types in managed code. You can tell a parameter is a value type when its CLR type is defined using the struct keyword. Out and ref are used to marshal pointers to these data types”

So what should you use? Well using the out keyword for PInvoke will just add some information or documentation to your method, but because these functions are implemented in C or C++ they might treat an out parameter as an IN parameter so I really prefere to use ref when I’m calling functions with PInvoke.

.NET has been around for quite a while. According Wikipedia it has been around since on 3 April 2003. So now there exist applications developed for .NET Framework 1.0 or 1.1 and people need to migrate them to Framework 2.0 or Framework 3.5.

It is the general impression that there is not a direct path to 3.5. As Zain Naboulsi explains in his blog you can go from 1.1 to 2.0 then from 2.0 to 3.5. And From 2.0 to 3.5 the migration is a no-brainer because, both, 3.0 and 3.5 are based on 2.0.