I can open the MicroStation CONNECT Update 11 SDK command window and invoke BuildAllExamples.bat successfully.
If I change to folder \Annotatation\ManagedItemTypesExample and execute openSln.bat in the same SDK command window then Viz Studio opens and loads that project.
However, when I build that project in Viz Studio the build fails. Viz Studio complains that it can't create temporary files in
If I create those folders (obj, Debug) manually then Viz Studio builds successfully.
I do not see such problem with the example(s), maybe because I modified SDK folders priviledges to don't require admin access.
Maybe you started Visual Studio with as a normal users, so it was not possible to created the folder because of restricted access rights?
But there are more problems with delivered examples, not only with this one:
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Jan Šlegr said:Maybe you started Visual Studio with as a normal users, so it was not possible to created the folder because of restricted access rights?
I started Viz Studio using openSln.bat from the SDK shell. Presumably the Viz Studio process inherits the Windows environment of that shell: I guess that's the raison d'être of openSln.bat.
I raise this issue not because it gives me a problem — I don't normally use the SDK shell — but to give a hint to the BDN team that there remain hiccups in the delivered tools. Beginners will find such build errors difficult to understand and fix.
Regards, Jon Summers LA Solutions
To access SDK folders you need admin access. Open MicroStation CONNECT Edition SDK command window in admin mode. You need to have VS2013 installed.
Shweta Tadge said:You need to have VS2013 installed.
And it's nonsense, because for native code development, Visual Studio 2015 (latest update) is required and for NET in general, any Visual Studio, supporting required NET Framework can be used (or Visual Studio Code). So naturally, VS2015 should be used. Moreover, in Update 11, NET Framework 4.6.2 is required as target platform, but it did not exist in VS2013 and has to be added explicitely.
Shweta Tadge said:To access SDK folders you need admin access
You haven't read my question thoroughly. I can access the SDK folders. I am using the SDK shell.
Using BuildAllExamples.bat succeeds in the SDK shell. If I open a particular project from that same shell, using the openSln.bat for that project, then Viz Studio fails to build the project. I don't think that I can express the problem any more clearly.
Shweta Tadge said:You need to have VS2013 installed
Really? I am as astonished as Jan!
Shweta Tadge said:Open MicroStation CONNECT Edition SDK command window in admin mode
Users in our company DO NOT have admin access, intentionally, to help prevent security problems and to prevent users from altering the approved desktop configuration. We *can* open the access to that folder specifically, on an "as needed" basis.
Bruce Reeves SRNS said:Users in our company DO NOT have admin access,
The solution would be to install SDK into another than C:\Program Files\ folder, because this location is not mandatory.
Or when it's preinstalled and cannot be changed, to copy Examples from the original folder into e.g. Documents, where full access is ensured.
The MicroStation Developer Shell at this time is documented to be run using local Administrator privileges (GOOD: Elevated User == White Text + Black Background, Standard User: BAD == Yellow Text + Black Background. In short, a Yellow shell is bad. The Developer shell also provides a dynamic title bar (each start) that reflects if running as a Standard or Elevated user. The primary reason is that MDL applications (.ma) are often required to be built in a Program Files output location (mdlapps) folder.
BuildAllExamples simply will execute bmake +a on all .mke child projects. The make file inherits the developer shell environment and calls - Visual Studio tools that also inherit the environment and admin privileges of the parent shell. The pattern I use/recommend is:
Per everyone's input on this thread (thank you), I will add an action item to review all delivered examples Microsoft solutions and files. I do know we need to update the default minimum Microsoft .NET Runtime version, and ensure the solutions use a standardized build output (temp) location too.
Build output locations are certainly one (1) reason Admin privileges are required at this time. As we move forward with releases I will start to see what I can do towards eliminating Microsoft 8DOT3 naming conventions and any build complications/issues that prevent an SDK install from running under LUA mode. I should be able to provide even more focus on SDK priorities into 2019 (and hopefully beyond!). :)
As always, thank you (and you all) for any suggestions to improve the SDK, materials and contents. Much more to come, hopefully in quicker order soon.
it seems a broader discussion how SDK should be structured is required, but probably as separate threads. To summarize what crossed my mind when I read the whole discussion at once (without explicitely quotes):
In my opinion when dev shell functionality will be moved back to its origin (to configure everything properly, to allow run bmake, start Visual Studio etc.), it will be clear we do not need any admin priviledges.
And in a next step, example should be changed to don't expect the shell will provide any extra priviledges.
Robert Hook said:The primary reason is that MDL applications (.ma) are often required to be built in a Program Files output location (mdlapps) folder.
In line with my text above, I think this reason is not correct. I do not see - when talking about development of 3rd party applications - any reason why the access to mdlapps (or any other MicroStation program folder) should be required. It's about the application structure and also (again) about mixing responsibilities: