One concern when upgrading to a new Microsoft Dynamics SL version is any custom programs. Custom programs will need to be upgraded to the new version as well. Depending on which SL version is the source and which is the destination, this process can either be easy or involved. It has become more complicated in the newer versions than it used to be.
Solomon 4.0 → Dynamics SL 6.5
Between Solomon version 4.0 and Dynamics SL 6.5, custom programs were written in VB6 and upgrading them is a simple process. First, replace the DH files containing the table buffer definitions; technically, that only needs to be done if the table definition changed, but making that change universal is faster and easier. Then, do the same thing with the applic.dh and swimapi.bas files, recompile, and the upgraded program is ready for use. It is possible that some other changes might be needed. For example, if a field was lengthened, the screen may require adjustments, and new fields may need to be added, but these are unusual circumstances.
Dynamics SL 6.5 → Dynamics SL 7.0
Changing from SL version 6.5 to 7.0 was MUCH more involved. That upgrade involved changing from VB6 code to VB.Net. Fortunately, Dynamics provided a utility that would manage much of the process. Running SolomonSDKConversionUI.exe for each project to be converted started the process.
That process rebuilds the FRM, BAS and DH files used in VB6 into the FRM.VB, FRM.Designer.VB, BAS.VB, and DH.VB files used in VB.Net. The Type structures in the VB6 code become Class structures for VB.Net. This conversion program was intended for use on 6.5 code, but it will actually work on any code from version 5.5 to 6.5 (although converting 5.5 code can mess up the SL installation). Any older version source had to be upgraded to 6.5 before it could be converted. One irritating detail about this step is the path and VB project filename for the source and path for the destination cannot contain spaces; Microsoft never did fix that restriction.
The VBTools utility does much of the work converting the code, but it never finishes everything. For example, some of the Type conversions are not done correctly, and they become structures instead of classes. Those structures then need to be recreated as classes manually. The Solomon.VBTools.VB file that takes the place of the Applic.Dh and SwimAPI.Bas files is included in the project as a shortcut. I drop and add the file manually so that it will be included in the directory as it is for a new program. The screen layouts change as well. Fields in standard screens in 7.0 are larger than they were in 6.5, so the screen layout needs to be altered if you want the custom screen to look like the standard ones. Another change here is the measure used for the fields. In 6.5, the height of a text field was 278. That same height is 19 in version 7.0, which usually has field heights of 21.
After redoing the screen layout in the new system, you still need to go through the code to clean up issues. In many cases, there will be syntax errors because the system was not able to change the code. Also, the code has been left in VB6 format. That generally works fine, but it doesn’t match .Net code formatting. For example, the code to change a number variable into a string might be Trim(Str(NumVar)), but then it changes to NumVar.ToString.Trim in the new system. The only real reason for changing the code to the new format is to make it more consistent with any future code, but it does look cleaner and is easier to read as well. You do need to watch some of these changes. For instance, Mid, the VB6 command to take a set of characters from a larger string, becomes SubString in VB.Net, and Mid starts counting characters with 1, while SubString starts with 0. Similarly, several other commands have changes to name or rules.
Finally, don’t forget to change the target CPU to x86 or the program won’t run on a 64-bit machine. This is done on the property screen in the compile tab.
Dynamics SL 7.0 → Dynamics SL 2011
Technically, the upgrade is always from Dynamics SL 7.0 because it uses the same VB conversion program for older versions of the code as a first step. The 7.0 code is run through the DynamicsSLSDKConversion7to8.EXE program. For many programs, nothing will happen; as far as I can tell, all this program does is change the date fields on the screens to the new DSLDate object.
Other than that step, this upgrade is remarkably similar to the earlier version changes, assuming the starting code is fully upgraded to 7.0. Drop the old dh.vb files and import the new ones, and do the same thing with the Solomon.VBTools.VB file. One additional change here: if the new date object is used, then the Target Framework needs to be changed to .Net Framework 3.5. Recompile and the new program is ready for use.
Dynamics SL 2011 → Dynamics SL 2015
The upgrade to version 2015 is the worst yet, and so far I have only tried upgrading from 2011 (older versions will probably be even worse). It starts out similar to the previous version – you run the solution through the DynamicsSLSDKConversion.Exe program (here, at least, they have corrected the problem with spaces in the source path). Below is a screenshot of the only error that I have gotten at this point. Picking up that conversion from this point, I did not notice any problems.
Every program I have upgraded has had at least 100 errors listed, even when the conversion works. First things first. On the Property screen references tab, there will be missing references that will need to be manually dropped and re-added. Microsoft.Dynamics.SL.Controls and Solomon.Kernel always come up with “the system cannot find the reference specified,” but there could be other files missing as well (e.g., the Controls and Kernel files are found under C:WindowsMicrosoft.NetassemblyGAC_32). This will correct most of the errors.
The next step is the ubiquitous replace data buffers and the Solomon.VBTools.VB file for the new version. There is a new trick here, however. The replacement files need to come from the Microsoft DynamicsSLSDKVB directory; the new tools file is Microsoft.Dynamics.SL.SDK.vb. At this point, the system may indicate that all errors are corrected, but frequently opening the form design view puts paid to that hope. Most commonly, the system indicates it is using .Net Framework 3.5, but it has the files for .Net Framework 2.0 in place, causing problems for the date. I fixed that situation by changing the program to use .Net Framework 4.0.
Every program that I have upgraded to version 2015 has seemed to run into a different issue at some point during the conversions, requiring some new change to fix that project. Be prepared for surprises. If you should have any questions about upgrading your Dynamics SL software to SL 2015, please contact us at any time.
For additional tips and tricks regarding Microsoft Dynamics SL and ERP products, subscribe to our blog.
