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
...\SDK\examples\Annotations\ManagedItemTypesExample\obj\Debug
If I create those folders (obj, Debug) manually then Viz Studio builds successfully.
To access SDK folders you need admin access. Open MicroStation CONNECT Edition SDK command window in admin mode. You need to have VS2013 installed.
Regards,
Shweta
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.
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
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.
BuildAllExamples.bat
openSln.bat
Shweta Tadge said:You need to have VS2013 installed
Really? I am as astonished as Jan!
Regards, Jon Summers LA Solutions
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.
Hi All,
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.
HTH,Bob
Hi Jan,
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.
Thank you,Bob
Hi Bob,
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:
With regards,
Jan Šlegr said:the examples are installed in wrong folder (should not be Program Files, but e.g. ProgramData, because they are data, not executables)
I agree. The development tools (bmake etc) should remain in the Program Files folder.
Jon Summers and Jan,
Thank you for your feedback/input. I was simply providing some quick relative insight on "current conditions" why LUA is not possible, and that I will be looking to "make further improvements" for tools and examples to be run under LUA, Another (likely minor) issue is to identify a developer-friendly default build output location that still can provide convenient MicroStation loading of native and managed developer built applications. I do try to provide some insights on related thread topics for information, or feedback and if determined better (by you our external developers) try/start to use discussion threads vs. question threads if that may help.