Highlighted
Super Contributor.
Super Contributor.
2405 views

Using Net Express project import wizard for Visual COBOL 2.1 questions

Jump to solution

After the import, the imported project directives are listed in the Additional Directives box on the project properties screen.  We would also like to add USE"..\MYDIRECTIVES.DIR"  to the list of additional directives.  Our Net Express projects don't always have the same directives but there are certain directives we've had to add to our Visual COBOL projects so they will build without errors (for example, REMOVE"OBJECT-REFERENCE") and we list these in MYDIRECTIVES.DIR.  Can we do this or will the compiler only use the directives in MYDIRECTIVES.DIR ?

We are bringing about 350 projects from NX 5.1 to Visual COBOL and we want to maintain two sets or source, the original, unmodified NX source and the Visual COBOL source which we will modify.  In the import wizard, we specified a different directory (from the NX directory) for the Visual COBOL project but the source was not copied to it.  Also, each time we use the wizard it creates a solution along with the imported project but we want to import multiple projects into a single solution.  Our solution to this is to copy our entire Net Express project to a temporary directory and then import the NX project from it.  We then copy, in Windows Explorer, the project's folders and files to our application's solution folder and select Add ... Existing Project in Solution Explorer and add the copied project.  This doesn't take long but let us know if there is a quicker way to do it.

Phil Levin

Tags (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Using Net Express project import wizard for Visual COBOL 2.1 questions

Jump to solution

The original idea was that this _Shared project was there to contain files, directives etc that are shared between the projects in a solution, which may well be the case in future and was the reason for the name that was choosen.

The reason that it exists even when there are no files in it is because of how the Visual Studio project upgrade mechanism that we are now using in 2.1 returns the name of the project to be opened.

It was necessary to create this extra project in order for the real project to be set as the Startup project.

As you point out, it is currently unnecessary and can be removed from the build.

View solution in original post

0 Likes
5 Replies
Highlighted
Super Contributor.
Super Contributor.

RE: Using Net Express project import wizard for Visual COBOL 2.1 questions

Jump to solution

We could also create a project directory under our application solution, copy the NX project to it, import the project, remove the solution file and other unwanted files and folders from the project directory, then add the project to our solution.  This would be a little faster.

Phil Levin

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Using Net Express project import wizard for Visual COBOL 2.1 questions

Jump to solution

We could also copy our entire Net Express 5.1 source to a new directory and then import Net Express projects from within that directory.  All source, solution files and project files would reside in a single directory just like the Net Express version of our application.  The wizard creates both a solution file and a project file.  The solution with the single project would come in handy because when we run the application from it, it will load quickly.  But a project can be included in more than one solution, so we could set up an Accounts Payable solution, for example, with all of the A/P projects in it.  When we start creating managed COBOL projects, we could put these in their own directory.  Using this approach plus outputting INT/GNT files would make the Visual Studio version of our native COBOL system virtually identical to the Net Express system.  Does this seem like a good approach ?

Phil Levin

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Using Net Express project import wizard for Visual COBOL 2.1 questions

Jump to solution

Net Express projects are more closely related to Visual COBOL Solutions than Visual COBOL Projects.

Net Express projects can contain a number of different types of application output files in the project build window, like .EXEs, .DLLs, .INTs/.GNTs, etc.

In Visual COBOL, a solution can contain multiple projects, each of which can contain a single output type, although multiple output files of the same type can be generated per project.

When Net Express projects are imported into Visual COBOL you have the choice of what type of output file you would like the imported project to generate.

The directives found in the Net Express project will be added to the Visual COBOL project properties.
You can then modify these directives in the COBOL properties page by adding to them, or removing from them.
You can add a USE"filename" directive and the directives in the file specified will be cumulative with the directives that are already set in the project properties.

When importing Net Express projects, the source files are not moved and the Visual COBOL solution and project files will be placed in the Net Express project folder. This means that you should create a copy of these NX projects first to use in the import if you still wish to maintain them under Net Express.

If you wish to have more control over how these projects are created, you may wish to bypass using the Net Express Project Import Wizard and just use the Create Project from Existing Code Wizard instead.

If you will be adding a USE"filename" directive to your projects then you could add all neccessary directives in this file.

The one item that you need to look out for is that if you are calling programs between projects then the programs being called must be locatable by the calling program.

You can do this using a couple of methods.

1.  Make the target output folders the same for all projects so that the calling and called programs will be in the same folder.
2.  Add an application.config file to the project of your main program which sets the PATH environment variable to include the location of the programs to be called.   If calling .DLLs, use PATH, if calling .INTs/GNTs use COBPATH.

There is really no right or wrong way to do this, (as long as it works), it really depends on what you feel comfortable with going forward.

New Visual COBOL projects are created with a separation from each other so that each project has its own folder that contains the source that will be compiled into an output location.

I personally believe that this makes it easier to maintain rather than having all sources in the same folder and then creating several projects from this single repository of source code.

One difference between Net Express projects and Visual COBOL projects is the default current directory that is used when debugging or running a program in the IDE.

Under Net Express the default folder is the Net Express project folder so this is where it will look for files that are not qualified with a full path name, i.e. Dialog System screensets.

In Visual COBOL the default folder is the output folder and not the project folder so it will look for Dialog System Screensets and unqualified files in the ..\bin\debug folder, for example.

This working directory can be changed in Visual COBOL on the project-->properties-->Debug tab.

Thanks.

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Using Net Express project import wizard for Visual COBOL 2.1 questions

Jump to solution

The Net Express project import wizard creates an additional "Shared" project.  For example, I imported the MF41 project and the wizard created two projects:  MF41 and "MF41 Shared".  What is the second project for ?  I can delete it from the solution and still get a clean build.

Phil Levin

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Using Net Express project import wizard for Visual COBOL 2.1 questions

Jump to solution

The original idea was that this _Shared project was there to contain files, directives etc that are shared between the projects in a solution, which may well be the case in future and was the reason for the name that was choosen.

The reason that it exists even when there are no files in it is because of how the Visual Studio project upgrade mechanism that we are now using in 2.1 returns the name of the project to be opened.

It was necessary to create this extra project in order for the real project to be set as the Startup project.

As you point out, it is currently unnecessary and can be removed from the build.

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.