[MStn CE U12 SDK] ConstraintCommonNet.dll referenced incorrectly in examples

Jan Šlegr said:

When buildexamples batch is used and buildallexamples-Output.txt is analyzed, there are 105 instances of "error" word in the log. The most of them belong to the reported issue

I didn't get that result.  I have two errors when invoking BuildAllExamples.bat for MicroStation CONNECT Update 12:

### Error: Duplicate: File=(D:\temp\Bentley\MicroStationSDK\rscobj\sclrottc.rsc), 
LINK : fatal error LNK1201: error writing to program database 'G:\PROGRA~1\Bentley\MICROS~2\MICROS~1\mdlapps\applcelm.pdb'; check for insufficient disk space, invalid path, or insufficient privilege

As you can read, one error is a duplicate resource found by rcomp or rlib, and the other when Viz Studio tried and failed to write a project database file.  I don't know why that failed, because subsequent projects built OK.

Hi Jon,

thanks for checking this and your feedback.

It's weird why we obtain different results.

To find what is the difference, may I ask you?

• How did you install the update? I did clean install (remove both SDK and MStn, remove all leftovers in ProgramFiles, ProgramData and AppData, and ran both installations.
• Can you check where the discussed ConstraintCommonNet.dll assembly is located? My is in Assemblies folder.
• Can you check how the reference is defined (e.g. in ParametricModelingExample.csproj? My is as $(MS)MdlSys/AsNeeded/ConstraintCommonNet.dll, which is not correct in my opinion.

With regards,

  Jan

Jan Šlegr said:

How did you install the update?

Uninstall the existing SDK, then install the SDK for Update 12

I didn't uninstall/reinstall MicroStation.  I didn't do the housekeeping that you scrupulously performed.

Jan Šlegr said:

ConstraintCommonNet.dll

G:\Program Files\Bentley\MicroStation CONNECT Edition\MicroStation\Assemblies File version: 10.12.0.40
G:\Program Files\Bentley\MicroStation CONNECT Edition\MicroStation\Mdlapps  File version: 10.12.0.40

It looks like the installer creates a duplicate?

Jan Šlegr said:

Can you check how the reference is defined

 
<Reference Include="ConstraintCommonNet">
  <HintPath>$(MS)MdlSys/AsNeeded/ConstraintCommonNet.dll</HintPath>
  <private>False</private>
</Reference>

Jon Summers said:

I didn't do the housekeeping that you scrupulously performed.

Maybe this situation is one from reasons why I my approach is "do it from scratch" ;-)

Jon Summers said:

It looks like the installer creates a duplicate?

I do not think the copy in MdlApps is created by the installer.

Some NET examples delivered in SDK are configured wrongly (not sure what and how many), because when project is compiled, referenced assemblies are copied to output folder also. I assume ConstraintCommonNet was copied to MdlApps folder in some previous version and was not cleaned up when MicroStation installation was upgraded.

My assumption is that when the assembly will be removed from MdlApps, the examples will be not compiled.

With regards,

  Jan

Jan Šlegr said:

I do not think the copy in MdlApps is created by the installer.

Both files I mention above have the same date-stamp 21/02/2019 11:24.  I installed Update 11 at the end of 2018, so anything newer must have been installed by Update 12.

I haven't been doing any .NET constraint programming, so have not used that DLL.

Perhaps MicroStation installed one and the SDK installed the other?

Hmmm ... a bit weird. But anyway, the reference path used in VS projects is incorrect and should be fixed.

Thanks for your effort,

  Jan

Jan Šlegr said:

ConstraintCommonNet.dll assembly is referenced using wrong path:

• it is: $(MS)MdlSys/AsNeeded/ConstraintCommonNet.dll
• should be (I think, but have not tested it): $(MS)Assemblies/ConstraintCommonNet.dll

Hi Jan,

It appears that someone had moved (and - for me - also duplicated) this file in a clean environment.

The example code had (2) hint locations and the correct single location can/should be the ..\Assemblies directory.  I will file two defects to correct the duplication and clean up the example project to the correct location.

Thank you for reporting this,
Bob

Jon Summers said:

one error is a duplicate resource found by rcomp or rlib, and the other when Viz Studio tried and failed to write a project database file.  I don't know why that failed, because subsequent projects built OK.

Hi Jon Summers,

The duplicate resource (subtle) issue has been present for quite awhile and on my back-burner radar todo list, though is in need of an official defect to be filed. I will file a defect and update you here with it.

The second issue trying to write to the .pdb on your G: drive though while the error message may be helpful (possibly a drive space or access issue) I suspect might be due to Microsoft's more strict process isolation levels. e.g. If you map a drive in Windows Explorer (non-elevated standard user context) the drive mapping appears fine in a CMD.exe (standard user context) though NOT mapped in an Elevated CMD.exe shell.  If fact, this is one reason I use the SDK postproc bat to leave myself a breadcrumb for when I need to map my external source and symbol server paths as my "e:" drive, like:

[Wed 03/13/2019 15:50:08.46: MicroStationDeveloperShell.bat calling: D:\Data\Dev\bin\mscesdk1000_postproc.bat, result: 0]
net use e: \\sourceserver.bentley.com\PRGProductBuilds

The isolation issues have been present for some time and though this is a post from 2013, I believe it hits on the primary points to illustrate and understand this specific case: Elevated command line prompt can't access shared drives.  The other slightly related possibility is that Microsoft often (for performance and/or power reasons) allows mapped drives to disconnect then "wake" when accessed - via user (e.g. Explorer) or Elevated user access (admin command prompt).

HTH,
Bob

Robert Hook said:

Elevated command line prompt can't access shared drives

Not the case here: my G: drive is a local disk.  Keep in mind that the error I reported above is the only PDB that fails.

ORD says that "ConstraintCommonNet.dll" is missing and its dependencies. I have installed it again with the same result.

OpenRoads Designer Connect Edition 2020 Release 3 Update 9 v10.09.00.91

Windows 10 Home.