msbatch batchconvert from command line does not work in Connect Edition

Hi all,

I have a simple DGN file with a reference file attached (another simple DGN file)

I want to use the Batch Convert utility to merge the reference with the Master file.

Everything works fine inside Microstation Connect (Update 16) with the Batch Convert dialog, but it's NOT working outside using the msbatch batchconvert syntax from commandline.

No output file is created. I use the same .bcnv file I created in Batch Convert Dialog.

Syntax: C:\Program Files\Bentley\MicroStation CONNECT Edition\MicroStation>msbatch batchconvert C:\Temp\SampleCE.bcnv

In Microstation V8i everything works fine in both modes.

Inside the attachment zip file you will find the DGN files, bcnv and bat files for CE , bcnv and bat files for V8i.

You can put everything in C:\Temp and Test (create the C:\Temp\Out folder for output file)

The batchprocess.log says that the process is not terminated...

Can you help me please? I need msbatch for an application that use Microstation without user interaction.

3465.Temp.zip 

Processing Batch Convert Job: C:\Temp\SampleCE.bcnv
Start Time 22/12/2021 17:00:25
---- Convert File: from C:\Temp\Sample.dgn in V8 format to C:\Temp\Out\Sample.dgn in V8 format ----






Parents
  • Hi,

    This issue has been fixed in U16.1 build. 

    Regards,

    Pravin Sawant

    Answer Verified By: IronMonkey 

  • Pravin,

    Just got the 10.16.02.034 build, it gets a bit further but fails with the following when you do "MSBatch BatchConvert"

    Ideas?

  • Pravin, Hopefully you can find the problem code in MS CE and respond soon with a fix.

  • Hi John,

    I have filed the bug for Log4 net error. please find below bug number.

    BUG 812993 Batch convert error log4net.

    If possible can you please share your data set and bcnv file?

    Regards,

    Pravin Sawant

  • Pravin,

    Did some more testing, Log4Net flaw is still there, but can be worked around...

    Commands in MSBatch are DIFFERENT between Different MS versions :

    • MSV8i - runwait ustation.exe -wa%1 -i%2 -i%3 -i%4 -i%5 -i%6 -i%7 -i%8 -i%9
    • MS CE - start /wait MicroStation.exe -wa%1 -i%2 -i%3 -i%4 -i%5 -i%6 -i%7 -i%8 -i%9

    When:

    • Parameter %1 is BatchConvert
    • Parameter %2 is "Path-to-BCNV\Stuff.bcnv"
    • All previous tests were done where the BCNV Parameter has Quotes surrounding the Parameter, just as was allowed with MSV8i previously.

    Results:

    • MSV8i
      • DOES TOLERATE QUOTES around Parameter 2, the BCNV File can be as "Path-to-BCNV\Stuff.bcnv" or without quotes if it is not a "Long" Path\Filename" containing Spaces
    • MS CE
      • DOES NOT TOLERATE QUOTES around Parameter 2, the BCNV File must be as Path-to-BCNV\Stuff.bcnv
      • A Properly Configured Command Line will not be "sent to/received by" BatchConvert if it has Quotes around the BCNV Parameter
        • With no Quotes, the Log4Net Error will display at the start, and then the BatchConvert will start.
        • Add the Quotes, the Log4Net Error will display at the start, and then the MSBatch will fail back to DOS.
      • So... Long Paths with "Spaces" then cannot be used.

    For our current needs, we can work around not being able to use quotes.

    Quotes would of course be required where Long Paths are required.

    Please see if this can be addressed.

  • Hi. Very strange :-) Anyway, in my case I can use quotes or not and the result is the same as I described in my previous post.

    It works but with log4net message.

    For long paths you can use 8.3 notation (the same of the command dir /X).

    You can create a shortname.bat file with this instruction inside:

    echo %~s1

    You can call this batch with a long path with spaces as parameter:

    Example: shortname "C:\Program Files (x86)\Bentley\MicroStation V8i (SELECTseries)\MicroStation"

    It returns: C:\PROGRA~2\Bentley\MICROS~1\MICROS~1

    And you can use this in your BCNV

    Just an idea.

    Bye

  • Thanks!

    I had considered adding other parameters, or modifying as you suggest, but I then decided that this needed to be addressed by Bentley as "inconsistent"... I prefer the paths to be spelled out...

    So far, I have seen exactly the same on three separate machines... it is "consistently" different/broken.

    Not discounting that it could be some change in MS that is perceived different by our Anti-Virus or other similar tools and is affected from there, but still, if it does not work for me, it would not for others in our company.

    • Even so, I still suspect that "MicroStation.exe" is just not parsing the Quotes properly

    Arguably Bentley should:

    • account for this in the MS Documentation, at a minimum...
    • and/or change the BAT File or MicroStation.exe Parameter Parsing to account for the change when using "Start /wait" vs old "Runwait.exe"
    • and/or recreate the MSBatch.bat using the %~f1 syntax
    • or just declare that MSBatch.bat is now a "example only", and should not be used directly anymore...

    For now, until I hear-different-where-it-is-made-to-work, I will mark this as "not tested enough before release", possibly "because not many people use this feature anymore" (unfortunate). 

    Good thing is, now I know this, I can make it work.

Reply
  • Thanks!

    I had considered adding other parameters, or modifying as you suggest, but I then decided that this needed to be addressed by Bentley as "inconsistent"... I prefer the paths to be spelled out...

    So far, I have seen exactly the same on three separate machines... it is "consistently" different/broken.

    Not discounting that it could be some change in MS that is perceived different by our Anti-Virus or other similar tools and is affected from there, but still, if it does not work for me, it would not for others in our company.

    • Even so, I still suspect that "MicroStation.exe" is just not parsing the Quotes properly

    Arguably Bentley should:

    • account for this in the MS Documentation, at a minimum...
    • and/or change the BAT File or MicroStation.exe Parameter Parsing to account for the change when using "Start /wait" vs old "Runwait.exe"
    • and/or recreate the MSBatch.bat using the %~f1 syntax
    • or just declare that MSBatch.bat is now a "example only", and should not be used directly anymore...

    For now, until I hear-different-where-it-is-made-to-work, I will mark this as "not tested enough before release", possibly "because not many people use this feature anymore" (unfortunate). 

    Good thing is, now I know this, I can make it work.

Children
No Data