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

Trying to get going with Connect SDK and not having much luck:

First was getting missing .netfx toolset error, found the thread about .Net 4.6 needing to be installed, so I did, but that didn't create the netfx folder, so i modified the VCVarsQueryRegistry2017.mki file to look at 4.6.2 but now I'm getting:

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

Can anyone help? 

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

    so i modified the VCVarsQueryRegistry2017.mki

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

    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. 

  • Hi Viktor,

    For me the tools are installed here:

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

    I have:

    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.

    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 ;-).

    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.

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

    Mit freundlichen Grüßen / Best regards
    Volker Hüfner

    |  AB_DATE Engineering  Software   |  ab-date.de  |

  • Hi ,

    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.

    Answer Verified By: Robert Hook 

  • That's probably the case for me as well. I'll see if making the change to .mki will be sufficient instead of removing all the newer frameworkds.

  • Jan, I definitely meant managed addin, thanks for clarifying. I get confused with the terminology between Autodesk's various products and Bentleys.

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

    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.

     
    Regards, Jon Summers
    LA Solutions

Reply Children
No Data