Skip to main content

.Net 101

  • April 18, 2011
  • 5 replies
  • 0 views
D

[Migrated content. Thread originally posted on 18 April 2011]

No doubt a very simple question for all you guys out there, but this is a first for me.
We have a .Net app which needs to trigger a .acu program. There is no data to be passed between the apps. The .net app merely has to cause the .acu program to run.
Documentation seems to suggest that I use either -netexe or -netdll compiler options, if true, which would he preferable? It is worth mentioning that the .acu program calls another .acu program, so presumably both .acu programs would have to be compiled with the same options?
Anything else I need to provide for the .net guys?
Dumb questions for those who know, but advice would be appreciated

    5 replies

    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • April 18, 2011

    [Migrated content. Thread originally posted on 18 April 2011]

    No doubt a very simple question for all you guys out there, but this is a first for me.
    We have a .Net app which needs to trigger a .acu program. There is no data to be passed between the apps. The .net app merely has to cause the .acu program to run.
    Documentation seems to suggest that I use either -netexe or -netdll compiler options, if true, which would he preferable? It is worth mentioning that the .acu program calls another .acu program, so presumably both .acu programs would have to be compiled with the same options?
    Anything else I need to provide for the .net guys?
    Dumb questions for those who know, but advice would be appreciated
    Hi,

    Either -netexe or -netdll compiler options work, no preference.
    It is worth mentioning that the .acu program calls another .acu program, so presumably both .acu programs would have to be compiled with the same options?
    No, just the initial program that .Net is calling, the other Acu programs can be compiled normally - it would probably be helpful to make a COBOL library - cblutil -lib and furnish this library to the .Net guys - where the first program in the library is the one compiled with --netexe or --netdll
    D

    [Migrated content. Thread originally posted on 18 April 2011]

    No doubt a very simple question for all you guys out there, but this is a first for me.
    We have a .Net app which needs to trigger a .acu program. There is no data to be passed between the apps. The .net app merely has to cause the .acu program to run.
    Documentation seems to suggest that I use either -netexe or -netdll compiler options, if true, which would he preferable? It is worth mentioning that the .acu program calls another .acu program, so presumably both .acu programs would have to be compiled with the same options?
    Anything else I need to provide for the .net guys?
    Dumb questions for those who know, but advice would be appreciated
    Many thanks, will do.
    D

    [Migrated content. Thread originally posted on 18 April 2011]

    No doubt a very simple question for all you guys out there, but this is a first for me.
    We have a .Net app which needs to trigger a .acu program. There is no data to be passed between the apps. The .net app merely has to cause the .acu program to run.
    Documentation seems to suggest that I use either -netexe or -netdll compiler options, if true, which would he preferable? It is worth mentioning that the .acu program calls another .acu program, so presumably both .acu programs would have to be compiled with the same options?
    Anything else I need to provide for the .net guys?
    Dumb questions for those who know, but advice would be appreciated
    Many thanks, will do.
    D

    [Migrated content. Thread originally posted on 18 April 2011]

    No doubt a very simple question for all you guys out there, but this is a first for me.
    We have a .Net app which needs to trigger a .acu program. There is no data to be passed between the apps. The .net app merely has to cause the .acu program to run.
    Documentation seems to suggest that I use either -netexe or -netdll compiler options, if true, which would he preferable? It is worth mentioning that the .acu program calls another .acu program, so presumably both .acu programs would have to be compiled with the same options?
    Anything else I need to provide for the .net guys?
    Dumb questions for those who know, but advice would be appreciated
    If you don't need to communicate back and forth from the COBOL program to .Net, then I would just compile the COBOL program normally, and invoke it from .Net.

    In VB, you use:
    Shell("app.exe")

    In C#:
    Process.Start("app.exe");

    So, for the AcuCobol runtime, you would use something like:
    Process.Start("\\\\Path_to_runtime\\bin\\wrun32.exe -C \\\\Path_to_config_file\\config.cfg \\\\Path_to_program\\main.acu");

    Hope that gives you some ideas,

    Paul
    D

    [Migrated content. Thread originally posted on 18 April 2011]

    No doubt a very simple question for all you guys out there, but this is a first for me.
    We have a .Net app which needs to trigger a .acu program. There is no data to be passed between the apps. The .net app merely has to cause the .acu program to run.
    Documentation seems to suggest that I use either -netexe or -netdll compiler options, if true, which would he preferable? It is worth mentioning that the .acu program calls another .acu program, so presumably both .acu programs would have to be compiled with the same options?
    Anything else I need to provide for the .net guys?
    Dumb questions for those who know, but advice would be appreciated
    If you don't need to communicate back and forth from the COBOL program to .Net, then I would just compile the COBOL program normally, and invoke it from .Net.

    In VB, you use:
    Shell("app.exe")

    In C#:
    Process.Start("app.exe");

    So, for the AcuCobol runtime, you would use something like:
    Process.Start("\\\\Path_to_runtime\\bin\\wrun32.exe -C \\\\Path_to_config_file\\config.cfg \\\\Path_to_program\\main.acu");

    Hope that gives you some ideas,

    Paul

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement