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?
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:
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
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
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.
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:
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.
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 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.
Answer Verified By: Robert Hook
Volker Hüfner 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.
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.
Regards, Jon Summers LA Solutions