We just uploaded build 1.00.04.

As you can  read in the VersionHistory.txt file, this build sports many new minor but inmportant features:

• we added support for the MS Calendar ActiveX control, including data binding with DAO and ADO sources
• we fixed a serious bug related to splash screen in Windows Forms application - which occasionally caused VB Migration Partner to crash - and provided an easy way to avoid that the same bug in your own converted VB.NET projects
• we changed the way AxWrapperGen works, so that it now creates one single project instead of two.
• two new menu commands let users export and import user settings - no need to fine-tune VB Migration Partner's behavior when you install a new edition or install it on a different computer

 

 

We also uploaded a few interesting KB articles, that can help you work around some common problems including:

• [PRB] Pragmas related to arrays might not work if applied to a ReDim statement
  
• [PRB] Changing the type of a variable causes a Type Mismatch compilation error
• [PRB] A nonexisting property is generated for a control in the *.Designer.vb file
• [PRB] A locked EXE or DLL file causes the migration process or compilation command to fail

Just as important, we fixed a few minor bugs related to the DateTimePicker and WebBrowser controls, the SetType and ReplaceStatement pragmas, the AxWrapperGen utility.

Happy migrations... as usual! 

We all know that writing software requires a vast assortment of skills and, above all, a lot of patience. You usually need the latter to feel comfortable when you realize that you've wasted hours and days over someone else's bug.  Here's the story.

Like many commercial applications, VB Migration Partner has a splash screen. No big deal. VB Migration Partner is written in VB2005, therefore we could use VB.NET application framework. As a matter of fact, defining a splash screen in VB.NET is as easy as selecting an item in a combobox in the Application tab of the My Project designer.

During the beta test period a few users reported that at times VB Migration Partner threw an exception at launch, immediately after closing the splash screen. We never managed to reproduce the problem on our computers. Fortunately the exception occured quite rarely. Until a user running Windows 2000 reported that he was seeing the exception at nearly every launch. After installing VB Migration Partner on Windows 2000 in our lab, we could indeed verify that we had a problem.

 

It took a while to find out that we weren't  the only ones suffering from this issue. As a matter of fact, Microsoft recognizes that it is a VB.NET bug. Fortunately, they also offer a workaround. According to whis workaround you must create an invisible form from inside the Form_Load event of your splash screen, something like this:

   Private Sub Form_Load(ByVal sender As Object, ByVal e As EventArgs) _
          Handles MyBase.Load
     Dim frm As New Form
      frm.Opacity = 0
      frm.ShowInTaskbar = False
      frm.FormBorderStyle = FormBorderStyle.None
      frm.Show()
      Return frm
   End Function

Unbelievably, this code makes the problem vanish away! You can find more details in this Microsoft KB article.

We realized that *all* applications written in VB.NET could suffer from this issue, thus we added a method to our support library, named SplashScreenBugFix6, which creates the invisible form for you. You just need to add an InsertStatement pragma in the original VB6 splash screen form, so that a call to this method is automatically generated anytime you convert the VB6 project:

    ' in the VB6 project
    Private Sub Form_Load()
      '## InsertStatement SplashScreenBugFix()
      ' more code in the Load event
   End Sub

VB Migration Partner does a superb in dealing with Windows API calls. Here's a summary of the features that it supports and that are out of reach for the Upgrade Wizard included in Visual Studio 2005/2008:

• converts As Any parameters, by creating all the necessary overloads
• deals correctly with API methods that take a callback address (e.g. EnumWindows, EnumFonts)
• provides recommendation about the .NET object/method that can effectively replace the API method; we cover 300+ different API calls. (Enterprise Edition only)
• in a few cases, it automatically replace API calls with calls to the corresponding .NET object/method
• ensures that string immutability doesn't prevent the VB.NET code from working correctly (see this article)
• generates the correct MarshalAs attributes for elements in Type (Structure) blocks
• correctly translates fixed-length strings inside Type blocks, so that they work correctly when passed to the Windows API method
• automatically initializes static arrays inside Type blocks, so that you don't get unexpected crashes when invoking an API method that expects to find a buffer there
• creates a wrapper method that ensures that orphaned delegates don't cause an unexpected runtime exception, an advanced programming technique discussed in this KB article (Enterprise Edition only)
• includes the VB6WindowsSubclasser class that helps you correctly migrate subclassing-based techniques (as explained here)

In spite of all these innovations, there are cases when you still need to manually edit either the original VB6 code or the converted VB.NET. This happens, for example, if the original code uses the VarPtr, StrPtr, or ObjPtr functions to pass memory pointers to an external API method. These three functions aren't supported under VB.NET and there is no simple way to simulate them.

The good news is that in the vast majority of cases you don't need to deal with memory pointers under .NET, because the .NET Framework offer a valid "pure" alternative to the API method in question. In this article I'll illustrate how you can take advantage of VB Migration Partner features to reduce manual edits to the very minimum and take advantage of the convert-test-fix methodology.

For simplicity's sake, let's focus on one of the simplest API methods, the GetSystemDirectory Windows API. Here's a piece of VB6 code that displays the system directory path:

    ' Main.Bas module
    Public Declare Function GetSystemDirectory Lib "kernel32.dll" Alias "GetSystemDirectoryA" _
        (ByVal lpBuffer As String, ByVal nSize As Long) As Long

    Sub Main()
        Dim buffer As String, length As Long, windir As String
        buffer = Space(256)
        length = GetSystemDirectory(buffer, Len(buffer))
        winDir = Left(buffer, length)
        MsgBox winDir
    End Sub

The first step is in refactoring this code so that you make all the Declares private and move them to another BAS module, that exposes them by means of standard VB6 methods. (If you usually write tidy and maintainable VB6 code, odds are that you have already taken this step.)

    ' This is the APIHelpers.Bas file
    Private Declare Function GetSystemDirectory Lib "kernel32.dll" Alias "GetSystemDirectoryA" _
        (ByVal lpBuffer As String, ByVal nSize As Long) As Long

    ' returns the Windows directory
    Public Function SystemDirectory() As String
        Dim buffer As String, length As Long
        buffer = Space(256)
        length = GetSystemDirectory(buffer, Len(buffer))
        SystemDirectory = Left(buffer, length)
    End Function

The code that actually displays or otherwise uses the Windows directory path is now simpler. Notice that we explicitly include the module name (APIHelpers) in the method call. This tip reduces the odds that another method with same name exists elsewhere in the project, but the technique explained later works even if you don't include such a name:

    ' the Main.Bas module
    Sub Main()
        Dim windir As String
        winDir = APIHelpers.SystemDirectory
        MsgBox winDir
    End Sub

At this point you have a VB6 project that works exactly like the original one, but it is better organized and structured, with all Declares statements gathered in one single module. Let's see how to migrate this code to VB.NET and get rid of all dependencies from non-NET code.

First and foremost, we prepare a VB.NET module that exposes the same methods as the original APIHelpers.bas but doesn't use any Declare statement. Here's how we can render the SystemDirectory function using native .NET calls:

    ' This is the APIHelpers.vb file (VB.NET)
    Module APIHelpers
        Public Function SystemDirectory() As String
            Return Environment.SystemDirectory
        End Function
    End Module

Next, we use an ExcludeCurrentFile pragma to exclude the APIHelpers.bas VB6 module from migration process and we use an AddSourceFile pragma to add the APIHelpers.vb VB.NET file to the converted Visual Studio project. The neat result is that the code in Main now calls the .NET version of the method, which doesn't use any unmanaged calls:

    ' This is the APIHelpers.Bas file
    '## ExcludeCurrentFile
    '## AddSourceFile "c:\vbnet\modules\apihelpers.vb"

    Private Declare Function GetSystemDirectory Lib "kernel32.dll" Alias "GetSystemDirectoryA" _
        (ByVal lpBuffer As String, ByVal nSize As Long) As Long
    ' ... remainder of module as before...

This solution works great, but we can improve it. In fact, a (minor) problem is that the resulting VB.NET code still uses wrapper methods and doesn't look like the "native" .NET code that an experienced VB.NET developer would write. Fear not, because all you need is a project-level PostProcess pragma:

    ' This is the APIHelpers.Bas file
    '## ExcludeCurrentFile
    '## project:PostProcess "(APIHelpers\.)?SystemDirectory", "Environment.SystemDirectory"

Notice that I dropped the AddSourceFile pragma because you don't need the wrapper method any longer (at least in this simplified example). Using similar techniques you can provide a .NET equivalent for most methods that require API calls under VB6, including methods that take arguments.

One of the long-terms goals we have in Code Architects is to apply these concepts on a larger scale to create VB6 helper modules and their corresponding VB.NET versions, to help all VB6 developers to easily migrate their API-intensive applications. Just stay tuned, as usual!

We received (and happily publish) another great feedback from one of our beta testers. The original text is in Italian, but I translated it for you here:

Thanks, CodeArchitects! And a special thank to Francesco Balena for the job he did in developing this great VB6/.NET migration tool.

Few people in this industy believed that such a product could be implemented and could have been so effective, including Microsoft who never really invested in a migration tool. Our company invested a lot of time and money on VB6 products, and we left abandoned to our destiny when VB.NET was released, together with many VB6 developers. Code Architects managed to create such a tool, thanks to their determination, perseverance, and deep knowledge of both migration techniques and VB6/VB.NET inner workings. From now on, VB6 applications *can* be migrated, at last!

We have adopted VB Migration Partner since the beginning of the beta test program, and we stressed it on large complex projects (over 110,000 lines of code) that contain both custom and 3rd-party components, ADO, intensive Windows API usage, advanced graphics, sockets, even a script compiler. We always got great results and were able to migrate our projects by just adding a few migration directives (pragmas) to teach VB Migration Partner how to behave in a few special cases.

Giampaolo Lionello
Software Development Manager
Prometeo S.p.A.: www.prometeo.com

 

What can I add to Giampaolo's words? I have seen their app in action and was impressed by their care for details. The most innovative detail is the presence of a custom script compiler, which allows partner vendors (and even power users) to customize every little detail of the application to fit their requirements. VB Migration Partner has been able to migrate the script compiler easily and quickly, which was quite remarkable.

 

Giampaolo and his team at Prometeo also provided many good pieces of advice. For example, they managed to migrate the entire data layer (about 25,000 lines) into a working VB.NET library in just a few hours. They then replaced the old VB6 data layer with the new VB.NET component and everything worked fine. There was a double jump from COM and .NET - VB6 calling VB.NET which was using ADO - yet the new data layer was only marginally slower (about 6%) than the original VB6 code. To their surprise they realized that this overhead was caused mainly by the many string concatenations inside the data layer compoment.

The obvious solution was to use a StringBuilder, but we went one step further: we added the StringBuilder6 class to our support library. This is a custom data type that looks exactly like a string (it supports the & operator) but it internally uses a StringBuilder. They were able to optimize all concatenations by just adding a few SetType pragmas. On top of that, we improved our code analysis engine to automatically flag all string concatenations inside loops and suggest which string variables could be turned into StringBuilder6 objects for highest efficiency.

Well, I really mean "what are the options to have your VB6 application survive in the next decade?". After nearly 30 years in the field - I started my Computer Science studies in 1979, go figure! - many of which spent consulting for companies in Europe and United States, I have seen many tecnology revolutions, including the advent of IBM PC and of Windows 1.0. Each one thaught me a little piece of experience.

Let's quickly see the alternatives. 

1) DO NOTHING (AKA "IF IT AIN'T BROKE, DON'T FIX IT")
If the application is at the end of its life cycle, for example because it doesn't fullfil a widespread need any longer, you might decide to have it die of a natural death. There is no reason to invest in a dying creature, therefore you might stay with VB6 and just fix some major bugs when your users complain aloud. Don't add any new feature or extend it in any way, because it would be too expensive too.

2) EXTEND THE VB6 APPLICATION USING COM INTEROP AND THE FORMS INTEROP TOOLKIT
In this case you leave the main application in VB6 but extend it by invoking .NET components using COM Interop, or display .NET forms using Microsoft's Forms Interop Toolkit. Version 2.0 of this add-on is a major improvement, as it even supports hosting of .NET controls inside VB6 forms. Best of all, the toolkit is fully supported by Microsoft and comes with full source code. [Thanks to Rob Windsor for remainding me of this option, see comments]

While the toolkit is free, adopting it has some obvious and hidden defects and costs, though. First and foremost, this approach isn't really a solution to the problem, is more of a technique to soften the migration path and lessen its impact on your organization. If you need to migrate because your app doesn't work well under Windows Vista, or because it's slow, or because you don't want to rely on a language that Microsoft doesn't support any longer, using COM Interop and the Forms Interop Toolkit is just a way to postpone the time when you truly need to find a reliable solution. Second, the communication between the VB6 and VB.NET portions of the application is often awkward and leads you to inefficiencies (due to COM Interop) and complex roundtrips that don't make your code easily maintanable.

The bottom line: you should use the Forms Interop Toolkit only in the bigger picture of a phased migration (as Rob suggests in this comment). That is, while a group of developers is working on the porting from VB6, another group is already extending the application using VB.NET. Before taking this approach, you should compare it with the effort required by migrating it to VB.NET in one step using a *good* migration tool (ours, that is :-) )

3) CONVERT TO VB.NET, USING THE UPGRADE WIZARD AVAILABLE IN VISUAL STUDIO
Why not giving it a try? it's free! While your hard disk spins for hours trying to convert your real-world business app, you can have enough time to google for less-then-gentle comments about this tool from the VB community. Let's skip to next option.

4) CONVERT TO VB.NET, USING VB MIGRATION PARTNER
Using our conversion tool to migrate to VB.NET makes sense in many cases. First, when the original application works well and is thoroughly tested, but needs to be extended with new features and implementing these extensions with VB6 would be too difficult or expensive. Second, when the application is so large that rewriting it from scratch would require a very intensive test phase. Third, if time-to-market is essential to beat your competition and make your existing users happy. In these cases you can leverage VB Migration Partner higher speed and precision (as noted by our beta testers)

5) CONVERT TO VB.NET, USING ANOTHER 3^RD-PARTY TOOL
There are other VB6-to-VB.NET migration tools on the market. Choosing a conversion tool is a critical decision, so you might want to ask our competitors for a trial version and compare it with our VB Migration Partner. Please do it! Please compare its feature, precision, and speed with VB Migration Partner and then let us know. If you don't have time to waste, however, ask yourself the following questions before considering another conversion tool:

a) how many VB Migration Partner's feature does this tool support? for example, does it fully support all 60+ VB6 controls, drag-and-drop, graphic methods, arrays with any LBound, Gosubs, As New semantics, IDisposable objects, As Any parameters and callbacks in Declares, etc. 
b) are there any significant features that this tool support and that VB Migration Partner doesn't?
c) why they don't make their entire documentation available online before you buy?
d) why don't they dare to publish real-world VB6 apps and the VB.NET code that their tool generates?

As far as we know, Code Architects is the only vendor who has uploaded dozens of VB6 code samples and the corresponding, converted VB.NET project, to let potential customers see and test the VB.NET applications we produce. We don't upload artificially-conceived tiny VB6 projects that highlights the tool's strengths and hide its weakness. Instead, our code sample section gathers open-source VB6 projects taken from the Internet, and we guarantee that we edited neither the original VB6 code (which is in fact downloadable from its original URL) nor the converted VB.NET.

Now ask yourself: why no other vendor took this obvious step to show the world how powerful their tool is?

6) MANUALLY RE-WRITE IT TO VB.NET
In some cases, manually re-writing the application to VB.NET is a viable solution. Well, let me be absolutely honest on this point: in (very) few cases, this is the solution we recommend to our customers. If the application is a huge amount of contorted spaghetti code, has a orrible architecture and a ugly user interface....well, in this case you don't want to spend more time and money on automatic porting, because you would also port these issues to VB.NET. 

When weighing a complete re-writing from scratch against automatic porting, you should take several factors into account, including:

a) rewriting often takes from 50% to 90% of the time and money that was necessary to write the original application. (Sorry, no official statistics on this, just our field experience...)
b) you need a team of developer who are experienced in both VB6 and VB.NET, and they also need to be familiar with issues related to the specific application, therefore you can't simply hire them from outside your company
c) how do you cope with continuous edits/improvements to the original VB6 code during the months required by the rewrite? In other words, can you count on something similar to our convert-test-fix methodology?
d) can really you afford the extra time required by a complete re-write? what will your competitor do in the meantime?

7) MANUALLY RE-WRITE TO C#, JAVA, OR ANOTHER LANGUAGE
I heard that a few ISVs are taking this path. In my opinion this is an irrational decision, often motivated by the anti-VB (or even anti-Microsoft) feeling that is so fashionable today. Let me explain why you shouldn't even think of jumping from VB6 to any .NET language other than VB.NET.

Rewriting a complex VB6 application into a different language has all the drawbacks of rewriting it to VB.NET (see point 6), plus the many problems that you have when switching from VB.NET to C# or Java. How do you implement On Error Resume Next in C#? How do you render a DTPicker control in Java without carefuly mapping each and every property, method, and event? But the decisive argument is: do you have enough developers who are equally familiar with VB6 and C# or Java and the application being migrated?

Briefly stated: taking this route is a technological suicide similar to point 1), except it takes longer, costs more, and is more agonizing. You can only hope that your competitors are in love enough with C# or Java to invest their energies in this option. If you hear that they are doing it, relax and be happy: you don't have anything to worry about for a long time :-)

8) CONVERT IT TO C# USING AN AUTOMATIC CONVERSION TOOL
Come on! To get an idea of how tough this "solution" (so to speak) is, take all the issues listed at point 5) and multiply them by all the problems mentioned at point 7). Then double the result to have a more reasonable estimate of the actual cost and effort.

More seriously, just think of this: there are a few commercial tools on the market that can automatically migrate VB.NET to C#, for example Instant C# or C-Sharpener for VB. I have actually used a couple of these tools, they do a great job. However, they still require a few manual edits after the conversion, to adjust minor differences between VB.NET and C#. The main reason is that the resulting C# code doesn't look like native C# and requires some fixes to be more readable and easily maintainable.

Before your consider this approach, ask yourself two questions:

a) if you believe that automatic conversion between two .NET languages (VB.NET and C#) is difficult, how can you expect that a tool be able to automatically convert from VB6 to C# in one single step?
b) on the other hand, if you think that conversion from VB.NET to C# can be fully automated, why not going from VB6 to VB.NET using our VB Migration Partner (or another tool, if you prefer) first and then using Instant-C, C-Sharpener for VB, or another similar tool for doing the final move to C#?

If you really want a C# app as the final deliverable of your conversion efforts, keep in mind that jumping from VB6 directly to C# doesn't give you more than switching from VB6 to VB.NET first and then from VB.NET to C#. Well, it actually does give you something more.... many more headaches, for precision's sake :-)

Yesterday we received this comment from one of our early beta testers. I must share it with you:

We knew our tool was more accurate than other tools on the market, but Brian’s experience is simply amazing: With just a few pragmas, they had a running .NET application in less than one hour!

Brian told me they are now working on details, such as inter-program communication – their VB6 app used DDE, which isn’t currently supported by VB Migration Partner – but most of the migration has been completed… in one fifth of the time it took the “other” migration tool just to parse the VB6 project

Now, that means fast!

Now that VB Migration Partner is out, we can disclose a few comments from our beta testers. Here’s the one coming from Lorenzo Barbieri (LinkedIN profile). Lorenzo is arguably the most active Italian blogger, writes on several magazines (including Italian edition of MSDN), speaks at international conferences, and is a very active MVP. Yesterday he blogged on VB Migration Partner; his post is in Italian, but  I have translated it for you here:

Seven months after the launch of the http://www.vbmigration.com/ web site - and about two and a half years after we wrote a first prototype - we are excited to announce that VB Migration Partner 1.0 is finally available.

True, it took a bit longer than we expected. Our beta testers reported a few elusive bugs, that we promptly fixed, but above all they give us hints and suggestions on how to improve our tool. As a result, we added many new pragmas, support for batch migrations, optimized execution for n-tier applications, include files, advanced code analysis techniques, and much more. We now support Visual Studio 2008 and the integration with Microsoft Team System. We wanted to write the best conversion tool from VB6 and VB.NET, and we did it.

In these months VB Migration Partner has proven to be a very flexible tool, able to fit the most demanding migration needs. It is being used to migrate VB6 projects of all kinds and sizes, from graphical games to mission-critical bank and insurance software, from little utilities to "monsters" business apps that count over 10 million lines. One of our customers is using it convert an interpreter for a custom programming language.

Along the way we learned more ways to improve the quality of migrated code and expanded our knowledge base with dozens of articles, which explain how to achieve the most from this tool. The great thing about VB Migration Partner is its flexibility (provided by pragmas) and its open architecture, which allows you to be in control of how VB.NET code is generated, how to convert forms containing 3rd party controls, and more.

The "convert-test-fix" methodology has been welcome by all our customers, especially those who have large "legacy" applications to take care of, that can't simply be thrown away when the VB.NET version is ready. As a matter of fact, one of our customers is planning to keep both the VB6 and VB.NET versions in sync for at least one year, until they complete the conversion and all their users have switched to the .NET version. To ensure that the two versions are "functionally equivalent" at all times, they will use batch migration and custom-made plug-ins that leverage VB Migration Partner's extensibility model. Just another evidence of how flexible our tool is.

---

Many developers wrote us and asked about our licensing policy. Our goal was to make VB Migration Partner a viable solution for software companies of all sizes as well as individual developers and smaller software shops. As a result, we are offering VB Migration Partner in two editions:

• VB Migration Partner Professional supports the vast majority of the features described on our Web site and can convert VB6 projects of up to 50,000 executable lines. (Empty lines and remarks aren't included in the count, but lines at the top of .frm files are.)
• VB Migration Partner Enterprise is the full-featured version, can migrate larger VB6 projects, performs more sophisticated code analysis and refactoring, supports batch conversions and Microsoft Team System, and is the preferred choice for N-tiered applications. Users of the Enterprise Edition can purchase additional user licenses and the full source code of the support library.

Unfortunately, at this time we can't offer a demo version that is freely downloadable, but we plan to remedy in the future. If you need to test our tool against your VB6 code, let us know.

All VB Migration Partner users benefit from a subscription period, during which they are allowed to download all the releases that have produced in the meantime. The subscription period is 3 months for the Professional edition and 6 months for the Enterprise edition.

Finally, we are launching the Early Adopter Program (EAP): for a short period you can purchase VB Migration Partner and double your subscription period: six months for the Professional edition and one year for the Enterprise edition. Start converting your VB6 applications right now and protect your investment at the same time!

Find more information on our web site.

Yesterday we worked hard to fix a subtle bug related to project groups, plus other minor stuff related to the Data and TabStrip controls.

Today is a nationa holiday here in Italy, but our beta testers abroad can download version 0.98 and play with it during the weekend. (We know for sure that some do! )

 

This is truly a milestone in our release story. We have added many new features, including support for Visual Studio 2008 and for batch migratons. A number of KB articles describe how to use these new features, for example

[HOWTO] Generate Visual Studio 2008 project

We have added many new pragmas:

PreInclude and PostInclude pragmas allow you to include a piece of VB6 code (before the parsing step) or a piece of VB.NET code (after the migration is completed); they even support recursive inclusion (an include file can contain other PreInclude and PostInclude pragmas). The PreInclude pragma can be used in a *.pragmas file and in practice allows you to have all these *.pragmas file reference the same settings stored in a centralized file.

The OutputMode pragma now supports an Uncomment mode, which allows you to includ a block of remarked out VB.NET code and have it un-remarked during the migration process. (It is a great way to include large pieces of VB.NET code in the middle of a VB6 source file.) You can find an usage example here:

[HOWTO] Exclude portions of VB6 code from the migration process and replace it with custom VB.NET statements

We changed the way we deal with Empty and Null values. In previous releases, these values were migrated to VB6Empty and VB6Null constants, and both of them were set equal to Nothing. Using constants was necessary to support Null and Empty values when they appear as default values for optional parameters, as in this statement

    Sub Test(Optional x As Variant = Null)

However, using constants didn't make it possible to map the null value to DBNull.Value, and a few beta testers complained about this. Thus we decided to map these values to Empty6 and Null6 properties, which by default are equal to Nothing and DBNull.Value, respectively, but can be changed if necessary. You can find more details in this article:

[HOWTO] Deal with Null and Empty values

Another minor improvement on previous releases: we have added the VB6Config class that gathers all the settings that you can change at runtime to fine tune the library's behavior, as explained here:

[HOWTO] Determine whether unsupported member throw an exception at runtime

[HOWTO] Ignore fatal error at runtime

The new VB6Config.FocusEventSupport lets you work around a key difference in how VB6 and VB.NET deal with LostFocus and Validate events:

[INFO] Controlling the LostFocus and Validate event sequence

We are including a new extender that allows you to create a text file containing the list of all the migration issues and warnings. It's a precious feature when you migrate multiple projects in batch mode. You can read more details in this article:

[HOWTO] Create a report with all the migration issues and warnings

We also added a few KB articles that illustrate non-obvious way to use PostProcess pragmas, for example:

[HOWTO] Modify project-level options in VB.NET programs

[HOWTO] Enforce project-level Option Strict Off settings in VB.NET programs

Last but not the least, we have fixed 35 bugs. As usual, beta tester can find the complete list in the VERSION HISTORY.TXT file.