Unable to build examples in SDK, Toolset Version, and just getting going

Hi Viktor,

unfortunatley because your provided not many information, it's hard to guess what can be wrong.

Please read and follow this forum best practices, namely specify exactly what MicroStation and MicroStation version do you use, and also using what Windows.

Viktor_Kulik said:

so i modified the VCVarsQueryRegistry2017.mki

If you have to modify anything in .mki, something is likely wrong.

Viktor_Kulik said:

Can anyone help? 

No until you provide more information:

• What NET Frameworks are installed on your computer? ... there can be more and as was discovered, when original 4.6 is missing and only 4.6.2 is installed, using (only) the latest SDK an error is reported.
• What Visual Studio is installed.
• What SDK example did you try.

You should also create and analyze verbose output (build example using verbose option) and also attach it to this discussion as crucial source of information.

With regards,

  Jan

Jan,

My mistake, been reading many posts and and forgot to include all the details.

Microstation Connect

SDK Update 12, filename: mssdk10120043en_updt12.msi

I was editing the mki file as per your suggestion in another thread since I didn't have .net 4.6 installed and the .mki file is pointing to it explicitly. 

I'm getting this:

This batch file should be run from a VS2013 x64 Cross Tools Command Prompt
Make sure that you have already run MicroStationDeveloperShell.bat in
order to set the required environment variables.
Visual Studio 2013 is required for this project

Hi Viktor,

can you confirm whether the problem was solved or not?

I do not like an approach "try to install / run something and hope it will solve the problem", especially when the source of the problem can be tracked and (usually ;-) solved.

Viktor_Kulik said:

Openned SDK Command prompt as an administrator and ran BUILDALLEXAMPLES

I think you should choose only 2 (simple) examples - one native and one managed - for testing.

Viktor_Kulik said:

BMAKE: Error - Cannot find the .Net tools location for this toolset. VS2017_DotNetToolsDir was not defined, and registry lookup failed.

The message is clear and mki file emmiting this message can be easily found. Did you check the mki file how the mentioned toolset is located?

Is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6/WinSDK-NetFx40Tools registry record defined? You can find plenty of discussions, not specific to MicroStation, about issues NET SDK registry problems.

Viktor_Kulik said:

I have VS2017 Community Edition installed with all the latest updates.

Well, you should be aware only Professiona and higher (which means Enterprise) version is supported officially. But in fact the discussed issue is not about Visual Studio at all (even about used version, not only about its variant), but about NET SDK, which is independent from Visual Studio (but optionally installed together with VS).

Viktor_Kulik said:

I didn't have .net 4.6

To have NET SDK 4.6 installed is required for Update 12, which is (as discussed already) identified bug, because 4.6.2 is required for MicroStation itself.

Viktor_Kulik said:

Well, I did install 4.6 Framework... but for some reason it doesn't come with SDK

NET Framework and NET SDK are two very different things and as developer you have to be aware of the differences!

Viktor_Kulik said:

can't seem to find how and where to get the 4.6 SDK

What about this page? There are plenty of documentation about NET Framework, NET SDK, available variants and how to install them (including explanation of a bit confusing terminology), I recommend to read this one.

Viktor_Kulik said:

Another question, if I put the examples aside, am I going to need 4.6 tools in order to compile a .net API Connect app?

This is good question, but new one, so you should ask in a new post!

But anyway: It seems there is a lack of knowledge what are roles of NET Framework, NET SDK, Visual Studio, MicroStation SDK shell and how managed addins work. And, strictly evaluated, the question is wrong and makes no sense, because you do not compile NET API, but MicroStation NET addin.

You do not need anything except NET 4.6.2 SDK to create addin for MicroStation CE U12. No Visual Studio, no shell, just SDK, Notepad and Windows command promopt (dos sheel). Anything else is just a tool (enhancement) that makes the development process easier.

To use properly configured VS C# class project is enough, there is only one exception: XCommands that I think can be implemented using MicroStation SDK tools only, but they are not mandatory for addin class.

With regards,

  Jan

Thanks again Jan. I may have not explained the problem clearly, but I do understand the difference between the sdk, framework, visual studio as the tool and microstation API. When I was referring to 4.6 Tools, I was referring to the NETFXSDK\4.6/WinSDK-NetFx40Tools, not Visual Studio. For me the tools are installed here:

C:\Program Files (x86)\Windows Kits\NETFXSDK

The real problem here is that .mki file is requiring an SDK tools of 4.6 to be installed, but even in the links you have provided, 4.6 SDK does not get installed. I have 4.6.1, 4.6.2, 4.7.1 and 4.7.2 installed. And even though I installed Developer Tools and runtime for 4.6, its still not installing the SDK tools in that folder. 

I understand that I don't need to compile any of the examples to build my own add-in, but it would be helpful to at least see one plug-in source code running.

Speculation here, but if you have the 4.6 Tools folder on your machine, is it possible that your machine was a windows 7 or 8 machine that was upgraded to windows 10? 

Hi Viktor_Kulik,

We noticed a few inconsistencies in latest U12 make includes specific to the detection of VS2017 and requirements.  We believe we have isolated issues some of our users have been experiencing and we should have these inconsistencies addressed in time for the MSCE SDK U13 release.  Please allow me a day or so to collate the issues, ensure each are filed to be fixed (asap) and provide a blog or wiki showing  what changes may be required as a temporary work-around until the U13 release.

Specific to your original ToolSet error below (requiring 14.16 vs 14.15 found), I suspect you have and earlier version of VS2017 installed and running: Help > Check for Updates; may address that issue properly.

BMAKE: Error - ToolSet version 14.16.XXX is required (version found=14.15.26726)

HTH and thank you,
Bob

Thanks Robert. Yea, I updated Visual Studio after I posted the original question. Will wait for the workaround. Our of curiosity, when is U13 supposed to be released?

Thanks.

Hi Viktor_Kulik,

If you can provide the current (concise) error you are receiving and then provide me a "build verbose" log; simply type "build verbose" from the developer shell; and send me the output log I should be able to provide a quick recommendation.

As for the release, we somewhat consistently release on a quarterly schedule.  So barring any unforeseen issues 3 months between releases is typical.  Here are the SDKAnnouncements as a reference target release time frame.

Bob

Build Verbose.txt

Do you need the whole thing? The first error pops up on line 1780.

Hi Viktor,

Viktor_Kulik said:

For me the tools are installed here:

What folder do you have under C:\Program Files (x86)\Windows Kits\NETFXSDK\?

I have:

Viktor_Kulik said:

The real problem here is that .mki file is requiring an SDK tools of 4.6 to be installed

As Bob wrote, it's bug. In fact it does not require the installation, it only checks whether registry and folder exist. Consequently it means can (as discussed in another thread) to change .mki file check 4.6.1 or 4.6.2 to pass through this check.

Viktor_Kulik said:

but even in the links you have provided, 4.6 SDK does not get installed.

That's weird and out of my knowledge. But because I found quite a lot of dicussions about similar problems with different NET versions, I guess historically side-by-side installation contains some bugs (and NET.Core solves this problem differently ;-).

Viktor_Kulik said:

but it would be helpful to at least see one plug-in source code running.

I agree it's valid argument and it's good to see everything is working fine, but because there is no requirement to have running SDK shell to build pure managed addins, a question is whether to invest time to hack the installation or to wait to Update 13 where I guess this issue will be solved.

Viktor_Kulik said:

one plug-in source code

No such terminology is used in MicroStation development, please use correct one. When you write plug-in, you confuse all readers, because it's not clear what you are talking about.

MicroStation CE applications can be:

• Native code (C++) applications required to be compiled using VS2017 now.
• Managed addins running "inside" MicroStation, written in any NET language (typically C#, but can be VB.NET, F#, IronPython...). Can be compiled by any compiler producing valid 4.6 CIL code.
• External applications accessing to MicroStation through COM, written in  whatever language.
• ... and as a subgroup, external applications accessing MicroStation through COM Interop wrapper around COM.

Viktor_Kulik said:

Speculation here, but if you have the 4.6 Tools folder on your machine, is it possible that your machine was a windows 7 or 8 machine that was upgraded to windows 10? 

Good question, but not. Except my main PC, I have also notebook where the latest Windows 10 were installed directly, so there is no history of older Windows. And NET 4.6 with all tools is installed and SDK shell works fine. Unfortunately I have no idea what software installed 4.6 tools, but I installed VS2005 (for V8i development), VS2015 (for older CE development) and VS2017 (for everything else). I think VS2015 was responsible for 4.6 tools installation.

With regards,

  Jan

Hi Victor,

A college has had some funny issues with 4.6.x. For some reason he did not have all 4.6. “packages” installed, but the 4.7.x already.

He was no longer able to install the rest of 4.6. correctly Some MicroSoft-Installer issue.

He had to deinstall all belonging to 4.7. And then he was able to install the missing 4.6 parts and afterwards the 4.7. - again.

Now he could compile on V8 and CE.

Sometimes you have to follow some magic rules :-)

Hi Viktor_Kulik,

Could you provide a small screen shot/snip of regedit showing the locations under this key?

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK

As mentioned there are a few issues that we see occuring (mostly on new/fresh VS installs) and for this I believe you many need to modify a line in the delivered .mki file (VCVarsQueryRegistry2017.mki:94) to point to "a higher" version than 4.6 that you have installed; like: 4.6.1 or 4.6.2 (preferred) if present.

Please check and make the edit to the mki file, or send a screen shot/snip of the expanded location so I can try to help further.

Thank you,
Bob

Hi Viktor_Kulik,

Could you provide a small screen shot/snip of regedit showing the locations under this key?

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK

As mentioned there are a few issues that we see occuring (mostly on new/fresh VS installs) and for this I believe you many need to modify a line in the delivered .mki file (VCVarsQueryRegistry2017.mki:94) to point to "a higher" version than 4.6 that you have installed; like: 4.6.1 or 4.6.2 (preferred) if present.

Please check and make the edit to the mki file, or send a screen shot/snip of the expanded location so I can try to help further.

Thank you,
Bob

See image of the registry. I have updated the lines 93-105 of  VCVarsQueryRegistry2017.mki to:

%if !defined (VS2017_DotNetToolsDir)
VS2017_DotNetToolsDir= $[@realpath $[@registryread "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1/WinSDK-NetFx40Tools", "InstallationFolder"]]
%if $(VS2017_DotNetToolsDir) == " "
%error Cannot find the .Net tools location for this toolset. VS2017_DotNetToolsDir was not defined, and registry lookup failed.
%endif
%endif
#introducing new variable as with 2017, microsoft further subdivided include folder with bin folder vs winsdk dir
%if !defined (VS2017_DotNetWinSDKDir)
VS2017_DotNetWinSDKDir= $[@realpath $[@registryread "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1", "KitsInstallationFolder"]]
%if $(VS2017_DotNetWinSDKDir) == " "
%error Cannot find the .Net tools location for this toolset. VS2017_DotNetWinSDKDir was not defined, and registry lookup failed.
%endif
%endif

Anything else I need to update?

It does seem to work so far, I guess when I first tried making this change it wasn't sticking mainly because I was likely missing the C++ libraries or VS wasn't updated.

Hi Viktor,

Glad to hear this issue is resolved with the proposed (temporary fix to the .mki - will try to correct for U13+).  You could point to either 4.6.1. or 4.6.2 (preferred) with likely minimal/no major issues.  About a year ago we wanted to retarget to 4.6.2 so that we can best align with Microsoft's lifecycle support policies.

Also, please feel free to mark one or more responses with the Suggest as Answer, since several very helpful people contributed and some of those comments may be important for (future) users to see if they encounter the same issue later.

HTH,
Bob

One more question regarding the SDK examples. So I was experimenting with WPFSample, it loads fine, works fine, so I decide to make some changes to see if I understand everything correctly, and no matter what change I make, I rebuild the project successfully, confirm that the .dll is replaced with a new one, restart microstation, load the new dll and it see none of the changes I made.

I even decompiled the .dll to confirm that the VS is building it with changes. Is it possible that microstation is caching this dll somewhere in the apps folder?

It's good to read that your development environment is set up and working!

Viktor_Kulik said:

I rebuild the project successfully, confirm that the .dll is replaced with a new one, restart microstation, load the new dll and it see none of the changes I made

That's a new question: please start a new thread.  I don't believe that many people have written WPF code (yours is the first question about WPF).  Make sure that you include WPF in the new thread title.