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

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:

• OpenSln.bat ... It expects Visual Studio 2013. Really? When VS2015 is required officially and for NET development, any VS (probably including VS2019) can be used?
• TargetFrameworkVersion is still missing in csproj files, which often leads to problems with compilation.

Regards,

  Jan

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.

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.

Regards,

  Jan

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.

Regards,

  Jan

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:

• Create your own copy of the MicroStation Developer Shell shortcut icon (on desktop is fine)
• Check the Run as Administrator checkbox in your Shortcut Properties. Note, this is helpful since your shortcut can persist and not be affected/replaced by subsequent/numerous version updates.
• Simply open the correctly associated Microsoft Visual Studio version in the developer shell (type: devenv) that certainly inherits the Developer Shell environment variables (PEB) and Administrator elevation.
• From Microsoft Visual Studio then navigate to and open your appropriate sln, vcxproj, or vcproj.

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

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

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:

• 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