As mentioned previously, the migration process is now an ally of every company while attempting to get their software systems revamped. It’s imperative to determine the rules to measure the process throughput, in order to compare all the options the market offers for this purpose, but, how it comes to be described the rules to compare a process where every single vendor employs proprietary technology that contrast from one to another?
After eye-witness the whole process, the ideas impressed in the user’s mind will decide the judgment made to some specified migration tool, and how it performs; but to make sure this judgment will be fair, here are some concepts, ideas and guidelines about how the migration process should be done, and the most important, how it should be measured.
<!--[if !supportLists]-->· <!--[endif]-->Time:
Human efforts are precious; computer efforts are arbitrary, disposable and reusable. An automated process can be repeated as many times as necessary, as long as their design considerations allow the algorithms to accept all the possible input values. Migration processes can be done with straight one-on-one transformation rules resulting in poorly mapped items that will need small adjustments, but regardless of the size of those efforts, those must be human, so these single reckless rules may become hundreds of human hours to fix all this small issues; remember, we are dealing with large enterprise software products, meaning that a single peaceable imperfection can replicate million times. Another possible scenario will be complex rules that searches for patterns and complex structures to generate equivalent patterns on the other side, but as many AI tasks, it may take lots of computer efforts, because of the immense and boundless set of calculations needed to analyze the original rules and synthesize new constructions. For the sake of performance, the user must identify which resources are most valuable, the time spent by people fixing what the tool’s output provided; or computers time that will be employed by more complex migration tools to generate more human-like code.
<!--[if !supportLists]-->· <!--[endif]-->Translation equivalence:
Legacy applications were built using the code standards and conventions for the moment, the patterns and strategies used in the past have evolved ones for good other to became obsolete. During an automated software migration process there must be a way to adapt arcade techniques to newer ones; a simple one-on-one translation will generate the same input pattern and the resulting source code will not take advantage of all the new features on the target platform. A brilliant migration tool should detect legacy patterns, analyze its usage and look for a new pattern in the target platform that behaves the same way. Because of the time calculations explained previously, a faster tool will only mean non-detailed and superficial transformations that will be a poor replica of the original code or in the best scenario a code wrapper will fix all the damage done. Functional equivalence is the key to a successful migration, because the whole concept of software migration is not only about getting the software running in the target platform, it’s about adaptation to a new set of capabilities and the actual usage of those capabilities.
With that on mind, a comparison between different tools can be clearer now. Leaving aside the competitiveness of the market, the readers should identify the facts from the prevaricated marketing slogans, and appraise the resources to be spent during a migration process. Saving a couple of days of computer time may become hundreds of human hours, which at the end will not cure the faulty core, will just make it run.
Before starting any migration from Visual Basic 6.0 to the .NET Framework (either VB.NET or C#), we always recommend that our clients perform at least a couple of pre-migration tasks that help streamline a potential migration process. Here is a brief summary of some of them:
- Code Cleanup: Sometime we run into applications that have modules that haven't been used in a while, and nobody really knows if they are still in use. Going through a Code Cleanup stage greatly helps reduce the amount of code that needs to be migrated, and avoids wasting effort in deprecated parts
- Code Advisor: It is also recommended that you execute Microsoft's Code Advisor for Visual Basic 6.0. This Visual Studio plug-in analyzes your VB6 code and points out programming patterns that present a challenge for the migration to .NET. Some of these patterns are automatically resolved by the VBUC, but even then, you should always use this rule of thumb: if you use high quality VB6 code as input for the VBUC, you get high-quality .NET code as output. Here is a brief example of the suggestion you'll get from the Code Advisor:
- Arrays that are not based on a zero index: Should be fixed in VB6
- Use of #If: Only the part that evaluates to "true" will be converted. This may cause problems after the conversion
- Use Option Explicit and Late binding, declare X with earlybound types: The VBUC is able to deduce the data types of most variables, but if you have an opportunity to fix this in VB6, you should take advantage of it
- Trim, UCase, Left, Right and Mid String functions: The VBUC is able to detect the data type being used and interpret the function (for example, Trim()), as a correct string function (in the example, Trim$()). It still recommended that you fix it before performing the migration.
There are other tasks that may be necessary depending on the project and client, like developing test cases, training the developers on the .NET Framework, preparing the environment, and countless other specific requirements. But if you are considering a .NET migration, you should at the very least take into consideration performing the tasks mentioned above.
Enterprise software is going beyond the line in matters of size and scalability; small companies depend on custom tailored software to manage their business rules, and large enterprises with onsite engineers, deal in a daily basis with the challenge to keep their systems up to date and running with the top edge technology.
In both cases the investment made in software systems to assist a given business is elevated, regardless if it was purchased from another company or if it was built and maintained by the own, it’s never going to stop being critical to update the current systems and platforms.
Any enterprise software owner/designer/programmer must be aware of the market tendencies of operating systems, web technologies, hardware specs, and software patterns and brands; because of the raging nature of the IT industry it takes an eye blink to get obsolete.
Let’s recap about VB6 to VB.NET era, a transition with a lot of new technology, specs and a lot of new capabilities that promise the programmers to take their applications where it seems to be previously impossible like web services and remote facilities, numerous data providers are accessible with a common interface, and more wonders were presented with the .NET framework, however all this features can get very difficult or near to impossible to get incorporated in legacy applications. At this moment it was mandatory to get that software translated to the new architecture.
Initially the idea was to redesign the entire system using those new features in a natural way but this implicates to consume large amounts of resources and human efforts to recreate every single module, class, form, etc. This process results in a completely new application running over new technology that needs to be tested in the final environment, and that will impact the production performance because it has to be tested in the real business challenges. At the end, we got a new application attempting to copycat the behavior of the old programs and huge amount of resources spent.
Since this practice is exhaustive for the technical resources and for the production metrics, the computer scientists research about the functionally equivalent automated processes were used to create software that is capable to port one application from a given source platform to a different, and possibly upgraded one. During this translation process, the main objective is to use as much inherent constructions as possible in the newly generated code to take advantages of the target technology and to avoid the usage of legacy components. In case that the objective is to include a new feature found in the target platform, the application can be migrated and then the feature can be included more naturally than building communication subprograms to make that new capability to get in touch with the old technology.
This process is widely promising because it grants the creation of a new system based on the previous one, using minimum human efforts by establishing transformation rules to take the source constructions and generate equivalent constructions in the desired technology. Nevertheless, this will require human input, especially in very abstract constructions and user defined items.
All the comparisons done before to measure the benefits between redesign and migration, points to identify the second practice as the most cost-effective and fast, but now another metric becomes crucial. The automated stage is done by computers using proprietary technology depending on the vendor of the migration software, but how extensive the manual changes will be? Or, how hard will be to translate the non-migrated constructions?
The quality metrics of the final product will be redefined because a properly designed application will be translated with the same design considerations. This means that a given application will be migrated keeping the main aspects of design and the only changes in the resulting source code will be minor improvements in some language constructions and patterns. This makes the new quality metrics to be: maximize the automation ratio, minimize the amount of manual work needed, generate more maintainable code and reach the testing stage faster.
Aggiorno is an add-in for Visual Studio 2005/2008 that can swallow horrible non-validating markup and help you make an ASP.NET site web standards compliant with little effort. With Aggiorno web developers can improve their ASP.NET or HTML sites by making them comply with the latest web standards and incorporating the latest technology trends. This will immediately mean increased productivity and immediate business value.
Beta 1 has just been released, so you might want to give it a try and send some suggestions to the development team.
Last March I attended the Microsoft Inner Circle conference in Bellevue, WA, in which they presented the 2008 version of Visual Studio Team System. This was my first view of VSTS, and I was impressed by some of the features they included to help developers in tasks such as gathering statistics on their source code, writing and executing unit tests, and looking for potential performance bottlenecks.
We were also introduced to Visual Studio Testing Edition, which contains a set of tools to help QA teams automate tasks such as tracking and managing stabilization processes, controlling code churn and performing load tests.
From a tester’s or developer’s perspective, I have no doubt that VSTS is going to be a great tool; however, I think it still needs to extend its support for Project Management tasks, as well as database design and requirements elicitation, documentation and tracking. We were told that many of these features will be included in the next version of VSTS, code named “Rosario”.
More information on VSTS can be found at http://msdn.microsoft.com/en-us/teamsystem/default.aspx
Here is an excerpt from an article that Greg DeMichillie wrote on Directions on Microsoft April Edition:
"The planned follow-on release to Windows Vista, code-named Windows 7, will not include the Visual Basic 6.0 (VB 6) runtime libraries, Microsoft has begun informing customers. This sets a timeframe for the final end of support for the runtime."
As we have informed on several occasion in this Blog, Microsoft is performing all the normal steps to retire a technology from market. Visual Basic 6 was/is a tremendously popular technology but never the less it will have to go away.
Jarvis Coffin once said: "All technologies fade away, but they don’t die." This is most probably what is going to happen to VB6 (hey.. we still have COBOL code written more than 30 years ago that is alive and kicking!!!) but the question I have for you is: will you embrace the new technology? Or will you fade away with it?
It is time to upgrade your skills as a developer and also to migrate your application to greener grounds.
ArtinSoft has been hugely successful at migrating customers as Eric Nelson (Microsoft UK DPE and blogger) recently mentioned: "Artinsoft have a lot of VB6 migration experience and can help you do the migration - either by licensing their VB Upgrade Companion or by taking advantage of their migration services. Artinsoft are doing some great work with some of my UK ISVs helping them move off VB6."
If you have any questions or comments regarding your migration strategy let's cover them in this blog.
UPDATE March 11th 2009: The title of this post was: "VB Runtime NOT in next Windows". However, Microsoft has recently updated the support policy for Visual Basic 6 Runtime. The new policy states that the VB runtime is now supported for the full lifecycle of Windows 7.
PS: You can read the inflammatory comments I got over the past week below!
We found and interesting bug during a migration. The issue was that when there was an iteration through the controls in the forms, and you set the Enabled property, the property didn't get set.
After some research my friend Olman found this workaroung
foreach(Control c in Controls)
{
ctrl.Enabled = true;
if (ctrl is AxHost) ((AxHost)ctrl).Enabled = true;
}
Do you want to create a program to install your assembly in the GAC using C#. Well if you had that requirement or you are just curious, here is how.
I read these three articles:
Demystifying the .NET Global Assembly Cache
GAC API Interface
Undocumented Fusion
What I wanted just a straight answer of how to do it. Well here is how:
using System;
using System.Collections.Generic;
using System.Text;
using System.GAC;
//// Artinsoft
//// Author: Mauricio Rojas orellabac@gmail.com mrojas@artinsoft.com
//// This program uses the undocumented GAC API to perform a simple install of an assembly in the GAC
namespace AddAssemblyToGAC
{ class Program
{ static void Main(string[] args)
{ // Create an FUSION_INSTALL_REFERENCE struct and fill it with data
FUSION_INSTALL_REFERENCE[] installReference = new FUSION_INSTALL_REFERENCE[1];
installReference[0].dwFlags = 0;
// Using opaque scheme here
installReference[0].guidScheme = System.GAC.AssemblyCache.FUSION_REFCOUNT_OPAQUE_STRING_GUID;
installReference[0].szIdentifier = "My Pretty Aplication Identifier";
installReference[0].szNonCannonicalData= "My other info";
// Get an IAssemblyCache interface
IAssemblyCache pCache = AssemblyCache.CreateAssemblyCache();
String AssemblyFilePath = args[0];
if (!System.IO.File.Exists(AssemblyFilePath))
{ Console.WriteLine("Hey! Please use a valid path to an assembly, assembly was not found!"); }
int result = pCache.InstallAssembly(0, AssemblyFilePath,installReference);
//NOTE recently someone reported a problem with this code and I tried this:
// int result = pCache.InstallAssembly(0, AssemblyFilePath,null); and it worked. I think is a marshalling issue I will probably review it later
Console.WriteLine("Process returned " + result); Console.WriteLine("Done!");
}
}
}
And here's the complete source code for this application: DOWNLOAD SOURCE CODE AND BINARIES
The date has arrived Visual Basic 6 leaves Extended support today.
Rob Helm recently wrote on "Directions on Microsoft": "Some organizations will let support lapse on the VB6 development environment, gambling that any serious problems in the VB6 environment has already been discovered" Additionally, Rob adds: "... organizations remaining loyal to VB6 applications will have to make increasingly heroic efforts to keep those applications running as their IT environments change."
Organizations that GAMBLE with their business continuity, IT professionals that need to make HEROIC efforts to keep applications running! Don't you believe that maintaining an IT organization supporting a business is already enough of an effort to add to the mix unsupported applications?
Do you plan to be a GAMBLING HERO or is it about time to consider ways out of Visual Basic 6?
Well this might be just the right time. ArtinSoft is about to release a new version of the Visual Basic Upgrade companion. The effort required to migrate has been reduced even further and it now makes more sense than ever to automatically upgrade your applications to C# or VB.NET.
Have you been procrastinating the decision to move? Act now!!
One of the nicest features of the Visual Basic Upgrade Companion version 2.0 is the support for Migration Profiles. These profiles give you control over which translations to use for a particular migration, improving the quality of the generated code and applying only the conversions desired (for example, for specific third party components). Profiles are managed through the Profile Maintenance screen, as shown here:
If look at the screen in some detail, you will see some of the features included with the tool. Here you can select, for example, to convert the MAPI (Mail API) library to the Microsoft.Office.Interop.Outlook component. And it shows that this particular conversion has a coverage of 80%. This particular library shows why Migration Profiles are important. If the application you are migrating is an end-user application that is locally installed in the user's desktop inside your enterprise, and MS Outlook is part of your standard installation on these desktops, then it should save you quite a bit of work to let the VBUC perform this transformation. If, however, it is a server-side application where MS Office is very rarely installed, then having this option selected will only cause you additional work later on, as you will have to go through the code and remove the references.
Other good examples are the ADODB and ADOCOMMON plug-ins. Both of them convert code that uses ADO into ADO.NET. How they do it, however, is completely different. The first plug-in, ADODB, converts ADO into ADO.NET using the SqlClient libraries, so it only works with SQL Server. The ADOCOMMON plug-in, however, generates code that uses the interfaces introduced with version 2.0 of the .NET Framework in the System.Data.Common namespace. This allows the application to connect to any database using an ADO.NET data provider that complies with this interfaces - most major database vendors now have providers that meet that specification. So you can use either transformation depending on your target database!
The previous two examples illustrate the importance of Migration Profiles. As you can see in the screenshot above, the tool currently has a large amount of plug-in with specific transformations. This number is expected to grow over time. I will be covering some of these plug-ins in later posts. Stay tuned!
I mentioned
a few days ago that ArtinSoft was about to release a new version of its VB to
.NET migration product. Well, today it is official: finally, the Visual Basic Upgrade Companion
v2.0 has been released! After an incredible amount of work
(kudos to everyone involved), the tool now includes a series of enhancements
basically aimed towards increasing the generated code quality and the overall
automation of the upgrade process, allowing to reduce even further the manual
effort required to convert and compile your VB6 code to VB.NET or C#.
These are just some of the new features and improvements
included in this version of ArtinSoft’s Visual Basic Upgrade Companion (VBUC):
-
Upgrade Manager: The VBUC v2.0 now sports a
dashing GUI and Command Line interface that improves the user experience. Incorporating
a screen to set up migration profiles, it allows selecting and applying only
those features you require for a specific conversion.
-
Support for conversion of multi-project
applications.
-
Migration of mixed ASP and VB6 code to ASP.NET
and VB.Net or C#.
-
Individual conversion patterns designed to
improve the migration of a large amount of diverse specific language patterns.
-
Conversion of unstructured to structured code, reducing
the presence of spaghetti code and improving code maintainability and
evolution. This includes the
transformation of frequently used patterns related to error handling. For
example, the VBUC recognizes “On Error Goto” and “On Error Resume Next”
constructs patterns and replace them with the .NET “Try-Catch” structure. It
also performs “Goto” removals.
-
Improved typing system, which provides
additional information to assign more accurate target types to existing VB6 variables,
functions, fields, parameters, etc.
-
Improved Array migration, such as conversion of
non-zero-based arrays and re-dimensioning of arrays.
-
C# specific generation enhancements:
declarations and typing, events declaration and invocation, error handling,
conversion of modules to classes, indexer properties, case sensitive
corrections, brackets generation for array access, variable initialization
generation, and much more.
-
Migration of ADO to ADO.NET using .NET Common Interfaces.
-
Support for converting many new 3rd-party
components such as SSDataWidgets SSDBGrid, TrueDBList80, Janus Grid, TX Text
Control, ActiveToolBars, ActiveTabs, ActiveBar 1 and 2, etc.
-
New helper classes that offer frequently used
VB6 functionality that is either unavailable in .NET and/or that is encapsulated
for the sake of readability.
-
Automatic stub generation of no-maps as a proven
strategy to manage overall remaining effort towards successful compilation of upgraded
code.
-
And much more!
For more info, you can visit ArtinSoft’s website, and let us know about your specific
migration requirements.
I was expecting the annoucement near the end of the week, but here it is - The Visual Basic Upgrade Companion version 2.0 was released today! Just in time to attend that other tool's funeral ;)
I am still waiting for the official press release, but at least the press here in Costa Rica is already talking about it (link in spanish). So you know, the VBUC2.0 is a considerable improvement over previous versions of the Companion. Some of the most interesting new features are:
-
Solves over 800 issues reported by our consulting staff, testing team, partners and end-users.
-
Significantly reduces the amount of manual work required to compile the migrated application, so you can start the testing earlier in the migration process
-
Improves the quality of the migrated code
-
Adds the concept of Migration Profiles - you can select from a series of migration features and apply only those that you want to a particular migration. This greatly improves both the quality of the migrated code, and decreases the amount of manual work required after the migration. It also allows greater future expandability of the product.
As you probably know, eye candy sells. And it makes your life easier, too. So the VBUC2.0 includes a new Graphical User Interface called the Upgrade Manager, that incorporates all the features and concepts described above into one easy to use environment:
If you have been thinking about upgrading your VB6 applications to the .NET framework, think no more. With this new version of the VBUC you will be able to have your .NET application up and running in no time!
I may be a little late to the obituary, but VB6 support is finally, officially, irrefutably gone. The IDE, as stated in Microsoft's Product Life-Cycle guidelines, "... will no longer be supported starting March 2008". Even though VB6 (or Basic for that matter) didn't enjoy the best reputation as a programming language (best illustrated by the famous Edsger W. Dijkstra quote), you can't deny the huge influence it's had over the past 15 years. The easy-to-use paradigm followed by VB IDEs lent itself to be used by both amateur programmers, that caused many headaches during the years, and professional developers that were really able to harness the power and ease of use to create impressively robust solutions that are still running to this day.
So if you are thinking of moving away form VB6, obviously I'm going to steer you in the direction of the Visual Basic Upgrade Companion. There is, however, another reason for this as well... pretty soon we are going to release a completely updated version 2.0 of the tool, which has some very interesting new features and does an incredible job of converting your VB6 code into the .NET language. Watch this space, as I will be writing about this new version soon!!
I present here the implementation of some useful tasks
In Artinsoft we perform massive migrations of VB6 code to VB.Net
and C#.
And sometimes after migration there are customizations to be
performed on the code, to add new functionality or to set certain new
properties.
The idea was to provide a couple of very simple and puntual MSBuildTask
to illustrate how easy it is to create custom tasks and to provide a starting
point to create new one.
You can freely use this code, just keep this comments and remember this is just
a sample code. There are not warranties. ;) And i made it a rush I know it could have
been written better
Artinsoft
mrojas@artinsoft.com
The implemented tasks are:
RemoveCOMReference |
Removes COMReferences from your project. COM references are for when you are using things thru Interop |
FixOutputPath |
Resets the output paths to bin\Release and bin\Debug |
| AddProjectReference |
Add a reference to another project. A nice feature is that it generates RelativePaths the way Visual Studio does |
| AddSimpleReference |
Add a reference to a very simple references like the ones you add when you click Add Reference and add System.EnterpriseServices |
| ChangeCurrentBuildSetting |
This can be used for a lot of things.
For example to turn on or off the RegisterForComInterop setting
To set conditional compilation variables
To set debug info to pdbonly
The sky is the limit jeje |
The following is a sample project file
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- make sure that the Assembly is in a place where msbuild can find it, a simple way is just to put it
in the same directory of your .proj file -->
<UsingTask TaskName="SomeUsefulTasks.MSBuild.RemoveCOMReference"
AssemblyFile="SomeUsefulTasks.dll"/>
<UsingTask TaskName="SomeUsefulTasks.MSBuild.FixOutputPath"
AssemblyFile="SomeUsefulTasks.dll"/>
<UsingTask TaskName="SomeUsefulTasks.MSBuild.AddProjectReference"
AssemblyFile="SomeUsefulTasks.dll"/>
<UsingTask TaskName="SomeUsefulTasks.MSBuild.AddSimpleReference"
AssemblyFile="SomeUsefulTasks.dll"/>
<UsingTask TaskName="SomeUsefulTasks.MSBuild.ChangeProjectBuildSetting"
AssemblyFile="SomeUsefulTasks.dll"/>
<ItemGroup>
<VSProjects Include="$(Start)\**\*.*proj" />
</ItemGroup>
<!--
Run with
MSBUILD SampleProject.proj /target:COMReference /p:Start="C:\MyCode"
-->
<Target Name="COMReference">
<RemoveCOMReference SourceFiles="@(VSProjects)" ComReferenceName="MSXML2" />
</Target>
<!--
Adds a project reference
Run with
MSBUILD SampleProject.proj /target:AddProjectReference /p:Start="C:\MyCode" /p:ProjectPath="C:\MyCode\MyNewSuperProject\Project1.csproj"
-->
<Target Name="AddProjectReference">
<AddProjectReference SourceFiles="@(VSProjects)" AbsolutePathToProject="$(ProjectPath)"/>
</Target>
<!--
Adds a reference to a standard assembly
Run with
MSBUILD SampleProject.proj /target:AddSimpleReference /p:Start="C:\MyCode" /p:Reference="System.EnterpriseServices"
-->
<Target Name="AddSimpleReference">
<AddSimpleReference SourceFiles="@(VSProjects)" Reference="$(Reference)" />
</Target>
<!--
Resets the OutputPaths to .\bin\Debug and .\bin\Release
Run with
MSBUILD SampleProject.proj /target:FixOutput /p:Start="C:\MyCode" /p:Reference="System.EnterpriseServices"
-->
<Target Name="FixOutput">
<FixOutputPath SourceFiles="@(VSProjects)" />
</Target>
<!--
Adds a reference to a standard assembly
There are several options here for example to set the project debug info to pdb-only do this:
Run with
MSBUILD SampleProject.proj /target:ChangeSettingToPDBOnly /p:Start="C:\MyCode"
Or run with
MSBUILD SampleProject.proj /target:ChangeSettingAddAConstant /p:Start="C:\MyCode"
Or run with
MSBUILD SampleProject.proj /target:SettingComInterop /p:Start="C:\MyCode"
-->
<Target Name="ChangeSettingToPDBOnly">
<ChangeProjectBuildSetting
SourceFiles="@(VSProjects)"
ConfigurationType="All"
Setting="DebugType"
NewValue="pdbonly" />
</Target>
<Target Name="ChangeSettingAddAConstant">
<ChangeProjectBuildSetting
SourceFiles="@(VSProjects)"
ConfigurationType="All"
Setting="DefineConstants"
NewValue="MYNEWVAL"
Add="True"/>
</Target>
<Target Name="SettingComInterop">
<ChangeProjectBuildSetting
SourceFiles="@(VSProjects)"
ConfigurationType="All"
Setting="RegisterForComInterop"
NewValue="true" />
</Target>
</Project>
DOWNLOAD CODE AND BINARIES
I had the requirement of creating a MSBuild custom task that opens a .csproj
adds a reference to another project.
The problem I faced is that references in VisualStudio are generated as relative paths,
so I needed something to help me generate relative paths.
After some Googleing I finally found this code. It was in a long forum discussion
and was posted by a guy named something like Marcin Grzabski. And here it is for posterity.
private static string EvaluateRelativePath(string mainDirPath, string absoluteFilePath)
{ string[]
firstPathParts =
mainDirPath.Trim(Path.DirectorySeparatorChar).Split(Path.DirectorySeparatorChar);
string[]
secondPathParts =
absoluteFilePath.Trim(Path.DirectorySeparatorChar).Split(Path.DirectorySeparatorChar);
int sameCounter = 0;
for (int i = 0; i < Math.Min(firstPathParts.Length,secondPathParts.Length); i++)
{ if (
!firstPathParts[i].ToLower().Equals(secondPathParts[i].ToLower()))
{ break;
}
sameCounter++;
}
if (sameCounter == 0)
{ return absoluteFilePath;
}
string newPath = String.Empty;
for (int i = sameCounter; i < firstPathParts.Length; i++)
{ if (i > sameCounter)
{ newPath += Path.DirectorySeparatorChar;
}
newPath += "..";
}
if (newPath.Length == 0)
{ newPath = ".";
}
for (int i = sameCounter; i < secondPathParts.Length; i++)
{ newPath += Path.DirectorySeparatorChar;
newPath += secondPathParts[i];
}
return newPath;
}
And to use is just do somelines like:
String test = EvaluateRelativePath(@"E:\Source_Code\Code\ProjectsGroup1\Project1", @"E:\Source_Code\Code\ProjecstGroup2\Project2");
//This will genearate something like ..\..\ProjectGroup2\Project2
Well, not exactly. But official
support for Visual Basic 6.0 has certainly ended, as I’ve mentioned on
previous posts.
VB 6 has been used by millions of people all over the world to develop
applications ranging from thousands to millions of lines of code. It’s definitely time to move those significant organizational investments to .NET, and appropriately
ArtinSoft is about to launch a new
enhanced version of its VB to .NET migration product (Visual Basic Upgrade Companion).
Stay tuned for details…
Browsing through some of the good old VB to .NET migration
resources I’ve accumulated through all these years, I rediscovered a Dr.
Dobb’s interview by Scott
Swigart with Jay Roxe. Among
other things, they talked about the motivations for migrating from Visual Basic
6.0 to the .NET platform, either to VB.NET or C#, and some of the benefits of
the new environment.
Putting aside the VB6 support end concerns, he describes the
lifecycle of any application as one of the motivations for a .NET upgrade: “The application has reached a point where
the code has grown beyond its original scope, and it's time to rewrite the
application anyways, and it just makes sense to transition to the latest development
platform at the same time”. Other incentives relate directly to the .NET
Framework’s new functionality and development capabilities, and that’s where
the benefits come under the spotlight. For instance, he mentions that “We're also seeing, particularly for some of
our Web customers, that when they took a VB6/ASP application, and moved it to a
VB.NET/ASP.NET application, it was 300 percent more scalable, and they got 200
percent more throughput from the application”.
Roxe also explains how the ClickOnce technology solves the
DLL Hell issue by providing better deployment and management, checking the
prerequisites availability before installing the application itself, with the
option of setting up version checking and without impact to any other
applications on the machine. There’s also the possibility of deploying a COM
component with an application without having to register it, allowing multiple side-by-side
installations of that component without conflicts.
Finally, he responds to the questions around choosing the
programming language (VB.NET or C#) once you decide to move to the .NET platform,
adding some advice around VB to .NET migrations and pointing some of the
available resources. You can read the whole article here,
and if you have a VB to .NET migration project in your hands or want to share
any experience you’ve had with such upgrades, I’d definitely love to hear about
it.
A quick post to let you all know that Beth Massi, Program Manager on the Visual Studio Community Team, will be doing a series of webcasts on Visual Basic 9. They will be mostly about the new features of VB9, including one about LINQ in VB that I am particularly interested in. Another one of them deals specifically with Visual Basic 6.0 to .NET migrations, called Live From Redmond: Migrating Your Visual Basic 6 Investments to .NET. If you haven't yet considered moving your VB6 application to the .NET Framework, this may be a good place to start. Remember that the end is near....
For more information on the webcasts, check out this post over at Beth's Blog.
In my past life I spent a few eons writing Java code. And it wasn't bad. We had nice tools like Jalopy! that allowed us to have
code in a very standard way.
And I missed that. I've been looking around for something similar but I havent found anything like that :(
Until I found a great post from Chris Eargle, he improved the original solution from Kelvinpinch
Well here's the code.
Public Sub FormatSolution()
Dim sol As Solution = DTE.Solution
For i As Integer = 1 To sol.Projects.Count
FormatProject(sol.Projects.Item(i))
Next
End Sub
Private Sub FormatProject(ByVal proj as Project)
For i As Integer = 1 To proj.ProjectItems.Count
FormatProjectItem(proj.ProjectItems.Item(i))
Next
End Sub
Private Sub FormatProjectItem(ByVal projectItem As ProjectItem)
If projectItem.Kind = Constants.vsProjectItemKindPhysicalFile Then
If projectItem.Name.LastIndexOf(".cs") = projectItem.Name.Length - 3 Then
Dim window As Window = projectItem.Open(Constants.vsViewKindCode)
window.Activate()
projectItem.Document.DTE.ExecuteCommand("Edit.FormatDocument")
window.Close(vsSaveChanges.vsSaveChangesYes)
End If
End If'Be sure to format all of the ProjectItems.
If Not projectItem.ProjectItems Is Nothing Then
For i As Integer = 1 To projectItem.ProjectItems.Count
FormatProjectItem(projectItem.ProjectItems.Item(i))
Next
End If
'Format the SubProject if it exists.
If Not projectItem.SubProject Is Nothing Then
FormatProject(projectItem.SubProject)
End If
End Sub
To use it perform the following steps:
- Go to the VS IDE Tools Option
- Then Select the Macros option and select Macros IDE...
- This will open the macros IDE
- In the Macros IDE navigate to the Module1, and Insert the code
To run the Macro go to Tools\Macros\Macro Explorer
And select FormatAll :)
And last but not least if you want to runit from the command line just do:
devenv /command "Macros.MyMacros.Module1.FormalAll" MyProject.csproj or
devenv /command "Macros.MyMacros.Module1.FormalAll" MySol.sln or
In some migration projects you have to take an incremental approach. You just can't disappear with an application for a few months, and then come back with the application in the target language. Because of this, when we do migration projects, we try to divide the project in smaller milestones, so that developers can continue working on a certain module of the application, while another group migrates a different module.
It turns out that is you are migrating from Visual Basic 6.0 to the .NET Framework (using either Visual Basic.NET or C#), you can do even smaller steps. Microsoft offers the Microsoft Interop Forms Toolkit, a set of tools that you can use to run .NET forms and controls in VB6 applications. This Toolkit allows you to create an even less disruptive migration strategy, by creating an incremental upgrade process in which you can start out by moving some controls first, then some forms, and, before you know it, you'll have your applications running completely in .NET.
I realize this has been out for a while, but it is still worth mentioning, since there's tons of people out there that haven't moved from VB6 yet. This may give all of you some incentive to at least get started with the first incremental steps. :)