Earlier this week we launched an joint initiative with Microsoft and Avanade in the UK for helping Visual Basic 6.0 developers move their applications to .NET. The initiative consists of several parts:
The initiative is UK-only at the time, but if you want to take advantage of these time-limited deals feel free to contact us. The press release for the campaign can be found here and at our website. Eric Nelson from Microsoft has been heavily involved - you can read his blog post on the initiative here.
The campaign has been well received so far. In the two days since launch, we already have several leads interested in both offerings!!
Jointly with the Visual Basic 6.0 migration campaign we are launching in the UK, today we released the Visual Basic Upgrade Companion Developer Edition. This is a scaled down version of the Visual Basic Upgrade Companion, targeted at individual developers that want to migrate their Visual Basic 6.0 applications as fast and painlessly as possible. It has a license that is valid for three months and allows you to migrate an application of up to 50,000 lines of code.
The VBUC Developer Edition does have some fewer features than the fully-fledged Visual Basic Upgrade Companion. All the features that we decided to include in the Developer Edition, however, are targeted towards automating as much of the migration process as possible. So, we left out features that have been introduced by the request of our enterprise customers over the 7+ years the tool has been on the market (yep, we were already doing VB6 migrations before the official release of .NET - and it wasn't all fun with the Betas). We made it so that getting an application up and running in C# or VB.NET is as simple as possible.
Here you can see the VBUC Developer Edition in action (video recorded by yours truly :) ):
And, as an introductory offer, The VBUC Developer Edition will only cost £199 for a limited time. So why wait?
Starting tomorrow January 27th we will be
engaging with Microsoft on a campaign aimed
towards helping companies and developers in the UK move their Visual Basic 6.0
applications to the .NET platform. This is not the first time we provide
migration solutions in that territory,
since we have lots of customers
there already (you can read some of our case studies and references here), but this is the first occasion
we join forces on a massive scale effort locally with 2 of our major partners:
Microsoft and Avanade. ArtinSoft will be providing tools, resources and
guidance, along with limited-time offers during this campaign. For example, we’ll
have a 10% discount on licenses of our Visual
Basic Upgrade Companion for the enterprise level, while launching the Visual
Basic Upgrade Companion Developer Edition at a special introductory price
of only £199. For those who require a turn-key solution, we have also partnered
with Avanade to deliver the most
comprehensive, cost-effective Visual Basic 6.0 to .NET migration solution. So
if you are based in the UK and still have Visual Basic 6.0 investments that
need to be leveraged, click here to learn
more about this campaign, and contact us as soon as possible to take advantage
of this unique opportunity.
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
Here is some XBAP code using a WinForms WebBrowser. They designer does not like it a lot but it works:
XBAPWithWinforms.zip
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.
We were watching with great interest and seriously thinking about the nice videos from Anders Hejlsberg recently presented at PDC2008, regarding programming languages and particularly covering the future of C# 4.0; (JAOO). Both talks offer really interesting perspectives that can be useful when thinking ahead about new challenges and opportunities on Software maintenance and particularly automated tools for supporting Software evolution, as it is the case of Software migration, usually.
We realize migration as a fundamental piece in fulfilling maintenance requirements derived from platform/framework evolution (as it will be the case of C# 4.0) beyond legacy migration in a traditional sense (I mean very old languages). That is if we consider shorter cycles of evolution not necessarily critical cases (i.e. those ones pushing to the edge of obsolescence a user application). We mean those new platform features offering better performance, scalability and maintainability chances, for instance. Thus, moving VB6 to VB.Net is a first stage. Moving to "a better" VB.Net a second one. We will return to this statement later on.
We first notice that in his presentation Hejlsberg talked about C# but it is assumable VB.Net will be providing in other flavor similar features and orientation as has been for these languages so far. Another very interesting player on this game is F# which deserves by itself another post; so we leave it aside just for the moment.
The language orientation Hejlsberg describes is one where C# becomes more multi-paradigmatic which essentially means for him covering three general aspects: more dynamic, concurrency and declarative expression power. These three aspects are clearly interrelated to each other in his vision.
The dynamic (DLR) facet should provide alternatives to compete with the proliferation of scripting languages a wave where strongly static typing is avoided (considered harmful for productivity by someone) even tough such kind of (rebel) languages will be sooner or later turn reasonable and will be offering capability for static types. Otherwise testing and maintenance will be more problematic as they are per se. In addition, the "dynamic" static type (no word playing here) will allow a cleaner interoperability with other .Net languages (scripting specially) and with COM itself, as he explains.
Turning something that looks like a compiler directive into a type might be disputable, we personally think; but independently of the name used the approach sounds very flexible because it is something open and controlled via an interface the programmer can use for his/her own needs. This also complements very well with the "var" declaration giving the impression of being programming in a dynamic language. However, we can imagine potential misuse and abuse of such a feature; hence the VS might play an important role during development.
Avoiding Javascript, using C# instead, is a subtle suggestion we might (over)infer from the message and if accepted we see an interesting space in the Web domain.
The declarative aspect, which takes the form of adopting functional programming (FP) idioms, look for avoiding, explicitly, side effects and mutability providing the compiler with better chances of optimization for parallelism as well as more readability and understanding. In other cases, more intuitive forms of static typing are now possible concerning co- and contra variance, by the way which is an added-value.
Concurrency should help to take advantage of multi-core computing without affecting program intentionality where FP is naturally an option for achieving that (see post1 and post2 )
An exciting challenge/opportunity derived from this vision (which is also valid for C# or VB.Net not necessarily product of a migration) is the ability to offer tools for platform related evolution without changing the language: refactoring for platform adoption, in other words (RPA).
A quite interesting and rich part of the C# 4.0 package is likewise "meta-programming" and the "compiler as a service" orientation. In particular, there will be a much more complete code model for C# available with an API for compiling in C# itself (presumably in F#, too!), as we see from the presentation. In such a case the space for developing tools for RPA should be easier which is an interesting point to analyze, we believe. In terms of how exploit the compiler as a service to produce a "migration as a service" in analogy.
My first language ever was GW-Basic. I was a teenager doing in summer work at a company that made polls about hair products and things like that. At that time I didn’t had a computer. They were tooooo expensive.
And I found a manual for GW-Basic. I stole it, to make a copy, my boss found out and he fired me :(. But then I had the power!! jeje. With my cousin Esteban we started out first programs. And we got our first sale :) :) :). It was the typical POS software for a small video rental company.
Ahhh, and that was just the beginning.
So, I really appreciate basic, with all its strengths and weaknesses. I do most of my development now in C#, I think due to my C++, java years, and know I am more used to its syntax, and I really prefer C#. But I consider Basic a real treasure.
Well recently while digging in the Microsoft Dev Labs I discovered SmallBasic. I was just browsing for some new stuff and I am glad to have found this jewel.
Artinsoft (the company I work for) is a company that has devoted a lot of time in the research of automatic software migration to other platforms.Not for nothing one of our flapship products is Visual Basic Upgrade Companion, so basic in any form is always a delight for me. (I will soon post a brief article about bringing VBScript back to life in VB.NET just wait and see)
Ok. Back to SmallBasic.
First of all. The interface is great!!!
It has a cool intellisense guide and you can even extend it :)
And they even resurrected LOGO!
I just hope to write a cool Turtle Graphics routine soon!
:)
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?
A long long time ago, I faced the problem of installing an assembly on the GAC from code. And I even posted the code in my blog
http://blogs.artinsoft.net/mrojas/archive/2008/04/09/install-assembly-gac-with-c.aspx
Recently Jose Cornejo wrote me on my blog because the code was not working, and he finally showed me the right way to do it. It was sooo easy.
His solution was:
1. Add a reference to System.EnterpriseServices.dll to your project
2. Write code like the following:
System.EnterpriseServices.Internal.Publish p = new Publish();
p.GacInstall(@"C:\ClassLibrary1.dll");
p.GacRemove(@"C:\ClassLibrary1.dll");
Thanks a lot Jose for your help.
These interesting functions have a long history, since the BASIC language, QuickBasic
and earlier versions of Visual Basic. There isn’t much documentation on them but you
can look at very good reference as the one published by Matthew Curland
titled Unofficial Documentation for VarPtr, StrPtr, and ObjPtr
Well enough history, now let’s get back to the the migration part. If you’re reading this
post it might be, because you have VarPtr, StrPtr or ObjPtr calls in your code and you
want to move those calls to C#.
Well we have good and bad news.
Bad news are that the .NET world is a lot different than VB. Remember that your code
is running in the managed sandbox, and to get the address of variable you are probably
dealing with unmanaged memory, so some things might not work.
Good news are that I am one of those that believe that there are no imposibles,
it’s just a matter of the cost of developing the solution :)
Let’s see at some alternatives:
VarPtr can be use to get pointers to vaiables. This can be solved using Unsafe code:
VB6
Dim l As Long
Debug.Print VarPtr(l)
C#
class Program
{
[DllImport(@"DllTest1.Dll")]
static extern void Foo(IntPtr p);
static void Main(string[] args)
{
int l;
unsafe
{
int* pointerToL = &l;
Foo((IntPtr)pointerToL);
// Print the address stored in pointerToL:
System.Console.WriteLine(
"The address stored in pointerToL: {0}", (int)pointerToL);
}
}
}And The implementation for Foo is a C function like:
extern "C"
{
__declspec(dllexport) void Foo(int* data)
{
*data = 100;
}
}Unsafe code like this will work for VarPtr cases where you have primitive types,
like int, short, char variables.
Structures are more tricky and you will require pinning the memory to avoid some
other problems. But in general doing Interop with structures is very tricky and
I will publish another post about this.
Unsafe code must be enabled at the assembly level and the assembly might need to
be signed.
StrPtr is very similar to VarPtr but it mostly to provide efficient marshalling
to Unicode functions. In most of cases like:
Declare Sub MyUnicodeCall Lib "MyUnicodeDll.Dll" _
(ByVal pStr As Long)
Sub MakeCall(MyStr As String)
MyUnicodeCall StrPtr(MyStr)
End SubThe StrPtr declaration is no longer needed because the .NET Interop mechanism can
handle most of this marshaling automatically.
ObjPtr is the most tricky of all because it can be used in COM scenarios to get
pointers to Interfaces implemented by a class.
In .NET scenarios this will involve only using classes that are exposed by COM.
I have use code as the following
for some of those cases:
Object myComObject = null;
//..init code
IntPtr pIUnknown = Marshal.GetIUnknownForObject(myComObject);
IntPtr pIDesiredInterface = IntPtr.Zero;
Guid guidToDesiredInterface = new Guid("XXXXXXXX-XXXX-XXXX");
Marshal.QueryInterface(pIUnknown,
ref guidToDesiredInterface,out pIDesiredInterface);
As always there are exceptions to the rule. These are just some general solutions.
Directly accessing the memory is really something not desirable in a .NET application and in most
cases you should remove that code for something else, but if you can’t I hope these examples
guide you in this process.
Microsoft's Patterns & Practices group released last week a new version of the Application Architecture Guide. This book provides you with the best practices in the design of .NET applications. I recommend you read this when planning the evolution of your migrated applications after you reach functional equivalence in the .NET Framework.
Download the Application Architecture Guide, version 2.0
The Visual Basic Upgrade Companion is able to generate both C# and Visual Basic .NET code from the original Visual Basic 6.0 code base. Thus, when doing a migration project with our tools, you can choose either language. This decision is a challenge itself, especially if you aren't doing any .NET development before the migration. You have to measure the skill set of your staff, and how comfortable they will feel with the transition from VB6 to either language.
Here are some points that are normally thrown around when comparing C# and VB.NET:
- Support: Both languages are well supported by Microsoft, and are first-class citizens on the .NET Framework. Neither one will go the way of the Dodo (or the way of J#, for that matter).
- Adoption: C# seems to have higher adoption than VB.NET. A completely unscientific and in no way statistically valid quick search on the books section of Amazon, however, returned 15,429 results for C#, and 2,267 results for Visual Basic .NET. Most of our customers migrate to C# instead of VB.NET as well. So there may be some truth in this.
- Perception: C# was developed from the ground up for the .NET Framework. This has affected VB.NET's mind share, as C# is viewed as the new, cool language in town. C# is also seen as an evolution of C and C++, which are considered more powerful languages. And we've all heard at least one Visual Basic 6.0 joke - which means that even though VB.NET is a completely different beast, the "VB" name may work against it.
- Familiarity: Visual Basic .NET's syntax is very similar to VB6's, so it is assumed that VB6 developers will feel right at home. This may or may not be true, since they will need to learn all the differences of the new environment, not only the syntax.
- Cost: It also looks like people with skills in C#, on average, earn more than those with skills in VB.NET. This is also something to keep in mind when deciding which language to choose.
.NET allows you to mix programming languages, even on the same Solution. So you could have some developers work in C#, while other work in VB.NET - basically let them use the language they feel more comfortable with. DON'T. This may become a maintenance nightmare in the future. You should definitely standardize on just one language, either C# or VB.NET, and stick with it. That way you'll save time and resources, and overall have a more flexible team.
Also, keep in mind that the biggest learning curve when coming from the VB6 world won't be the object orientation of VB.NET or the curly bracket syntax of C#. It will be learning the .NET Framework. That is what you should plan training for, not for a particular language. Learning the syntax for a new programming language is pretty trivial compared to the effort required to correctly use all the APIs in .NET.
All in all, you can do anything on either language. I personally like C# better, mainly because I started with C, C++ and Java before moving on to .NET development. Coding is C# is "natural" for me. But you can develop any type of application in C# or VB.NET, as there's no meaningful difference under the covers.
When planning the migration of large applications you may want to use a phased approach. This means that as you migrate the first portions of your application to .NET, you will need to keep the interaction with the Visual Basic 6.0 code. Depending on your application's architecture, you can use one of the following approaches:
- Interop Forms toolkit: Now at version 2.0, it simplifies the process of embedding .NET forms and controls inside VB6 applications. It is recommended for GUI-intensive applications
- Binary Compatible .NET DLLs: This technique allows you to expose .NET components through COM. It is recommended for multi-tier apps, especially if you want to migrate the back end before you migrate the front end. It allows VB6 and ASP applications to continue using the same components even after they are migrated to the .NET Framework.
The current version of the Visual Basic Upgrade Companion is able to add binary compatibility information to these components. The VBUC does this automatically to ActiveX DLLs, and it is as easy as activating the "COM Visible" feature in the Upgrade Profile:
Once you have the .NET code, you need to check Register for COM Interop in the Project Properties page in Visual Studio.NET, and then you are all set. Your VB6 and ASP applications will continue working with the newly migrated .NET components, transparently, while they await their turn for a migration.
You can read more about this feature on the COM class exposure page.
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:
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
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.
We recently did some quick tests on the results of some projects that we just finished migrating to compare the binary size and memory footprint of the resulting migrated .NET application and the original Visual Basic 6.0 application. Here is a brief summary of the results.
Binary Size
We have seen that binary sizes remain very similar or decrease by a small margin when compared to the original Visual Basic 6.0 binaries. There is a small amount of application re-factoring that contributes to this reduction, though, such as consolidating all shared files to a common library (instead of including the same files in several VB6 projects, which increases the code base and binary size).
You do have to take into account the space required by the .NET Framework itself, that varies from 280MB to 610MB.
Memory Footprint
Our observations on the memory footprint of migrated .NET applications, when compared to the original VB6 applications, is consistent to what we've seen with the binaries' size. .NET applications have higher initial memory consumption, since the .NET Framework sets up the stack and heap space at startup, and you have to add the memory required by the JIT compiler. Even with these constraints, a quick revision of applications that we've migrated for customers shows that the memory consumption is, on average, around 10% less than in VB6 (these are no scientific measurements, just based on monitoring memory consumption during the execution of test cases).
We have also seen that .NET normally maintains a more consistent memory usage pattern, while VB6 applications has more peaks where the memory consumption goes up, then back down. This is caused by the .NET Framework holding on to resources until the Garbage Collector runs, and the overall improvements in memory management included in the .NET Framework.
.NET applications have a memory overhead associated with the .NET Framework itself. This is more noticeable in small applications, but overall, is a tradeoff required for running on a managed environment. According to the .NET System Requirements, the Framework requires at least 96MB (256MB recommended) of RAM to run. In our experience, however, you should have at least 512MB (1GB recommended) of RAM to run migrated applications comfortably (on Windows XP).
The performance of a migrated .NET application, when compared to the original VB6 application, is normally very similar or better. The only instances when we have seen a performance decrease is when doing an important re-architecture or when the database engine is changed (from Access to Oracle, for example). Every once in a while we also run into issues with the Garbage Collector, but fortunately they are not that common and are easy to detect.
One thing to keep in mind is the way .NET loads assemblies, and how they are executed. .NET assemblies are compiled to an intermediate language, called CIL (Common Intermediate Language, formerly MSIL). When these assemblies are executed, the default behavior for the .NET Framework is to use a Just-In-Time compiler, which compiles the CIL code for a method to native code "on the fly" the first time the method is called. This implies an overhead on this first call, which suffers from a (normally acceptable) performance impact while the JIT compiler runs. Once a method is compiled, though, it is kept in memory, so the performance of subsequent calls is not affected. Once the code is in memory the performance of the .NET application is normally better than the performance of the VB6 application. You can find more information on JIT here.
It is worth mentioning that you can run ngen.exe on the application to compile the CIL assemblies to native code. This may improve application startup and first run times. Here's an interesting take on whether to ngen or not to ngen.
Check out this performance optimization book in MSDN, called Improving .NET Application Performance and Scalability. It is slightly outdated, but the concepts still apply and are useful to improve the performance of migrated applications.
Today we published a new White Paper, Planning a Successful VB to .NET Migration: 8 Proven Tips. In it, we share some tips on things that you should be aware of when migrating your applications.
This is the first in a series of White Papers we will be releasing in the next months. The idea is to share the knowledge we have accumulated over the years performing Visual Basic 6.0 migrations to the .NET Framework. We have been involved with Microsoft in this type of engagements since the very beginning of the platform, and faced lots of issues in the process. This has shaped our current methodology, which, even though is still improving, has proven itself with solid results (a you can read in the recently released case studies). Hopefully you will find them very useful when faced with a migration task at your organization.
If you are familiar with VB to .NET migration projects, you
certainly know by now that this is not a trivial task. And with the state of
the economy today, saving up on scarce, valuable resources is a must. That’s
when an automated software migration solution proves to be the most viable
approach, constituting the most cost-effective, non-disruptive method of application
renewal.
I recently read an excellent article in ASP.NET PRO magazine, where Alvin Bruney offered some
insight on the challenges of migrating VB6 applications, providing some
estimation on the overall effort. For starters, he accurately notes how a large
part of the cost in these projects is related to the QA process, something
we’ve definitely seen in large, complex enterprise application upgrades, as it
usually represents around 50% of the total time.
He then provides some numbers regarding the cost for VB to
.NET migration projects: $1/LOC for simple applications, $3-$7/LOC for large
enterprise systems, and $10-$15/LOC for the more complex ones. However, this
varies a lot from one project to another, depending not only on the complexity
of the application and target requirements, but also on the quality of the tools
and the skills available for the migration. For example, due to a proven
methodology, consultants with broad experience in VB to .NET migration projects
and powerful conversion tools, a turn-key solution delivered by ArtinSoft,
taking care of the complete migration up to functional equivalence in the
target language, is generally between $1-$2 per line of source code. This includes the Supplier Testing activities,
though not the User Acceptance Testing, where the customer finally certifies functional
equivalence through predefined test cases. And of course there are other
post-migration costs involved, like those related to the new application’s deployment
and enhancement, but I think it is safe to say that the cost per line of code
for the migration itself, on a turn-key basis, is rarely higher than $3.
Moreover, when
time to market is a critical factor, this automated migration solution just
can’t be beat. For example, a recent customer estimated that rewriting from
scratch his highly complex, business critical, 100,000+ LOC VB6 application
would take him up to 2.5 years, while using ArtinSoft’s comprehensive solution
allowed him to release the C# version in less than 6 months. And using only
about 1/17th of the resources required for a rewrite. Expect the
case study soon, but trust me: we’re not talking n00bies here ;-) And another
example I mentioned on my last post
described how a recent customer
cut down the project time in 1 year, representing savings of about $160,000.
On the other hand, calculating how much it will cost for someone who licenses
our Visual Basic Upgrade Companion to perform the migration in-house is more complicated,
since it depends greatly on his dexterity. But just to provide another example
of how much our solution reduces the effort, another customer with a 550,000
LOC application recently told us he managed to save 14 man/months by using ArtinSoft’s tool
internally, instead of the Upgrade Wizard that ships with Microsoft’s Visual
Studio.
In any case, as Bruney wrote on the aforementioned article “automation
is the key to containing cost”. But watch out for conversion tools that will
only cause you to waste your time and money. Some of our customers have tried
some of these options in parallel before choosing our tool, but a few were
lured instantly by the deceivingly low prices. Most of the latter have come to
us in the end, frustrated with the poor results.
By the way, the article says that “the migration tool takes
you to VB.NET only”. I assume the author is talking about the Upgrade Wizard,
since even a couple of the tools I referred to above convert to C#, but the Visual Basic Upgrade Companion is
the only one that allows migrating effectively to both VB.NET AND C#. Finally,
if you have settled for C# as the target language, I should warn you again
about the infamous double-jump approach, that is, converting from VB6 to VB.NET
and then to C# (the author mentions this option, though he doesn’t exactly
recommends it). We’ve seen a couple of customers who tried that and found it
really problematic, to say the least. In fact, they finally decided it was a
whole lot easier starting all over from VB6 and using our tool to move to C#
directly.
As I mention in a post last week, we recently released version 2.2 of the Visual Basic Upgrade Companion. The previous version, 2.1, added some new things, but focused mostly on "under the covers" improvements, and fixing several issues reported with version 2.0. However, for this release, we do have several exciting new features that should make migrations from Visual Basic 6.0 go much smoother. Among these, we can mention:
Custom Mappings
The Visual Basic Upgrade Companion enables the user to define customized transformations for the upgrade process execution. This technique allows to implement coverage for non-supported legacy components and to enhance and fine-tune the existing support. I already covered Custom Maps on this post and you can read more about this on the Custom Maps page.
Data access - new flavors available
The Visual Basic Upgrade Companion converts the data access model on your VB6 application (ADO, DAO, RDO) to ADO.NET, using the either SQLClient data provider or the classes defined in the System.Data.Common namespace. Using the latter will allow your migrated application to connect with most major .NET database providers. Version 2.2 added support for the automated migration of DAO and RDO to ADO.NET, and greatly improved the migration of ADO to ADO.NET. More information here.
Naming conventions refactoring
This feature lets the end-user migrate his Visual Basic 6 code to VB.NET or C# with standard Naming Conventions. This feature is a compound of common naming conventions for .NET languages, and use standard coding practices for C# and VB.NET. You can find more information on this and the next feature in this page.
Renaming mechanism
The renaming feature changes the name of an identifier and all of its references in order to avoid conflicts with another name. Some of the conflicts solved by the VBUC are:
- Keywords: The VBUC must rename the names that are the same as keywords from Visual Basic .NET and C#. Moreover, the VBUC should take into account the target language (Visual Basic.NET or C#) to recognize the keywords that apply for each case.
- Case sensitive issues (C#): Visual Basic 6 is a case insensitive language, but C# is not. The VBUC must correct the name references used with different cases to the case used in the declaration.
- Scope conflict: This is necessary when a Type declaration element has the same name as the type declaration. If this case is detected the element declaration must be renamed along with the references to this type element.
- Conflicts with .NET classes: This section applies for Forms and UserControls, mainly, because they could declare some member names that are part of the corresponding class in .NET (in this case System.Windows.Forms.Form & System.Windows.Forms.UserControl). These members must be renamed in order to avoid any conflict.
User Controls and Custom Properties
In Visual Basic 6.0 user controls expose their programmer-defined properties in the property list on the designer window. These user properties can be configured to be displayed in a specific category and based on these settings. The Visual Basic Upgrade Companion can determine the most appropriate type and settings for the resulting properties to have functional equivalence with the original VB6 user property. I plan on elaborating on this feature in a future blog post.
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.