[CONNECT .NET] CONNECT Update 11 SDK: Build ManagedItemTypesExample fails in Visual Studio

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.

Parents
  • 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

  • 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.

  • 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.

    Regards,

      Jan

  • 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):

    • There is no reason why dev shell should depend on admin rights. No extra priviledges are required for application buiild process (compilation and linking), which is the core of SDK functionality.
    • Admin priviledges are (now) required for things that are not core functionality like to compile delivered examples, so it's about mixed responsibility.
    • ... but it's because the examples are installed in wrong folder (should not be Program Files, but e.g. ProgramData, because they are data, not executables).
    • Also the predefined output folder to MicroStation mdlapps is bad idea and in fact it's a demonstration of bad practice.

    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.

    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:

    • Building: Application is built in configured "work folders", defined in mke or csproj files. Folder like obj, debug etc. can be placed anywhere, often inside project structure, but always configured as ignored by Git (or any other used sytem).
    • Testing: It's where testing (sandbox) workspace should be used. To prepare the sandbox for the application testing is post-build task and because of MicroStation workspaces flexibility, again folders/files outside any restricted access can be used easily.
    • Deploying: I can imagine, in some scenarios, it makes sense to don't use own folders but to place (some) files directly to MicroStation program folders. But to solve restricted access is a responsibility of the application installer.

    With regards,

      Jan

  • 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.

     
    Regards, Jon Summers
    LA Solutions

  • 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.

    Thank you,
    Bob



Reply
  • 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.

    Thank you,
    Bob



Children
No Data