Specific steps by team
Work In progress...
Last updated
Work In progress...
Last updated
This section will explain how to execute some of the demos commonly used for testing on the WFNet Conversion Tool to Web Converter.
Pre-requisites
Latest Version of WFNetConversionTool
Visual Studio at least 2019 from here
Node.js from here
To migrate a solution using the WinForms Conversion Tool, we need to clone the conversion tool from the repository. Once cloned the project, we must read the Readme file, just to compile the tool. After compiling the tool, we can open the .sln file and build the solution to ensure that every component in the project is ok. The next picture will show us how to build the project:
We just have to click on build solution and then, if everything is working well the visual studio will show us a message like this:
Winform conversion tool has several different migration options, this is the list of the different flags to migrate:
WinForm to NetCore: --TargetFrx NetCore
WinForm to NetFramework 4: --TargetFrx Net4x
WinForm to NetFramework 5: --TargetFrx Net5x
WebForm to WebMap: --InputType WebForms or --TargetFrx WebForms
Note: If we do not put any kind of these flags, the tool will migrate by default (WinForms)
Additionally, we can move on into this path: WFNetConversionTool\Assemblies\Core\Config\CommandLineOptions.cs to see more migration options (this, into the project folder).
We can see the list of the demos (WinForm) that we can do the migration with them, here is the list:
WebForm Testing Demo (WebForm)
Migrating Testing Demo Winforms
Now that we know the basic migration options, we are going to migrate a WinForm project, in this case, Testing Demo Winforms. Once you clone this project, we open the conversion tool and we press right click on CmdRunner, select Properties, then Debug and then we will see a textbox like this:
In that textbox, we need to add the command line arguments, which is the following:
I (means input) Specifies the input WinForms solution to be processed.
O (means output) Indicates the output directory file path.
Therefore, our path would be as follows:
As we can see in figure 4, we don’t add any flag after those arguments, but in case that we need to add it, just type one of the flags that we describe before (We will see an example in figure 8). After that, we can continue with the migration process, we run the CmdRunner with the correct arguments and you will see the result in the output folder.
As we can see in figure 5, the migration tool creates these files in the output folder, but to run the migrated project, we have to complete some additional steps. First, we have to move on the folder called: testingdemo-angular, second, we have to open a cmd in the path that the package.json stay and type yarn, for example:
This will download all packages necessary related to frontend. Without this step, we cannot run the migrated solution. Once the download is complete, we must type in the same console, yarn run build and we need to wait until all packages are download and install it.
In the migrated solution, we will find a file with extension .sln called: TestingDemo. As figure 5 showed us. Double click on that, then we build the solution and finally run the application. This will be the result:
As we can see in figure 7, this is the migrated application using the WinForm Conversion Tool.
Migrating the Webform testing demo
To migrate this application, we need the follow the same steps from the testing demo WinForm. The difference here is the arguments. We have to put the flag after the input and output path, for example:
Migrating the SKS, TKS and Tailwind WinForms projects
In this point, it is almost the same steps. The difference is that those projects have databases, which means we must follow additional steps. We can find this information in the next link: Internal demos
Execute test methods
These projects (SKS, TKS and Tailwind) include data base, if we want to run these demos (not only for test cases purposes, but also for functional purposes) we must add the database.
Therefore, running the SKS, TKS and Tailwind project implies the following additional steps. About SKS with need to move on into this path: WEBMapDemos\WebMAPDemos\src\WFNet\SKS\SKS_Winform\Requirements\netCore (original code) and copy the Orders.db file into the migrated SKS solution.
With Tailwind is the same step, the difference here is the path, which is: WEBMapDemos\WebMAPDemos\src\WFNet\TailwindTradersPointOfSale\WinForms\Requirements\netCore and copy the TailwindPOS.mdb file into the migrated Tailwind solution.
Finally, with TKS there are some requirements first to follow:
SQL Server Management Studio 19.3 (not necessary), visit here for guide.
TKS Database backup located on WebMAPDemos, it can be found here.
Now, there are two ways to restore the database, using the command line or through SSMS.
To restore a backup on the command line for SQL Server, you can use the following steps:
Open a command prompt window.
Navigate to the directory where the SQL Server executable files are located. This is typically "C:\Program Files\Microsoft SQL Server\{SQL Server version}\{Instance name}\Bin".
Run the following command to restore the database backup:
Replace {ServerName} with the name of the SQL Server instance, {Username} and {Password} with your SQL Server login credentials, {DatabaseName} with the name of the database to restore, and {PathToBackupFile} with the full path to the backup file.
Note: Make sure to have SQL Server installed and the necessary permissions to restore the database.
Note: If there are more than one SQL Server instances or servers, replace {ServerName} with the name of the SQL Server and the instance name {ServerName}\{InstanceName}. Those names can be found on the Database engines from the local server.
To restore a backup using SQL Server Management Studio (SSMS), follow these steps:
Open SQL Server Management Studio.
Connect to the SQL Server instance where you want to restore the database.
In the Object Explorer, right-click on "Databases" and select "Restore Database".
In the "Source" section, select "Device" and click on the "..." button to browse for the backup file.
Select the backup file and click "OK" to close the dialog.
In the "Destination" section, specify the name of the database you want to restore to.
Under the "Options" section, you can customize the restore options as needed.
Click "OK" to start the restore process.
Please note that you should have SQL Server Management Studio installed and the necessary permissions to restore the database.
Before compiling and running the app, update the connection string located on file /TKS_DB/DataHandler.cs. Replace {ServerName} with the name of the SQL Server instance:
Note: If there are more than one SQL Server instances or servers, replace {ServerName} with the name of the SQL Server and the instance name {ServerName}\{InstanceName}
After doing that just run your fresh new TKS web app.
This process consist of three main steps in order to move from Access to WebMAP.
The VBA Extractor is required to generate the VB6 code and the controls of Access as a helper file to import to the VB project. To find this resource there are two options:
Download from the repository the solution Mobilize.VBA.ConversionTool.sln.
Take the last artifactory generated from \\buildartifactory\VBUC\Product\Mobilize.VBA.ConversionTool path.
Now, the executable file is vbact.exe, with this the extractor will be open and the next window will show up:
Each of those fields are required to be filled, this fields are for:
Input: the .accdb file.
Output: the output path for the extracted project.
Project Name: name that vb project will have.
New Connection String: connection string to the access db. It can be found here: https://www.connectionstrings.com/access/.
Main Form Name: name of the main form from .accdb database.
Afterwards, the extraction to VB6 can be executed and it will generate the next files:
Here we can see the Demo.vbp that is the main project and the helper MobilizeAccessControls.vbp project. The other files are the forms from the .accdb file and the controls (.ctl) used on those access forms.
Sometimes the extraction process could fail because the Microsoft Access Database Engine x32 is installed. Solution would be to change it to x64.
First, the MobilizeAccessControls.vbp must be compiled and it will generate an .ocx file that must be imported to the .vbp main project.
If any issue shows up when compiling the .vbp project about that Mobilize controls reference is not found, it could be related to the .ocx reference in .vbp project.
The Mobilize.Control reference sometimes generates errors when compiling the VB project, a workaround to apply is to use native VB controls instead of the Mobilize controls from de Access helper .vbp.
Now, check that datasource path is aiming to .accdb file to retrieve the data from Access database, this could be reviewed from the main form:
It is required to have installed VB6 or a virtual machine with VB6 to achieve the compilation.
Subsequently, when the vb6 project is compiling and the .exe file is working, the next step is to migrate the vb6 project to winforms using the Visual Basic Upgrade Companion. It can be found from two options:
Latest release of VBUC: \\services-srv\FDS\CM\Microsoft\UWEE\Latest Release\Mobilize.Net Visual Basic Upgrade Companion - Build 9.5.20110.0
Latest build of VBUC: \\vbuc-build-w8\Builds\Trunk\Git-20230303-0100-20303\msi, take the Setup-en.exe
Now, when the VBUC tool has been executed, the next steps will be required:
Click on new and choose the source path to the folder where the .vbp file is located.
Resolve references.
On Upgrade Options section select csharp vs 2019 and click on Upgrade Projects.
A folder will be generated with the migrated solution (.sln file).
The VBUC team can help with a license to execute this tool.
Now, compile the Winforms project before moving to WebMAP. For this, could be required a virtual machine with winforms installed, also it could be compiled locally but there are paths to be replaced from the virtual machine to the local machine directory.
If Winforms project does not compile, it could be required to install the x32 version of the Microsoft Access Database Engine (2016 optional).
The conversion from Winforms to WebMAP can be performed with the next options:
Conversion tool of WebMAP.
Last bundle generated of WebMAP.
For the usage of the bundle is required a license.
Here is required the webmap.config of Access.
Verify the package.json has the Access components reference (last version of components). There is an issue with this reference that sometimes is generated without the @mobilize (@mobilize/acs-winforms-components).
Verify in the angular.json that on styles block the reference to access components styles contains the @mobilize at the start.
Finally, the WebMAP compilation process. There is a migrated project called Mobilize.AccessControls, if it is not required, it could be removed from Stubs and the project should build. On the other hand, if it’s required the folder would need to be restructure, so the Mobilize.AccessControls must be moved to an internal folder because the bin and obj directories were being shared. An example of the can be found here.
If an issue shows up when compiling that fails trying to connect to the database, it’s possible that Microsoft Access Database Engine x64 should be installed instead of x32 version.
For Silverlight Conversion tool, there are 3 internal demos, Controls demo, PRISM demo and Testing demo. These solutions(Silverlight and Automation) are in WebMAP Demos. In this section, the steps to execute all these solutions will be exposed.
Build the Silverlight solution located in: ...WebMAPDemos\src\SLAngular\SLControlSampler\SLControlSampler.sln and keep it running. This is because the migrated application will consume the service for the Modules.
Please run the Silverlight conversion tool using the following instruction in the CMDRunner:
Note: Please check that the path is correct according to your local files.
For this solution, no manual changes are required. So, the functional tests can be execute. Please open the Automation project located in: ...\WebMAPDemos\test\ui\DemoSLAngular\ControlsAutomation\SilverlightToAngularAutomation.sln. and follow the steps to run functional tests.
Build the Silverlight solution located in: ...\WebMAPDemos\src\SLAngular\PrismFunctionalDemo\PrismFunctionalDemo.sln and keep it running. This is because the migrated application will consume the service for the Modules.
Please run the Silverlight conversion tool using the following instruction in the CMDRunner:
Note: Please check that the path is correct according to your local files.
Some manual changes need to be made, the first one is change the script "fullbuild" in the package.json, and add the following instruction:
Now, open the angular project files in VisualStudio Code. Open a new terminal and write the following commands:
Once the code is compiled, go to the generated Shell.ts file, in the line number 33 change it to the following line:
Note: Also do the client change in the generated Boostraper.ts file in the line number 15.
Now the application is ready. Please open the Automation project located in: ...\WebMAPDemos\test\ui\DemoSLAngular\PrismFunctionalAutomation\PrismFunctionalAutomation.sln. Now, the tests are ready to be execute, please follow the steps to run functional tests.
Build the Silverlight solution located in: ...WebMAPDemos\src\SLAngular\SilverlightTestingDemo\SilverlightTestingDemo.sln and keep it running. This is because the migrated application will consume the service for the Modules.
Please run the Silverlight conversion tool using the following instruction in the CMDRunner:
Note: Please check that the path is correct according to your local files.
For this solution, no manual changes are required. So, the functional tests can be execute. Please open the Automation project located in: ...\WebMAPDemos\test\ui\DemoSLAngular\SilverlightTestingDemoAutomation\SilverlightTestingDemoAutomation.sln. and follow the steps to run functional tests.
First, we need to meet some requirements to run the frontend test projects:
Install Node.js.
Install Angular CLI.
Install Yarn or use NPM.
In addition, there is a step require on each of the frontend repositories, for both components project (Unit Test) and Samples/E2E project (E2E Test). It is to install the node modules (dependencies) necessary to execute the projects. It is achievable through yarn install or npm install cli command. It is needed to be inside package.json location directory and execute:
In order to run the unit test, we need to mention the different test runners that are being used on the Frontend components projects:
Karma – Jasmine, where Karma is the test runner and Jasmine the BDD style testing framework, Jasmine has been used to create the test cases. Here we can find the Karma documentation and the Jasmine documentation.
Jest, it is a JavaScript testing framework with a test runner and an assertion module for Node.js. Here we can take a look on Jest documentation.
And then, we have the repositories of Frontend, these projects are structure with the components project and the samples or end-to-end project. For the unit test we will focus on components project. Inside the components project, at the src folder, we can find some other folders named test, within these folders we can find spec files that contain the test suites.
How to run the unit test for Angular Client:
This repository is using Karma – Jasmine as a test runner, so through the karma.conf.js the configuration of the test runner can be modified. Here we have the steps to run the unit test:
First, move to src\WebMap.Client.Angular directory.
Then, execute yarn install to install all the dependencies needed for the Angular Client.
When the installation is finished, use yarn run test command to start running the unit test.
How to run the unit test for the Base Components:
First, on the root of the Base Components directory can be found the package.json file, so move to the root of Base Components.
Next, install the dependencies needed for the Base Components using the yarn install command.
Now, when the dependencies are installed, the unit test can be executed using yarn run test command.
Note: The Base Components is using Karma as a test runner and Jasmine to write the test.
How to run the unit test for the Client Core:
First, locate in packages\core directory.
Then, execute yarn install command to install the dependencies for the Client Core.
Later, when the installation is complete, execute yarn run test command to start running the unit test for the Client Core.
Additionally, on the Client Core there is only unit test using Karma as the test runner, and it can be found on packages\core\test directory, it has the corresponding spec files containing the different test suites for the src code. Also, in the same directory where the package.json is located, the karma.conf.js file can be found there.
How to run the unit test for the PB Kendo Components:
Initially, move to Components folder, that’s the location where the package.json file is placed.
When inside of Components folder, execute yarn install command to install the dependencies for PB Kendo Components.
Now, after the installation of the dependencies, the unit test can be executed using yarn run test command.
As mentioned before, to run the unit test is being used Karma – Jasmine, the karma.conf.js can be found inside Components folder, there can be modified the test runner options to run the unit test.
How to run the unit test for the WFNet Kendo Components:
First, locate in WinformsComponent folder because in here is the package.json file.
Then, install the dependencies necessary for the components project, this can be achieved through yarn install command.
Next, when dependencies installation is finished, the unit test can be ran using the yarn run test.
Last, when the unit test has reached the end, a coverage folder will have the results of the test.
Note: In WFNet Kendo components, the test runner is Karma – Jasmine, the configuration file can be found inside WinformsComponents folder.
How to run the unit test for the WFNet Janus Components:
First, position inside of frontend\JanusComponents\projects\janus directory, this to be at same location of package.json.
Execute the yarn install command to install the dependencies for the project.
When installing is finished, execute yarn run test to begin the unit testing process.
After the unit test, an Istanbul report will be on coverage folder with the information of the coverage per components file.
Note: For WFNet Janus components, Karma is being used as the test runner and the configuration file for Karma is in the same folder where is the package.json file.
How to run the unit test for the WFNet Access Components:
Initially, move to frontend\AcsComponents\projects\acs directory because here is the package.json file.
Then, execute yarn install to add the node modules needed to run the Access Components.
Now, when the installation of the dependencies is finished, execute the yarn run test to start running the unit test.
After that, when the unit test has ended, a new folder will be generated with the Coverage information, this folder can be found as coverage folder.
Note: In this repository, Karma - Jasmine is being used as the test runner for the unit test.
How to run the unit test for WFNet C1 Components:
First, move to frontend\projects\WFNetC1Components.
Next, execute the yarn install command to install the dependencies needed for C1 Components.
Then, the dependencies should be installed, so the unit test can be run using the yarn run test command.
After that, when the unit test has ended, a new folder will be generated with the coverage information, this folder can be found as coverage folder.
Note: For C1 Components, the test runner being used is Karma – Jasmine.
For Silverlight Components, there are two projects that has unit test, these are the (Infragistics) i-components and the wms-framework. The steps to run the unit test for them will be expose here:
Silverlight i-Components
How to run the unit test for Silverlight i-Components:
First, locate to WebMapSilverlightComponents\projects\i-components directory.
Then, execute yarn install to install the dependencies for i-components.
Afterwards, move to WebMapSilverlightComponents\projects\wms-framework directory.
Then, execute yarn install for the dependencies of wms-framework.
After that, move to WebMapSilverlightComponents directory.
Then, execute yarn install to install the dependencies for WebMapSilverlightComponents.
Now, when the installation of the dependencies has been completed, execute the build for wms-framework through yarn run f-buildTFS.
Next, execute yarn run i-update to move what was built from last command to the node_modules of i-components.
Now, it is ready, the unit test can be executed using yarn run i-testTFS.
Last, when the test has stopped running, a new folder will be created with the name coverage, there will be the data about code coverage for the i-components.
Note: For Silverlight i-Components, Jest is being used as the test runner.
Silverlight wms-framework:
How to run the unit test for Silverlight wms-framework:
First, move to WebMapSilverlightComponents\projects\wms-framework directory.
Then, execute yarn install for the dependencies of wms-framework.
After that, move to WebMapSilverlightComponents directory.
Then, execute yarn install to install the dependencies for WebMapSilverlightComponents.
Now, when the installation of the dependencies has been completed, the unit test can be executed using yarn run f-testTFS.
Last, when the test has stopped running, a new folder will be created with the name coverage, there will be the data about code coverage for the wms-framework.
Note: For wms-framework, Jest is being used as the test runner.
How to run the unit test for Webforms Components:
First, move to frontend\projects\WebFormsComponents directory (package.json location).
Then, execute yarn install to install the dependencies for WebFormsComponents.
Now, when the installation has finished, the unit test can be executed through yarn run test command.
Note: In this repository, Karma – Jasmine is being used as the test runner.
On the other hand, the frontend repositories has the end-to-end (e2e) test. The testing framework being used to do this test is Cypress. Here can be found the documentation of Cypress. There are two main commands in the frontend repositories scripts to run Cypress test:
Headless (Better for CI)
Cypress Dashboard
In addition, here will be expose the repositories with end-to-end test in frontend:
How to run the end-to-end test for PB Kendo Components:
First, move to PBKendoComponents\Components directory.
Then, execute yarn install for the dependencies of PB Kendo Components.
Next, execute the yarn run build for the Components.
After that, move to dist directory inside Components folder.
Then, run the yarn pack command to create a package tgz file, necessary for E2E Samples project.
Afterwards, move to PBKendoComponents\Samples directory, in the dependencies package.json section modify the path on @mobilize/powercomponents with the path of the tgz file and execute yarn install to install the packages for the E2E project.
Last, when the installation of the dependencies has been completed, the e2e test can be executed using yarn run cy:test.
How to run the end-to-end test for WFNet Kendo Components:
First, move to WFNetKendoComponents\Samples\Samples directory.
Then, execute yarn install, this will install the packages needed to run E2E project.
After that, use yarn run cy:test to start running the e2e test.
How to run the end-to-end test for WFNet Janus Components:
First, position inside of frontend\JanusComponents\projects\janus directory.
Execute the yarn install command to install the dependencies for the project.
Then, execute yarn run build command in the same directory.
After that, move to dist directory inside Janus Components folder.
Then, run the yarn pack command to create a package tgz file, necessary for E2E Samples project.
Afterwards, move to frontend\samples directory, in the dependencies package.json section modify the path on @mobilize/jns-winforms-components with the path of the tgz file and execute yarn install to install the packages for the E2E project.
Last, when the installation of the dependencies has been completed, the e2e test can be executed using yarn run cy:test.
How to run the end-to-end test for WFNet C1 Components:
First, position inside of frontend\projects\Samples directory.
Afterwards, in the dependencies package.json section, modify the path on @mobilize/wfnet-c1-components dependency with the current version of the C1 Components.
Execute the yarn install command to install the dependencies for the project.
Last, when the installation of the dependencies has been completed, the e2e test can be executed using yarn run cy:test.
How to run the end-to-end test for Silverlight Components:
First, move to e2eProject folder.
Then, execute yarn install to add the node modules necessary to run the e2e project.
Next, locate to WebMapSilverlightComponents\projects\i-components directory.
Then, execute yarn install to install the dependencies for i-components.
Afterwards, move to WebMapSilverlightComponents\projects\wms-framework directory.
Then, execute yarn install for the dependencies of wms-framework.
After that, move to WebMapSilverlightComponents directory.
Then, execute yarn install to install the dependencies for WebMapSilverlightComponents.
Now, when the installation of the dependencies has been completed, execute the build for wms-framework through yarn run f-buildTFS.
Next, execute yarn run i-update to move what was built from last command to the node_modules of i-components.
Therefore, execute the build for the i-components using yarn run i-buildTFS.
Afterwards, using yarn run e2e-update command to update in the node modules of the e2e project the i-components and the wms-framework.
Then, move to the e2eProject folder and execute yarn run cy:test to start running the test cases.
How to run the end-to-end test for WebForms Components:
Initially, move to frontend\projects\e2eProject.
Next, execute yarn install to install the necessary dependencies to run WebForms e2e test.
Lastly, execute yarn run cy:test to start running the e2e test.
